# Open State Repository

Nodes are published on an "open state" repository. The open state repository's core architecture has been designed in line with the principles set forth by the [Leiden declaration](https://www.fdo2022.org/programme/leiden-declaration-fdo) on digital infrastructure. This is the first step towards an [Internet of FAIR digital objects](https://www.go-fair.org/resources/internet-fair-data-services/) where access is guaranteed to all humans and machines. 

**The open state repository irrevocably separates control over the data layer from control over the application layer. This not only guarantees accessibility to all research outputs, but also protects against the formation of vendor lock-in.** 

The open state repository achieves this separation through a distributed and open peer-to-peer architecture based on [content-addressed storage](https://en.wikipedia.org/wiki/Content-addressable_storage) and ledger-based anchoring of secure data structures on an open state PID registry. For an example of a similar architecture, [see Microsoft's Sidetree protocol](https://identity.foundation/sidetree/spec/). 

The open state registry PID namespace combines all three properties of [Zooko's triangle](https://en.wikipedia.org/wiki/Zooko's_triangle): secure, decentralized, and human-meaningful. This is a solution that is famously [owed to Aaron Schwartz](http://www.aaronsw.com/weblog/squarezooko), the open internet activist. Every digital object on the repository is secured in a tamper-proof data structure and is versionable at will by its creators across all access points (Gateways) to the open state repository. DeSci Nodes is the first access point or Gateway to the open-state repository. It is a prototype interface to build research objects and to broadcast them on the network. 

Our end goal is to usher a future where the scientific record is **FAIR** and **OPEN**. 

{% hint style="info" %}
**Core properties of the Open State Repository**

**FAIR:** [PID](https://docs.desci.com/technical-background/open-state-repository/pid) + [Data](https://docs.desci.com/technical-background/broken-reference) + [Metadata](https://docs.desci.com/technical-background/open-state-repository/metadata) + [Methods](https://docs.desci.com/technical-background/open-state-repository/methods) for every digital object in a research object

**OPEN**: Open read & writes on a decentralized registry with data retrieval on a content-addressed storage network. 
{% endhint %}

## **What happens when you publish a Node on the open state repository**

When a Node is published, it is broadcasted from your private staging area hosted on our cloud infrastructure to the open state repository. Publishing triggers the repository’s registry to mint a single, version-invariant PID (called [dPID](https://www.dpid.org/put)). This PID serves as an anchoring point for the current version of your Node, which is structured into an efficient and secure data structure known as a [Merkle DAG](https://proto.school/merkle-dags). The individual branches of this Merkle DAG are [CIDs](https://docs.ipfs.tech/concepts/content-addressing/), serialized as an [IPLD-compliant](https://ipld.io/docs/), [JSON-LD](https://json-ld.org/) object. The root of this Merkle object is a cryptographic hash, and this hash is anchored to the Node’s PID on the open state registry contracts. 

Every time you publish a new version of your Node, a new root hash is anchored to your Node’s PID. This means that version history is preserved, and every event is logged with traceability: *who, what, and when.* 

## **Secure PIDs for linked digital objects**

Every Node has a single version invariant PID. From this PID, it is efficient to traverse the Merkle DAG and address any component of your node independently and uniquely. This is as simple as addressing a file path, something that everyone is familiar with. This means that every component of your Node has a provably unique path to every digital object contained, and therefore a unique PID. Because these PIDs are based on cryptographic hashes encoding the fingerprint of their content, they are architecturally guaranteed to secure data integrity. 

## **Permissions over the Node PID**

The Node creator can version the PID. As we upgrade the registry system, we will add permission delegation and a community recovery system to expand the flexibility and fault tolerance of the permission configuration.

## **Node PID permission recovery**

For the time being, DeSci Labs has admin rights over the open state repository registry contracts, which are upgradable via [proxy delegate](https://docs.openzeppelin.com/upgrades-plugins/1.x/proxies). This means that in the event of lost keys, we can re-assign your permissions to a new key. This is a necessary measure for the duration of the development process. 

## **Good UX for humans and machines**

Our goal is to make PIDs as useful to humans and machines as possible. For convenience, they are resolvable over HTTP as short, secured and human-friendly URLs via the DNS gateway [dpid.org](https://www.dpid.org/). You can learn more about the dPID schema [here](https://docs.desci.com/technical-background/open-state-repository/pid). 

## **DeSci PID properties**

You can compare below the properties of Node dPIDs with [DOIs](https://www.doi.org/) (which are based on the [HANDLE system](https://en.wikipedia.org/wiki/Handle_System)) and [content-identifiers](https://docs.ipfs.tech/concepts/content-addressing/) (CID). 

<table><thead><tr><th>Properties</th><th width="144">DOI</th><th width="177">CID</th><th>dPID</th></tr></thead><tbody><tr><td>Does not depend on a central authority</td><td><mark style="color:red;">FALSE</mark></td><td><mark style="color:blue;">TRUE</mark></td><td><mark style="color:blue;">TRUE</mark></td></tr><tr><td>Consistent resolution to their content</td><td><mark style="color:red;">FALSE</mark></td><td><mark style="color:blue;">TRUE</mark></td><td><mark style="color:blue;">TRUE</mark></td></tr><tr><td>Protects against content drift</td><td><mark style="color:red;">FALSE</mark></td><td><mark style="color:blue;">TRUE</mark></td><td><mark style="color:blue;">TRUE</mark></td></tr><tr><td>Linked Data support</td><td><mark style="color:red;">FALSE</mark></td><td><mark style="color:blue;">TRUE</mark></td><td><mark style="color:blue;">TRUE</mark></td></tr><tr><td>Method to compute over the data</td><td><mark style="color:red;">FALSE</mark></td><td><mark style="color:blue;">TRUE</mark></td><td><mark style="color:blue;">TRUE</mark></td></tr><tr><td>Native support for versioning</td><td><mark style="color:red;">FALSE</mark></td><td><mark style="color:red;">FALSE</mark></td><td><mark style="color:blue;">TRUE</mark></td></tr><tr><td>Method to resolve to metadata</td><td><mark style="color:red;">FALSE</mark></td><td><mark style="color:red;">FALSE</mark></td><td><mark style="color:blue;">TRUE</mark></td></tr><tr><td>Enables Short URLs</td><td><mark style="color:blue;">TRUE</mark></td><td><mark style="color:red;">FALSE</mark></td><td><mark style="color:blue;">TRUE</mark></td></tr></tbody></table>