Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve IPNS spec #205

Open
hugomrdias opened this issue Jul 3, 2019 · 5 comments
Open

Improve IPNS spec #205

hugomrdias opened this issue Jul 3, 2019 · 5 comments

Comments

@hugomrdias
Copy link
Member

hugomrdias commented Jul 3, 2019

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:
#198

/cc @aschmahmann @lidel

@lidel
Copy link
Member

lidel commented Jul 3, 2019

  1. Terminology

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

  • Spec names of IPNS path components:
    • /ipns/ipns namespace
    • /ipns/bafy...ipns root, ipns (content) path
    • /ipns/bafy.../images/pic.jpgipns (content) path
    • bafy...libp2p-key-in-cidv1b32, CID of libp2p-key (multicodec: add IPLD codec for libp2p public keys multiformats/multicodec#131)
      • While we are at this, we should improve UX/DX: default to CIDv1 in Base32 in spec, and change go-ipfs and js-ipfs to use libp2p-key-in-cidv1b32 in the default output of name publish
    • /images/pic.jpg – rootless content path

@aschmahmann
Copy link
Contributor

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
Copy link
Member

lidel commented Aug 14, 2019

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
Copy link
Contributor

Moved revocation discussion to new issue #219

@aschmahmann
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants