Take who the copy of a share is for
The INWARD half of settling a share’s audience, served by the organisation’s home and called by a developer’s — the twin of the entries and revoke operations beside it, and for their reason: the organisation’s home is a narya host, so this is one more operation on this contract rather than a second protocol.
IT IS ITS OWN OPERATION AND NOT THE ONE A PERSON USES. A home serving this writes the list and stops, because it holds the copy and has no far end of its own to tell. One road serving both halves would make a home that is both ends of a publish have to recognise its own call, and by the time that call arrives the list is identical on both sides of it — so the only fact available to recognise it by is the one fact that says nothing.
SETTLING THE SAME LIST TWICE IS NOT AN ERROR, and it is not skipped either: a home repeating this is a home whose first attempt it cannot know the fate of, and the state asked for is the state it gets.
WHO MAY CALL IT is who may change an audience anywhere — the person who published the share, or a member carrying members:manage — and the call travels as the person ASKING rather than as the person who published. That is what lets a departed colleague’s conversation be narrowed at all: nobody holds a credential for somebody who has left, so a call that had to travel as the author would wait for a sign-in that never comes.
A share this home holds no copy of answers 404, and so does a revoked or expired one: there is no audience here for the list to apply to, which is the state the caller asked for.
Authorizations
Enforced on every transport, with no exempt operation. A person's request — over the default local unix socket exactly as over a TCP listener — must carry a JWT issued by the configured identity provider, which the host verifies itself against that issuer's key set: signature, issuer, expiry, and the person and organisation it names. Requests without a valid one receive 401 NRY-0011. The socket's file permissions are transport and are not an authorisation.
Path Parameters
The share's id, as SessionShare.shareId reports it: 26 characters of RFC 4648 base32 drawn from a cryptographic source, carrying no encoding of anything. It is NOT a uuid and is deliberately unrelated to the session id it was published from — a share id travels, so an id derived from a session would make every leaked link a statement about the machine it came from.
26^[A-Z2-7]{26}$Body
Who a published share is for, after this request. THE WHOLE LIST AND NOT A CHANGE TO ONE. What is sent is what the share names afterwards, so adding a colleague and removing another is a single act with a single answer — a body that carried "add these, remove those" would be two lists that can contradict each other and a third rule for what happens when they do. ABSENT OR EMPTY IS THE WHOLE ORGANISATION, the ordinary publish and the default — never "a share nobody may read". It is how a share narrowed by mistake is widened again without republishing the conversation. Naming somebody twice is the same grant said twice and is kept once. A value no sign-in could report — a blank, a pasted line — is refused by name with 422, because a share addressed to a typo is a share readable by nobody answered with a success.
The subjects of the colleagues this share is for. They are members of the same organisation: there is no cross-organisation share, because one organisation is one home and a token for another is refused before any handler runs.
Response
The copy this home holds is for exactly the colleagues named.