-
Notifications
You must be signed in to change notification settings - Fork 236
Open
Description
The IPNS spec currently combines a lot into a single document and leaves some issues ambiguous. The main issues to tackle are:
- Terminology
- Spec names of IPNS path components:
/ipns/
/ipns/bafy...
/ipns/bafy.../images/pic.jpg
bafy...
/images/pic.jpg
- Spec names of IPNS path components:
- Data Types (mostly in the spec already)
- 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
- publish strategy
- If streaming updates from resolve (or to publish) is part of the spec it should be defined
- Existing router behaviors
- 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
hugomrdias, lidel and aschmahmann
Metadata
Metadata
Assignees
Labels
No labels