Skip to content

Improve IPNS spec #205

@hugomrdias

Description

@hugomrdias

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions