search

ipfs / specs

Technical specifications for the IPFS protocol stack
https://specs.ipfs.tech
1.15k stars 232 forks source link

Improve IPNS spec #205

Open hugomrdias opened 5 years ago

hugomrdias commented 5 years ago

The IPNS spec currently combines a lot into a single document and leaves some issues ambiguous. The main issues to tackle are:

  1. Terminology
    • Spec names of IPNS path components:
      • /ipns/
      • /ipns/bafy...
      • /ipns/bafy.../images/pic.jpg
      • bafy...
      • /images/pic.jpg
  2. Data Types (mostly in the spec already)
  3. Networking and Protocol spec
    • Existing router behaviors
      • dht
      • pubsub
      • dns
    • IPNS protocol
      • What must be implemented to be considered IPNS?
      • How is behavior in the presence of multiple routers defined?
      • publish strategy
        • republish/pinning strategy
      • resolve strategy
      • define specifications new routers must meet (e.g. must it support third party republishing, must it
      • If streaming updates from resolve (or to publish) is part of the spec it should be defined
  4. Other
    • Do we want to spec out any implementation suggestions or defaults?
    • Do we want to specify any extensibility points up front, or just PR the spec in the future?
    • Be explicit about DNSLink in /ipns/ namespace:
      • why we allow DNS names? what are the rules of interop? is there a plan to change current situation?
      • is supporting DNSLink required by IPNS implementers?
      • how should IPNS implementers who don't support DNSLink denote the IPNS namespace?

refs: https://github.com/ipfs/specs/issues/198

/cc @aschmahmann @lidel

lidel commented 5 years ago
  1. Terminology

I think it would be useful to write down what we use right now. When I think about IPNS, names I use:

aschmahmann commented 4 years ago

I can move this to another issue if we want, but I'd also like the spec to cover revocation of IPNS keys.

For example, one scheme that's pretty easy to implement is reserving the sequence number MaxUInt64 as indicating that an IPNS record has been revoked. It's basically implied anyway because you cannot publish updates after sequence number MaxUInt64, however this would embed in the spec that we should return an error and not the data if the record has been revoked. There are also other potential options we could explore if we're interested.

lidel commented 4 years ago

I'd move revocation discussion to a separate one, as we need to figure out its purpose first and how/if it should to have impact on "ipns follow/pinning".

aschmahmann commented 4 years ago

Moved revocation discussion to new issue #219

aschmahmann commented 4 years ago

Some other areas of the IPNS spec that should be cleaned up/formalized:

  1. Better description of the IPNS record identifier/key format. Does it use multihash, does it depend on the peer ID spec?
  2. An algorithm for determining which of two IPNS records is "better", or considered authoritative, given two records.