For many years a false duality has existed that pits “Cloud” and “Decentralization” at odds with each other, with each definition often being defined as not being the other. This dualistic presentation fails to meet even the most primitive user needs, but the most vexxing aspect of this presentation in terms of engineering is the fact that decentralized protocols are great for building fully distributed cloud services.

At DAG House, we build internet scale implementations of decentralized protocols and offer that infrastructure to the developers and users of all applications.

This is accomplished through the use of several inter-related decentralized protocols covered in detail throughout this document, but the most important to recognize early on are the protocols that provide some kind of decentralized address.

• CID - Hash based content identifiers for data. This means all data is identified by hash and never by location, which means data is never bound to a centralized location.
• DID - Identifies some kind of “actor” which could be a user identity, device, service provider, or delegated public key for any of the above.
• UCAN - Encodes permission grants, invocations, and receipts into data that is addressed by CID, effectively connecting CIDs and DIDs together into cryptographic proof chains that are themselves addressed by CIDs and routed to actors by DID.

Guide to Good Protocols

DAG House began in Protocol Labs where many of the core protocols we rely on were developed. As such, we’ve adopted many best practices from PL culture in regard to protocol development.

Future Proofing

Something that separates protocols that use hash addressing from other types of protocols, like those used in messaging and networking, is the need to support prior protocol version indefinitely. Once the data is hashed and linked to in the network, you are stuck supporting it in some way forever.

It pays huge dividends to include measures of future proofing early. Something as simple as reserving a single number or byte for signaling version can make your future self a very happy person.

It’s always good to make protocols simple, but part of simplicity is also extensibility. Leaving room for extending the protocol means you don’t have to bloat the core protocol to cover every use case.

Self-Description

This is a specific instance of future proofing that is worth calling out in detail all by itself.

The basic principal is, whenever I look at data encoded into “this protocol” the first thing it should describe is “this protocol.” It sounds simple, but the vast majority of protocols that exist today do not follow this principal. Many protocols exist inside of some existing container and the context that signals which protocol is being used is in the container rather than inside each protocol message.

It may not sound like a big deal, but part of thinking in decentralized systems is dealing with data outside the originating “container” which is often a centralized or trusted actor. Protocols that rely upon existing context or signal are less portable and less upgradable.

Multiformats