This repository contains the specs for the Forge Network UCAN protocol and associated subsystems.
- Access Protocol β governs how agents request capabilities from accounts, verified via email, and how delegations are delivered to their audience.
- Attested Authority β a scheme for using externally verified identities (email, OAuth, etc.) as UCAN issuers via attestations from a trusted authority.
- Blob Protocol β allows authorized agents to store arbitrary content blobs with a storage node.
- did:mailto DID Method β a DID method for identifying principals by email address, with no central source of truth.
- Egress Tracking Protocol β allows storage nodes to record the data they serve, so egress fees can be calculated.
- HTTP Header UCAN Invocation β sends UCAN containers in HTTP headers, leaving the request/response body free for other purposes.
- Index Protocol β allows authorized agents to publish verifiable claims about content-addressable data to IPNI, making it publicly queryable.
- PDP Protocol β allows a storage node to prove possession of stored blobs using cryptographic merkle tree commitments.
- Provider Protocol β defines how accounts provision spaces with a provider, making storage capabilities invocable.
- Replication Protocol β enables distributed storage of blobs across multiple nodes in the network after initial upload.
- Retrieval Protocol β defines UCAN capabilities for authorizing retrieval of resources, served in the same HTTP request they are authorized in.
- Revocation Checking - defines a HTTP API for checking UCAN delegations for revocation.
- Routing Protocol β constrains which storage nodes a space's blobs are allocated on, via shared routing policies that spaces reference.
- S3 Tenant Management β how tenants of an S3 compatible gateway are managed, and how S3 style credentials map to UCAN authorizations.
- UCAN Extensions β protocol extensions to the core
/ucannamespace that we hope to standardize in the core UCAN specifications. - Upload Protocol β allows authorized agents to manage the list of top level content entries β "uploads" β in a space.
We use the following label system to identify the status of each spec:
A work-in-progress to describe an idea before committing to a full draft.
A draft ready for review. It should be implementable.
A spec that has been implemented. It will change as we learn how it works in practice.
It may be improved but should not change fundamentally.
This spec will not change.
This spec is no longer in use.
Nothing in this spec repository is permanent. While some of the subsystems are stable, some are still in a draft or reliable status.
Suggestions, contributions, criticisms are welcome. Though please make sure to familiarize yourself deeply with IPFS, the models it adopts, and the principles it follows.
This repository falls under the IPFS Code of Conduct.