A Condensation store holds a set of immutable objects, and a set of accounts with mutable boxes. It provides 5 functions to access the object store and the boxes.
The object store keeps a set of hash → object pairs (usually structured as a hash table) and exposes 2 functions.
Given a hash, this function returns the corresponding object, or a not found message.
Stores an object. The object must exist when the function returns.
For efficiency, most protocols often offer an additional function to check for object existence prior to uploading its contents:
The account store keeps a set of accounts. An account is identified by the hash of the actor's public key object and consists of 3 boxes:
- public box
- private box
- in-queue box
A box stores a set of hashes, each of which points to an existing envelope object in the object store.
Public and private box typically hold a 1-2 hashes, while the in-queue may contain thousands of hashes.
The account store exposes 3 functions.
Returns the set of hashes currently stored in the box. Each hash points to an envelope object. If the account or box does not exist, or has never been used before, an empty list is returned.
Add hash or envelope
Adds a hash to a box. The hash is added before the function returns, but a concurrent removal request may remove it before the function returns. A store may refuse to add the hash if the corresponding object does not exist, or is not an envelope.
Removes a hash from a box. The function may return immediately, and defer the actual removal. An actor may only remove hashes from its own boxes, or envelopes that he sent.
Many protocols offer addition and removal as a single account modification function.
A public store should authenticate actors, and enforce the following access rights:
|put object||registered actors|
|list box||in-queue||any actor mentioned on the account's public card, or everybody¹|
|private box||any actor mentioned on the account's public card, or everybody¹|
|private box||authenticated actor|
|public box||authenticated actor|
|remove hash||any sender or recipient mentioned on the envelope, and any actor mentioned on the account's public card|
- Granting access to everybody does not undermine data security, but unnecessarily leaks side information about the user's behavior.
- For non-registered actors, the envelope size is usually limited to 16 KiB, and submissions may be rate-limited.
Any request may fail for technical reasons, such as storage system failures, full disks, or network errors. Note that requests may fail before or after their execution. Subsequent requests may again succeed.
Concurrent requests may be executed (and completed) in any order.
Add requests must behave atomically. If a list request sees the object hash, all following list requests must see the hash as well, until it is removed.
Remove requests provide no such guarantees. Hashes may disappear in any order, and even reappear sporadically.
At any time, a store may remove objects that are not referenced (directly or indirectly)
- through any box
- a recently uploaded (or booked) object
General-purpose stores should keep uploaded or booked objects with all their descendants for at least one hour. Stores for specific purposes may use shorter timeouts.
Stores are not obliged to carry out garbage collection in a regular fashion, or within a certain time.
The above functions are sufficient to run the Condensation protocol. A store implementation may offer additional functions, however, e.g. functions to create or close accounts.