Access control

Access is per folder and per note, for the whole team or for one person, and it is enforced by the server rather than hidden in the interface. Vault Settings, Members and access carries three controls. Owners and admins see all three, and a plain member sees a read-only roster.

The three controls#

Everyone in <vault>Can edit · Can view · No access

The team's level, applied to every folder and note in the vault. Choosing one rewrites the team's rows across the vault in a single transaction rather than acting as a default that stops at the first folder someone had overridden. People you gave access to by name keep it.

New membersCan edit · Can view · No access

What someone sees for the notes that existed before they joined. It is snapshotted when they join, so changing it later does not reach back into people already in the vault.

Each personCan edit everything · Can view everything · No access · Custom

That person's absolute level across the vault. Custom means their per-folder grants differ from any single vault-wide level, and the profile's Access tab is where those are set.

How a level is decided#

For one person on one note, in order:

1. 1A No access row for that person on the note or any folder above it blocks it, unless a deeper row of their own says otherwise. Among one person's own rows, the deepest wins in both directions.
2. 2A personal level on the vault is absolute for that person. It replaces the team's posture, the owner and admin shortcut and authorship, and only their own folder or note grants lift a No access.
3. 3Otherwise, owners and admins have edit, and the person who created a note has edit on it. Both shortcuts are skipped when the item is not shared with the team at all, or when the team's level is Can view.
4. 4Otherwise take the highest of: a grant on the note, a grant on any folder above it, and the vault-wide grant, counting both the team's rows and that person's own.
5. 5Edit beats view beats nothing. No matching grant means no sync access at all.
6. 6A lock caps the result at view. It never grants and never removes read.

Giving one person access#

The profile's Access tab holds two views of the same thing, remembered per device.

• Board, the default: three columns, Can edit, Can view and No access, with rows dragged or moved by arrow buttons, a Set everything to menu including Reset to vault default, and Add all or Remove all per column.
• List: a checkbox tree of folders and notes with an Across the vault level at the top.

Both issue the same writes, one resource at a time, and each change applies immediately with a toast naming the result. Levels are colour-coded wherever they appear: Can edit green, Can view amber, No access grey, Custom neutral.

What asks for confirmation#

Only changes whose target is No access: the Everyone row, a person's vault-wide level, a row or note in List, the board's Set everything to No access, Remove all, and Reset to vault default. Moving something to Can view or Can edit never asks.

What a restriction does on disk#

Losing access moves the local .md into that device's trash on every device that had it. A revocation that left a full readable copy behind would be cosmetic, since the file could be opened in any editor forever. The server keeps the content, so this is a de-sync rather than a delete, and restoring access brings the note back: it reappears in the listing, is re-materialized and hydrates on open.

What a new vault starts as#

Creating a vault writes an Everyone grant of Can edit alongside its first collection, so an invited teammate lands on a vault with something in it. Vaults created before 2026-08-07 have no such grant and are private until their owner changes the Everyone row. To seal a vault, set Everyone to No access and grant people by name.

How the server enforces it#

1. 1The desktop app holds a session token from the OS keychain.
2. 2Before syncing a note it asks the server for a per-document token.
3. 3The server computes the effective permission and mints a token that is read-write, read-only, or refuses with a 403.
4. 4The editing socket verifies that token, so a client cannot open a document it was not granted.
5. 5Tokens are short-lived, ten minutes by default, and revoking access also force-closes live sockets, so the kill is immediate rather than eventual.

When the team's level is Can view, or your own personal level is Can view everything, the sidebar padlocks every folder and note rather than only the ones carrying their own lock, because to the person reading it those are the same state.