Documentation

Everything you need
to know about 451

This is the documentation for both the 451 Project (Rationale, capabilities) and implementation details.

Overview

The 451 Project encompasses both a protocol (The 451 Protocol) and a platform (The 451 Platform). There are examples of successful protocols that form the base of the internet. DNS (the Domain Name Service) and IMAP (the e-mail protocol) are two relevant examples because they encompass a protocol and an actual implementation that has servers, storage accounts, and such, managed by committees. But since those early foundation implementations many of the important protocols have been client side implementations. Video transmission, timing and compression, low energy bluetooth, streaming, and Authentication, but not many with with a protocol and an implementation. It's a hard combination. Bluesky is probably experiencing a bit of this. How do have a distributed protocol, and still create a company and a platform worth millions or billions of dollars? Distributed protocols and their incumbent platforms make investors nervous.


Let's see if the 451 Project can walk that fine line. This documentation will cover both the protocol and some of the implementation details for the 451 Project

The Distributed System

The Use of DID's by 451

The 451 Project uses some best practices when it comes to distributed systems. When we use the term distributed we are talking about a system that can function effectively without centralized servers. There is no bottleneck from one server controlling proprietary information.

Distributed Identifiers play an important part of implementing this system. A distributed identifier is a globally unique ID generated independently by different parties without coordination.

A distributed identifier is:
✅ globally unique
✅ created locally
✅ no central registry required
✅ portable across systems
✅ often cryptographically derived

Following the ATProto protocol by BlueSky

The 451 Protocol follows the same definition for DIDs as the ATProto protocol. In the AT Protocol (used by Bluesky Social), a DID is the stable, cryptographically-controlled account identifier for a user or service.

Definition (ATProto) A DID is a globally unique, decentralized identifier that permanently identifies an AT Protocol account, independent of handle or hosting provider. What this means
In ATProto:
Handle → human readable (can change) DID → permanent identity (never changes) 

                Example:
                Handle:
                alice.bsky.social
                DID:
                did:plc:z72i7hdynmk6r22z27h6tvur

ATProto supports two DID types:

1. did:plc (most common)
Managed via 451 directory:
did:plc:abcdef123456

2. did:web
Domain-based identity:
did:web:example.com
What a DID controls
A DID resolves to a DID document containing:
public keys
PDS server
handle
services
signing authority
Example (simplified):

            {
              "id": "did:plc:abc...",
              "alsoKnownAs": ["at://alice.bsky.social"],
              "service": [{
                "type": "AtprotoPersonalDataServer",
                "serviceEndpoint": "https://pds.example.com"
              }]
            }

The Green Blockchain

The core piece of infrastructure maintained by the 451 Project is the Green Blockchain. This blockchain does not rely on traditional block height determination using "Proof of Stake" or "Proof of Work", but rather it uses the permanence of multiple S3 providers to create a "Proof of Life" mechanism.

There are currently only a few types of transactions written on the blockchain:

  • Persona Changes
  • Document Publication
  • Document Signing
  • Witness Signing
  • Authentication
  • Real Identity Verification

With these few protocol endpoints we can construct a large range of signing events.

Authenticate

You can use the distributed persona validation system to sign into a system that uses this distributed authenticatiuon system. Much like you can login with Apple, or Google, or Facebook, you can also log in with The 451 Project (log in with 451)/

Personas

Most platforms have the concept of users. A user is a one-to-one mapping of a real person to a user identity. In apps that follow the 451 protocol that concept is replaced by the persona and any one human can have multiple personas. Why? Is this some sort of scheme for allowing people to hide behind a false identity so they can do bad stuff. Well, actually, just the opposite. The 451 Protocol emphasizes openness in all types of publication.

First, the persona acknowledges that people have different aspects of their life. A school teach who teaches 5th grade in an elementary school may not want her class to learn that at night she volunteers with the Le Leche League to help young mothers who are breast feeding. The woman is not ashamed of what she does and she is not doing anything bad. Rather she has different aspects to her life.

Second, personas may obscure a person's real identity, but when that persona publishes that publication is always meant to be very public. The 451 protocol is not necessarily designed to have civility built in, but the implementation of the discovery algorithms in the 451 Project. And once you've elected incivility that algorithm may punish that persona into the future. The whole system is designed for openness and a desire to foster erudite, civil, discussion, not stifle it.

What a Private Publication and Private Personas means

There is the concept of Private Publication with Private Personas within the 451 Protocol and on the 451 Servers. This concept is mainly concieved for contracts and legal matters. And in that situation the requirements on the persona differ. Personas that sign contracts do not need to be validated/verified, but attorneys, or agents, who publish private documents must have their identity verified by a third party credentialling service.

Publication

Publication of 451 Documents (Text documents in JSON format conforming to the 451 Document Schema)

The 451 Project has a number of clients that conform to the protocol. That protocol can handle both text documents and binary streams (non-text). Text documents that do not conform to the 451 Document Schema will be treated as binary objects. A Rich Text Document, a MS Word Document, or a PDF, are examples of documents that are textual in nature, but ones that will be treated as binary objects. 


                Book:
                id: string (UUID)
                did: string (DID)
                accessrights: string
                audience: string
                audiencemediator: string
                author: string
                contributor: string
                dateAvailable: string
                description: string
                doi: string
                format: string
                identifier: string
                isbn: string
                issn: string
                language: string
                provenance: string
                publicationDate: string
                publisher: string
                rights: string
                rightsholder: string
                subject: string
                subtitle: string
                title: string
                transcript: string
                type: string
                pages: Page[]

You will not that there is an array of pages embedded inside of the book at the bottom. That definition looks like this: 


            Page:
              id: uuid
              title: string
              richTextJSON: bytes
              attachments: map
              created: datetime
              modified: datetime

Inside of that page the richTextJSON is an on-the-fly translation from a RichText format to a JSON corrolary.

Publication of Binary Documents

Not everyone will buy into the 451 Project's text format, and yet, the functionality for signing digital documents, and publishing them on the Green BlockChain should not be limited to the 451 Document Schema. The 451 Project has a number of clients that conform to the protocol. That protocol can handle both text documents and binary streams (non-text). Text documents that do not conform to the 451 Document Schema will be treated as binary objects. A Rich Text Document, a MS Word Document, or a PDF, are examples of documents that are textual in nature, but ones that will be treated as binary objects.

Attestation

The other types of activity that ends up in the Green Blockchain and in the S3 containers are attestations. This can take the form of a witness statement, a verification of collateral, an indication of receipt of something, the affadavit of an event, Declaration under penalty of perjury Verified Complaint (complaint with sworn facts), Verified Petition, Verified Answer, Supporting Declaration (filed with motion), Witness Statement, Statement of Facts, Statement in Support.

All of these are part of an orchestration where one party attests to seeing/witnessing an event, or the presence of a physical thing.

More coming....

Additional, more detailed, doucmentation is forthcoming including examples and a primer for using the specific implemenations of the protocol by the 451 Project