NAOMS for developers

← Back to overview

Building block

Sharing & permissions

Decide who can see and edit what, down to a single item, and share it with a group.

What a person notices

Sharing is not one master switch for everything a person owns. Calendar, contacts, and other kinds of data each have their own separate sharing setting.

A person can find out about mutual connections, for example working out mutual friends with someone, as a real feature rather than something they have to guess at.

When something is shared with a friend, a channel, or a Hive, the person on the other side does not see a person's real identity by default. If the system can't work out the right stand-in for that relationship yet, it refuses to share rather than exposing the real identity as a fallback.

Deleting shared data is a real deletion, not a flag that quietly leaves the underlying data sitting there. It is queued and then actually carried out.

What you get as a developer

Sharing is built on per-domain permission levels and a fail-closed identity rule, backed by real working code rather than a policy written down and hoped for.

1

Per-domain sharing levels

Each kind of data, such as calendar or contacts, has its own registered sharing-level scale. A developer isn't limited to one blanket shared or not-shared flag across every kind of data a person owns.

2

Mutual-connection lookups

The sharing engine supports finding shared or mutual connections between people, such as working out mutual friends. This is a real, working capability rather than a described but unbuilt idea.

3

Pseudonym, not identity, on anything readable by another party

Whenever a chain type is something another party can actually read, such as a friendship, a shared channel, or a Hive, the system deliberately avoids stamping a person's real root identity onto it. It uses a pseudonym scoped to that relationship instead.

4

Fails closed, at the point of writing

If the right pseudonym can't yet be computed, the system refuses to share rather than falling back to the real identity. This check is enforced at the point data is written, not just documented as an intention.

5

Real deletion, not a flag

A person can permanently delete shared data through a genuine queued-then-executed deletion path, so the underlying data is actually removed rather than merely marked as gone.

Local-first: sharing levels, mutual-connection lookups, and deletion all run against data that lives on the device, not a server that could see or retain it independently.

How it connects

Contacts & friendships

The pseudonym rule for sharing is the same mechanism that keeps a friendship from exposing a real identity.

Trust graph

Trust between people can inform who a person chooses to share something with.

Approvals & consent

A related but distinct control: sharing decides what others can see and edit, while approvals decide what apps and other people may do.

Related