Comments (3)
Some thoughts here:
In order to support the new key types as a MAY
along with Secp256k1 and ECDSA we need one of two things:
- libp2p adopts these keys and adds them to the supported key types with new numbers in the KeyType enum https://github.com/libp2p/specs/blob/d2106f43e878ae4c3a1c6465a7c329835290fe22/peer-ids/peer-ids.md#keys
- We introduce a new way to refer to IPNS identifiers as strings that does not match the PeerID format since the current format is tied to the
libp2p-key
codecLines 118 to 127 in f68df0c
Make it libp2p's problem
- Not totally unreasonable for them to want to support new key formats
- Clients need to update in order to handle the new key types
- If the idea is to use the Amino DHT to hold the records then the DHT servers would need to update to handle the new key type (and size limit)
- Either the set of implementations bumps the baseline supported max record size, or these only work in certain places
Diverge from libp2p-key
- Allows the different projects to move at different speeds here
- Makes it easier to be more explicit about evolving IPNS identifier and record semantics than previously
- Needs similar kinds of update propagation (although potentially more) as with it being libp2p's problem
- Requires agreement on the new formats (i.e. record formats, identifiers, and compatibility requirements) which could potentially be a bunch of work
Even if going with libp2p-key there's still the issue of whether increasing the record size everywhere even makes sense.
- If implementations are ok with this then things are relatively straightforward
- If not, since we're going from realistically under under 200 bytes #319 (comment) to like 20k bytes, then this is doable it just means they won't be able to go everywhere. For example anywhere that a record is too big to go instead insert pointers to the entities that have copies of the records since they are self-validating.
- This is similar to how kubo does IPNS over PubSub by using the Amino DHT as a rendezvous point
- Other mutability approaches like #258 could operate similarly in that their validation could be "too expensive/difficult" to be done by Amino DHT nodes, IPNI nodes, arbitrary record databases, etc. and so you can tradeoff some convenience for smaller record sizes + extensibility here.
Also, as a bonus the approach where you store pointers instead of records in places like the Amino DHT also means that fewer systems need to upgrade to support new key types in order for the end-to-end user experience to work (e.g. no need for the Amino DHT network to update to support the new key type, just for the providing and client nodes).
from specs.
Thanks @lidel ! It will be some time before I can get to this, but I will do that.
from specs.
Realistically, decoupling IPNS from libp2p-key codec across ecosystem will be way more work than the actual work related to adding a new key type. A side-quest that is bigger than the main quest of adding new key type.
Due to ecosystem effects, keeping them in sync always be way less work than decoupling, and (imo) as long it is specified as MAY
, we don't have to add new key type support to every libp2p impl., just reserve the number in protobuf defn. to ensure libp2p and IPNS do not end up with conflicting codes.
@ianopolous if you are interested in pushing the IPNS specification work forward, and want to focus on new key type alone, introducing a new key type by reserving enum in libp2p-key protobuf definitions at both places feels like the first step.
Itwill ensure peerid and ipns remain in sync, and we don't run into problems when libp2p adds something new:
- Open PR that adds it to https://github.com/libp2p/specs/blob/master/peer-ids/peer-ids.md#keys (and include information on how signature is generated)
- Open IPIP (template) that adds the same to https://specs.ipfs.tech/ipns/ipns-record/#key-serialization-format
Other details, such as increasing max size of IPNS record, would be part of the IPIP PR.
from specs.
Related Issues (20)
- gateway: add CORS to specs
- gateway: CDN-Loop
- gateway: batching raw block requests (AKA userland traversal of DAGs with unknown codecs)
- IPNS Publisher Key Seed Phrases
- Add specification for Web Pathing
- Gateway: define a protocol.ID for the gateway protocol. HOT 2
- Remove Kubo (userland) specifications
- WebSeed specifications HOT 1
- specs.ipfs.tech uses absolute URLs for links, assets
- _redirects spec clarification
- website: link to conformance.ipfs.tech from specs.ipfs.tech
- gateway: run Unicode Normalisation Forms on path gateway inputs HOT 2
- bug: accept header vs format query param precedence
- IPIP: path gateway - range requests clarification (nit) HOT 1
- bug: spec contradiction
- http response header for gateways: alt-svc HOT 1
- IPNS: clarify serialization and the type of ValidityType, TTL and Seq fields
- IPNS: protocol specification doesn't indicate dnsLink domain is valid as "domain" in "ipns://domain" URI
- [Feature Request]: Add IPFS Loopback Functionality HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from specs.