Skip to content

Latest commit

 

History

History
101 lines (59 loc) · 7.56 KB

dip-0001.md

File metadata and controls

101 lines (59 loc) · 7.56 KB
Raw

Identity and Retrieval on the DIG Network

Abstract

This document outlines a proposed approach to identity and retrieval in the Distributed Internet Gateway (DIG) network, which is based on the Chia blockchain. It explains the importance of separating identity from retrieval in a distributed mesh network and proposes a URN-based system for resource identification. The document also discusses various methods for resource retrieval, including intra-network synchronization, Web2 gateways, and Web3 native protocol handlers.

Introduction

For grounding in the topic of identities, refer to this explanation of the differences between URIs, URLs and URNs.

Though all URLs and URNs are URIs, in practice, location (URL) and identity (URI) have become conflated and are used interchangeably. For the purposes of this proposal, URI will be used to refer to non-URN identifiers that contain both identity and retrieval/location in the same construct.

Why is the difference between identity and retrieval important for DIG?

In practice with Web 2, identity and location are synonymous, and that is largely acceptable. It is common practice for resources that matter to have a canonical location, and the majority of resources don't intend to be permanent or often even long-lived. Retrieval-encoded URIs can be used as long-lived identifiers; a good example being the XML namespace for schemas: https://www.w3.org/2001/XMLSchema. It looks like a location, and there's even some reference material at that location, but in an XML document, it identifies the schema for XSD.

In a distributed mesh network, there is, by definition, no canonical location. Furthermore, the identity of a resource is permanent, even past the point where it is no longer present on the network. A resource's identity is expected to remain valid and static beyond the specific mechanisms that might be used to retrieve it (see below) and across multiple iterations of the network and its protocols.

Permanent Identities on the DIG Network

It is proposed that resources on the DIG network be identified by a URN. For a given store and resource, this urn should be invariant and permanent.

URN Format

urn:dig:chia:{storeID}:{optional roothash}/{optional resource key}

Namespace

  • urn - scheme identifier denoting a URN (case insensitive, required)
  • dig - identifier that denotes the DIG namespace (case insensitive, required)

Namespace Specific String (NSS)

  • chain name - for example chia (case sensitive, required)
  • store id - the DIG store identifier (case sensitive, required). This is a unique identifier for a collection of resources within the DIG network.
  • roothash - the roothash of the version of the resource being denoted (case sensitive, optional, the latest version is specified if not present)
  • resource key - the key of a specific resource within the store (case sensitive, optional - behavior if not specified is store dependent. For example, for a web application, index.html would be assumed).

Examples

  • URN denoting the latest version of a store: urn:dig:chia:17f89f9af15a046431342694fd2c6df41be8736287e97f6af8327945e59054fb

  • URN denoting an individual resource within the latest version of a store: urn:dig:chia:17f89f9af15a046431342694fd2c6df41be8736287e97f6af8327945e59054fb/css/app.css

  • URN denoting a particular version of a store: urn:dig:chia:17f89f9af15a046431342694fd2c6df41be8736287e97f6af8327945e59054fb:35cccf5cba6e3ee2dcf237b4b8a47c64e89cf733a95c6f5e9ac7062734c22b81

  • URN denoting an individual resource within a particular version of a store: urn:dig:chia:17f89f9af15a046431342694fd2c6df41be8736287e97f6af8327945e59054fb:35cccf5cba6e3ee2dcf237b4b8a47c64e89cf733a95c6f5e9ac7062734c22b81/css/app.css

Comparison of URNs for Equivalence

Per section 2.1 of the URN RFC the Namespace Identifier (NID) is case insensitive. Case insensitivity applies to the entire namespace, including the urn prefix. Thus URN:DIG and urn:dig are equivalent.

In order to conform to the generally accepted convention of the path part of location-encoded URIs, the NSS portion of the URN is case sensitive. Refer to RFC 3986 Section 3 for specific details.

Retrieval of DIG Resources

Once identity has been established, any number of retrieval or resolution mechanisms can be established that are completely decoupled from each other. This, if anything, is the biggest reason to be explicit in keeping identity and retrieval distinct. In a distributed, Web 3 mesh network, there will not only be multiple locations for a resource but multiple ways to retrieve it.

Intra-Network Synchronization

The DIG network needs to identify stores and individual resources as content is exchanged and synchronized between nodes. While the specific mechanisms are still being developed, the proposed URN-based identification system could potentially streamline this process by providing a consistent, network-wide identification scheme for resources. This could facilitate more efficient content discovery, replication, and synchronization across the distributed network.

Web2 Gateway

For Web2 applications (websites and such) to access DIG resources, there will need to be a way for those applications to identify and retrieve DIG resources. URNs lend themselves well to a resolver design, where there is a service, or in the case of DIG, services that can convert from a DIG URN to a resource stream. This would be similar to how ISBN book identifiers can be resolved via multiple Web2 applications: http://urn.fi/URN:ISBN:978-952-10-3937-9.

It is proposed that every DIG instance act as a resolver for any resources on the network, even if that resource is not mirrored on that instance. For example, if a resource is not hosted by the node dig.kackman.net, the following Web2 URL would redirect to a node that did host that collection:

https://dig.kackman.net/urn:chia:ad18c23361decb109c6bd5e49162bec9df79e44d0415e3f53a2e0f3416ea3457

Web3 Native Protocol Handler

For native DIG applications that have the opportunity to install a native protocol handler, a retrieval scheme can be defined such that native applications interact with DIG directly via its SDK:

dig://urn:chia:ad18c23361decb109c6bd5e49162bec9df79e44d0415e3f53a2e0f3416ea3457

In this case, the URN remains the same, but the retrieval scheme (dig://) invokes code that can resolve resources without a Web2 intermediary.

Benefits of the Proposed Approach

  1. Persistence: URNs provide stable, long-term identifiers for resources, independent of their current location or availability.
  2. Flexibility: Separating identity from retrieval allows for multiple retrieval methods, enhancing the network's adaptability.
  3. Scalability: This approach supports the distributed nature of the DIG network, allowing for efficient resource management across nodes.
  4. Compatibility: By providing both Web2 and Web3 retrieval methods, the system ensures broad accessibility while supporting next-generation applications.

Glossary

  • DIG: Distributed Internet Gateway
  • URI: Uniform Resource Identifier
  • URN: Uniform Resource Name
  • URL: Uniform Resource Locator
  • StoreID: A unique identifier for a collection of resources in the DIG network
  • Roothash: A hash that represents the state of a store at a particular version

URI URL URN graphic