specs/rooms/create/v0_2/payload
library
Classes
-
Payload
-
An owner registers a data room with a host. 0.2 adds
recordRetention: how long
the room keeps its records by age, stated at creation so that no record is ever
removed under a rule its readers could not have read.
-
RecordRetention
-
How long a room keeps its records, by age: the room's record retention. Records
older than it states become eligible to be removed by
rooms/records/prune;
nothing is removed until a holder of admin asks for a prune, and nothing a prune
removes can be brought back. Not retentionPolicy, and not retentionDays.
Both names are taken in this family and mean other things. retentionPolicy
(RetentionPolicy) is whether a room's key chain lets a member read epochs from
before they joined, fixed at creation because key material either exists for an
epoch or it does not. retentionDays (rooms/create) is how long a host keeps a
whole room after it lapses unrenewed. This is a third question — how long the room
keeps its records while it is live — and unlike the first it is a decision a room
revisits, so it is changeable (rooms/records/retention/set). A name sharing
either's would invite a reader to apply one's rules to the other. Age is the
host's to measure, so age is updatedAt. On the sealed tiers a host can read
nothing of a record but its key, version, status, pinning and when it last changed,
so a policy the host applies can only be stated in those terms. That is also why it
cannot use a record's own validUntil, which is sealed: expiry is a reader's rule,
retention a host's. A curation is a change, so it restarts a record's age — a
retraction starts a tombstone's. Absent, or {}, means no record is ever
eligible by age, and that is the reading a host MUST apply whenever it cannot
read a policy: removing data under a rule nobody stated is the failure this member
exists to prevent. Every member can read the policy in force (rooms/info), so a
record is never removed under a rule its readers could not have known.
-
Response
-
Success response to rooms/create. Type
https://trusttasks.org/spec/rooms/create/0.2#response.
Extension Types
-
AnchorCadence
-
How often this room intends to write an
EpochAnchor. A statement of intent, not
a schedule anything enforces — nothing in this family can make an owner anchor.
It is worth stating anyway, and the reason is the interesting part: it makes
silence legible. A room that says renewal and has not anchored in ten epochs
is telling a member something, and a member who did not know what to expect could
not have noticed. A room that says never is telling them not to wait for one. -
never — no anchor is intended. Honest, and cheap: anchoring costs a witnessed
update and a rotation of the room DID's update key each time. - renewal — one
anchor per epoch change, which is the cadence §9's lifecycle already moves at. -
manual — the owner anchors when they decide to. A member should draw no freshness
expectation from this at all, which is exactly what it is for: it is the honest
answer where there is no rule. Deliberately not a duration. A room that promised
"daily" would be making a claim its owner's availability cannot keep, and a member
comparing against a clock would read an owner's holiday as a host's misbehaviour.
-
RetentionPolicy
-
Whether a room keeps its history readable across a membership change, fixed at
creation and immutable thereafter — like
Visibility, and for the same reason: the
rungs of an epoch key chain either exist for an epoch or they do not, and no later
change of mind can seal key material that was never sealed or unseal what was
already severed. chained: each advance produces an EpochLink, so every member
reads the room's whole retained history however long they have been in it — what a
library wants, at the cost of post-compromise security for record content,
since a compromised current key then reaches every retained epoch. fromJoin: no
rungs are produced, so a member reads only from the epoch their group state is at —
what a stream wants, and what a room under a strict forward-secrecy obligation
wants, at the cost that a joining member finds an empty-looking room and nobody can
reread a record once their group state has moved past the epoch it was sealed
under. Absent means chained; see the prose on why the absent case is the readable
one.
-
Visibility
-
How much of a room its host can see, fixed at creation and immutable thereafter.
open: records are cleartext, searchable and fully audited. attributed: record
content is sealed, and the host still learns which member acted. private: content
is sealed and membership is presented in zero knowledge, so the host verifies that
a member acted without learning which. Immutable because a downgrade cannot un-see
cleartext and an upgrade would protect only what came after while presenting as
though it protected everything.
Typedefs
-
Ext
= Map<String, dynamic>
-
Vendor-namespaced extension object per SPEC.md §4.5.1. Each immediate key MUST be a
reverse-DNS namespace; structure under each namespace is opaque to the framework.
