Sharing & Permissions

How Sharing Works

Krillnotes is local-first — every person has their own complete copy of a workspace on their own machine. There is no central server that holds “the” workspace. When you collaborate with someone, you’re not giving them access to your computer — you’re exchanging updates (called operations) so that both copies converge to the same state.

This design has a few important consequences:

• Your data is always yours. You can work offline, on a plane, in a bunker — your workspace is a file on your disk.
• Only changes travel. After the initial snapshot, syncing sends compact deltas — just the operations that happened since the last sync — not a full copy every time.
• The channel doesn’t matter. Operations are encrypted bundles of bytes. How they get from A to B is up to you.

Communication channels

Krillnotes is channel-agnostic — it doesn’t care how updates reach the other person. There are three built-in options:

All three channels carry the same encrypted operation bundles. You can even mix channels — sync with one peer via relay and another via a shared folder.

For details on setting up each channel, see Sync & Multi-Device.

Roles

Krillnotes uses role-based access control (RBAC) to manage what each peer can do. Permissions are assigned per note and cascade down the tree.

The workspace owner (the identity that created the workspace) has full control over everything and cannot be demoted.

Inviting a Peer

To share your workspace (or part of it) with someone, right-click a note and choose Invite to Subtree.

Configure the invite:

• Offered Role — the role the invitee will receive (Owner, Writer, or Reader)
• Expiry — when the invite expires (never, 7 days, 30 days, or custom)
• Channel — how to deliver the invite:
  • Relay link — generates a shareable URL via a relay server
  • Swarm file — exports a .swarm file to send by any means

Relay invite link

If you choose the relay channel, a link is generated that you can share.

Managing invites

Open Workspace → Invites to see all active invites.

You can revoke an invite to prevent further use, or delete revoked invites.

Accepting an Invite

When you receive an invite (either a relay URL or a .swarm file), the acceptance flow walks you through three steps:

Step 1: Import

Paste the relay URL or load the .swarm file.

Step 2: Review

Review the invite details before accepting.

Verify the inviter’s fingerprint against what you expect. This is the key security check — it ensures the invite came from who you think it did.

Step 3: Respond

Accept or reject the invite.

If you accept, a new workspace is created locally and a snapshot is downloaded from the inviter.

Pending Responses

After sending an invite, you can track whether the peer has responded.

Statuses progress through:

• Pending — waiting for the peer to respond
• Peer Added — the peer accepted but hasn’t received data yet
• Snapshot Sent — the workspace data has been transmitted

Granting Permissions

To give a specific peer access to a note (and its descendants), select the note and click the Share button, or right-click → Share Subtree.

Choose a peer from the dropdown and assign a role. The permission applies to the selected note and cascades down to all of its children.

Permission Inheritance

Permissions cascade from parent to child. The nearest explicit grant wins. For example:

• If you grant Writer on a folder, all notes inside it inherit Writer
• If you then grant Reader on a specific child, that child (and its descendants) become Reader, overriding the inherited Writer

Permission Indicators

The tree shows visual indicators for permission grants.

Permission dots

Coloured dots next to note names indicate the effective role for each peer:

You can control dot visibility in Settings via the Sharing Indicator Mode (Off / Auto / On).

Share anchors

Notes with explicit permission grants show a share anchor icon, distinguishing them from notes that merely inherit permissions.

Cascade preview

Before changing a permission that would affect descendants, Krillnotes shows a preview of the impact.

This helps you understand the consequences before committing — especially when demoting or revoking access.

Restricted Actions

When you’re working in a workspace where you have limited permissions, the UI adapts to your role:

• Readers see notes but cannot edit, delete, or move them
• Writers can edit and create but cannot delete or change permissions
• Buttons and menu items that exceed your role are disabled automatically