Noosphere
Noosphere is a "protocol for thought" and the primary work product of my time as CTO and co-founder of Subconscious. Noosphere uses a combination of immutable data structures and public key cryptography to enable an alternative web with user-sovereign data and identity (without a blockchain, even).
Architecture
The atomic unit of content in Noosphere is a Memo: an immutable data structure that combines a header section with arbitrary body content (a la HTTP), and also includes a back reference to historical versions of same pairing.
Noosphere collects Memos into a document called a Sphere. A Sphere encodes a basic mapping from UTF-8 string values to a Memo (via CID), and bears an intrinsically verifiable signature over the rest of the document.
Diagram of the Noosphere prototype data structure
In totality a Sphere encodes:
- Paths: CID-addressed content mapped to UTF-8 string key
- Address Book: Peer public keys mapped to user-assigned petnames
- Authority: UCAN delegation hierarchy and associated revocations
The key benefit of the Sphere data structure is that it enables a new kind of URL: one that may be followed without resolving a name in DNS, or any other centralized name authority. In other words, all information needed to follow a Sphere-based URL is intrinsic to the Sphere.
We call these new URLs "slashlinks." A Sphere-relative slashlink—analogous to an origin-relative URL—looks like a pathname: /cat-thoughts. A fully-qualified slashlink adds a petname: @bob/cat-thoughts. The name "bob" is resolved to a public key by consulting the Sphere's petname "address book." That way we know the identity of the sphere where the /cat-thoughts content can be found.
The anatomy of a Noosphere "slashlink"
It is important to note that a slashlink does not constitute a locator by itself. Just as a typical URL is resolved by consulting a global name system like DNS, a slashlink must be resolved by consulting the local counterpart name system in Noosphere's architecture: the Sphere data structure.
A petname resolves to a public key. This public key is used to query a DHT to discover the latest version of the corresponding Sphere's data. The result of the query is a tuple that pairs a verifiable signature and a CID that can be used to look up the latest Sphere data from a potentially-decentralized storage source such as IPFS.
Sphere name resolution can be performed recursively. For example: a slashlink @google.com/bar first resolves the name com from the local Sphere, and then resolves the name google via the address book encoded by the Sphere resolved for com. Although never fully realized, this recursive resolution scheme was designed to enable using DNS as an alternative name authority for Noosphere.
Vertical slice of Noosphere network operations
Noosphere is designed to be maximally coherent with IPFS:
- Content links are CIDs
- Blocks are chunked for compatibility with bitswap
- Binary data is encoded as DAG-CBOR
- Blocks are transmitted in bulk via CARv1 slabs
- Noosphere's HAMT takes care to be compatible with IPFS' native implementation
However, Noosphere does not embed IPFS or encode a direct dependency on it. Instead, Noosphere is built around generic interfaces for reading and writing blocks. Any content-addressable storage—be it local or remote—can be used to store and retrieve blocks.
Informational poster describing Subconscious cloud architecture
UCAN
As part of this work, I was also active in the development of the UCAN spec via participation in the UCAN Working Group. I was the primary author of the Rust implementation of UCANs for multiple major revisions of the spec.
Ferris posing as the UCAN tucan