This is a proposal to implement an additional DHT for Content-ID labeling. The goal here is to make URIs in general and URNs in particular resolvable to a CID. This will IPFS-clients able to ask the network for matching Content-ID(s) for a known URI/URN.
A record in this DHT is signed by an authority, by default either an IPNS-key or a Node-ID. While this alone isnât establishing any trust in the record, there are several ways to establish a trusted anchor to the record.
One way is to include the Node-ID or the IPNS-key in a DNS record as an authorized key to publish IPFS records for this domain. As a practical example the IETF could publish an RFC under the URN urn:ietf:rfc:1149 and sign it with an IPNS key. The IPNS key can be shared between multiple nodes, avoiding a single point of failure. The IPNS key would be added to the DNS system, allowing DHT nodes to verify the source individually by verifying the signing key of the record with DNS requests. This measurement is just to avoid flooding of the DHT with false entries.
Example
The node interested in resolving urn:ietf:rfc:1149 is now hashing the string, and sending a request to the network. If the node is only interested in a certain type of verification, like DNS or a certain domain, this can be added as a filter, to avoid having to transfer large amounts of records which will be discarded anyway.
The DHT will respond with the matching record(s) and the client can ask his DNS server for the public key of the domain ietf.org to establish the trusted anchor.
Possible applications
Since the authority publishing and the string identifying the record are decoupled anyone can publish any string to be searched for. This allows for example to resolve digital object identifier, bibcodes but also regular URLs. This is useful for archiving purposes. Where a original source might go offline, but IPFS keeps a copy of the content for historical purposes - a prime example for this is archive.org which could publish the URLs they offer with a signature and store it to the DHT.
As a domain owner you could obviously also publish URLs for your domain in this DHT, if you migrated to IPFS and donât want to offer an HTTP server anymore. This would allow browsers to resolve any old http links to your domain.
Web-Of-Trust / ION integration
On a person-to-person level those records could be used with a web-of-trust where persons exchange Decentralized Identifier into their contact list and use them to filter the records received from the DHT - the prime example here would be ION which is build with IPFS and Bitcoin. This allows without having to rely on any external system to publish CIDs under human-readable identifiers between persons.
Metadata of records:
- Identifier in clear text â Must match the hash
- Record valid from date
- Record valid until date
- Epoch number (unsigned integer as version number)
- MIME type
- IPFS-Datatype
- Size
- Encoding Quality (string)
- language in ISO 639-1, -2 or -3
- Content creation datetime*
- Content capturing datetime*
- Content release/publish datetime*
- Content last modified datetime*
- Geo-Location: lat/lon
- Altitude
- Attitude
- Projection, coordinate system, ellipsoids etc GeoTIFF-Style
- Title
- List: Author(s)
- List: License(s) with their corresponding CID
- List: Content-Hashtags
- List: Parent-Objects Record-Identifier
- List: Alternative Versions Record-Identifiers
- List: Quoted Sources Record-Identifiers
- List: Related Objects Record-Identifiers
- Signature methods:
-
- Self
-
- IPNS
-
- DNS
-
- ION
-
- [âŚ]
Mandantory are bold.
* String to allow for scientific dates
Reverse records
Records could optionally also be published in the reverse direction. This allows CIDs to be resolved to identifiers and authorities. In this case, the DHT already needs to have the forward record with the same metadata and a clear text identifier stored. The DHT nodes which are requested to store the reverse entries will verify this before storing and serving the reverse entries.
Interface
As a simple interface, pins on the ipfs-webinterface could have these records as tags. So a user could add attach them and select how he likes to authorize this information. This would allow IPFS to store tags on pins decentralized and not only locally on a single node. Without changing the CID.
If the user chooses to add a reverse record other nodes could optionally fetch those tags automatically while fetching a CID.
Flooding prevention
Since thereâs some overhead on the DHT clients to process the received records for publishing we need a way to have clients who want to publish stuff to âpayâ for this with processing time - to avoid flooding and DoS.
As a possible solution we could generate a list of Argon2 hashes for random strings on each DHT node and add new ones/remove old ones from time to time.
If a client wants to publish a record, the DHT node would send him a challenge-response to let him calculate the Argom2 checksum for a random string from its list.
This way publishing records isnât cheap for the clients and will cost some processing time and memory usage for a while.
