Shared Spaces Across Nodes
Overview
A Shared Space lets people on different UnoLock nodes work on the same encrypted notes and files. You choose where to host your Safe and who to share with. Each person keeps their own home node, and the content stays encrypted by the clients the whole way.
You can also download a password-encrypted backup of a Space and restore its notes and included files into another Safe, or merge them into an existing Space.
How sharing works across nodes
- The client holds the keys. The Space content key and the Space's private signing key stay in the client. Nodes and federation peers never receive them.
- Every remote operation is signed. When your client reads or changes a Space hosted on another node, it signs a short-lived proof for that exact operation. The other node verifies the proof against the Space's pinned public verifier, then still applies its own Safe, archive, quota and resource policy.
- Bytes stay encrypted everywhere. Files are encrypted in the browser before upload. Other nodes access them through an authorized relay or a verified complete encrypted cache. A cache never grants access by itself.
- Your browser talks only to your home node. Your home node handles the federation transport to the node that holds the Space. See Federation.
Notes and files
Notes live in a mutable records archive protected by signed metadata and compare-and-swap.
- The first committed writer wins.
- A competing writer gets a conflict error. Edits are not automatically merged or resubmitted.
- The whole records archive is one unit for conflicts, so edits to different notes in the same Space can also conflict.
- Refresh to load the committed contents before editing again.
Files are immutable. After a file is created it can be read or deleted, but not rewritten.
When the other node is unreachable
If your client cannot refresh the Space from its authoritative node, the Space becomes stale and read-only. A verified complete encrypted cache may still let you read files you are authorized to read. Saving notes, adding files and deleting require fresh authority from the Space's node.
Who can see what
- Everyone you share a Space with can retain the keys, ciphertext and plaintext they were given.
- Shared membership cannot be selectively revoked. To exclude someone, create a new Space with new keys.
- When the owner deletes a Space, a deletion notice (tombstone) is published. When a non-owner deletes it, only that Safe's membership and local copies are removed.
Sharing cannot be taken back
Once someone has opened a Shared Space, they can keep what they saw. Share only with people you trust with that content.
Protected Spaces
A Protected Space adds an approval threshold. Its keyring is initialized only after the configured number of verified Safe approvals.
- Approvers are contacted through separate one-to-one messages and approve or deny independently.
- An approver can authorize unlock without having access to the Space's content.
- Approval material and the reconstructed key stay client-controlled. Nodes and federation peers transport encrypted workflow state without receiving the plaintext Space key.
- The unlocked key exists only in memory. Signing out, closing the Safe, reloading the page or relocking removes it.
- Keep your Safe session open while you wait for approvals. Closing or reloading it means sending a new request and collecting new approvals.
After unlock, a Protected Space behaves like an ordinary Shared Space.
Encrypted Space backups
You can download a password-encrypted backup of a Space. With that backup you can:
- restore its notes and included files into another Safe; or
- merge them into an existing Space.
Keep the backup password and your recovery material safe.
Space backups are not node backups
A Space backup covers one Space and is protected by its password. A node backup covers the operator's whole server. See Backup and Recovery.
Full reference
FAQs
Can I share a Space with someone whose Safe is on a different node?
Yes. Shared Spaces work across independently operated UnoLock nodes. The content is encrypted by the clients and travels between nodes as ciphertext.
Can the other person's node read our shared notes?
No. Nodes and federation peers handle encrypted bytes and signed proofs. The Space content key and private signing key stay in the clients.
Why did my edit fail with a conflict?
Someone else committed a change to the same Space first. The first committed writer wins, and edits are not merged automatically. Refresh to load the latest contents, then make your edit again.
Can I remove someone from a Shared Space?
Not selectively. A recipient can retain what they were given. To exclude someone, create a new Space with new keys and share it only with the people who should have it.
Can I move a Space's contents into another Safe?
Yes. Download a password-encrypted backup of the Space, then restore its notes and included files into another Safe or merge them into an existing Space.