Writing subspaces

Each user has a randomly generated writing key pair which controls writes to their filesystem. They can create new writing key pairs for any subtree, for example when granting write access to a file or folder. If desired, a given writing key can be quota controlled, to prevent users to which you've granted write access to a file from filling your data store.

Every signing keypair, including your identity keypair, and your root writing keypair, map to a data structure called WriterData. A WriterData can contain merkle links to roots of merkle champs and various public keys. The full data structure is listed below. If any of the properties are empty they do not contribute to the size of the serialized WriterData.

// the public signing key controlling this subspace
PublicKeyHash controller;

// publicly readable and present on owner keys
Optional<SecretGenerationAlgorithm> generationAlgorithm;

// This is the root of a champ containing publicly shared files and folders (a lookup from path to capability)
Optional<Multihash> publicData;

// The public encryption key to encrypt follow requests to
Optional<PublicKeyHash> followRequestReceiver;

// Any keys directly owned by the controller, that aren't named
Set<PublicKeyHash> ownedKeys;

// Any keys directly owned by the controller that have specific labels
// only used for the PKI
Map<String, PublicKeyHash> namedOwnedKeys;

// This is the root of a champ containing the controller's filesystem (present on writer keys)
Optional<Multihash> tree;