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;