Records and sharing

A record is written in its author's browser and sealed there. The server keeps its type, its revision number, its author, the key id it was sealed under and the sealed body. Its title, field names, values and files are inside that body.

Status. Release 0.0.1, the first.

What a record holds

• A type: eleven are built in, and an admin can define more, each naming the roles that may use it.
• Fields of fifteen types in named sections, added freely to any record.
• One-time password codes (RFC 6238), shown with the seconds left.
• SSH keys: Ed25519, generated or imported in OpenSSH's formats, with their fingerprints.
• Files, encrypted in the browser in 64 KiB chunks, up to 256 MiB each. A file whose chunks were reordered, dropped or added is refused.

Revisions

Each revision is sealed under a content key used once and bound to its company, record, revision and key, and signed by its author. A revision is written only over the one it was read at, so two editors cannot overwrite each other: the second is refused. A browser refuses a revision that was moved, altered or not signed, and one older than a revision it has already seen.

Sharing

A record is shared with a member, a team, a department or the whole company. The browser wraps the record's key to that member's or group's key and the share is written with the wrap in one transaction. The right is read or edit: edit lets the member revise the record, share it on and add files.

A browser wraps a record key only to a key that the company owner's chain of signed statements vouches for; see Keys and layers. A server that inserts a key of its own gets nothing to read.

Taking it back

• Removing a share stops the member or group at the next request, takes their wrap off the latest revision, and requires the next revision to be sealed under a new record key.
• A member leaving the company marks the company's key, every key of their groups and every record they wrote or could open for rotation in the same way.

Removal stops future reads. It cannot make anyone forget a value they already read: change that secret at its source.

Files

The author or an editor uploads a file in parts of up to 4 MiB, in order; it can be read back, in ranges, only once it is complete. A file up to 64 KiB is kept in the company's vault and a larger one in a TessariDB bucket. Each upload and each read is on the company's trail.

Deleting a record

The author or a company admin deletes a record with every revision, wrap, share and file in one transaction, and the reason they give is on the trail. Anyone else is refused, or told it does not exist when they cannot reach it.