> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # Settle who a published share is for > Changes who may read a conversation that has already been published, without republishing it. The share keeps its id, its expiry and its position: this is the audience and nothing else. A REPLACEMENT, which is what makes adding and removing ONE act. The list sent is the list the share names afterwards, so a colleague added and a colleague dropped happen in one request and the two can never disagree about who is on it. Absent or empty hands the share back to the whole organisation, which is the ordinary publish. WHOEVER ENTERS RECEIVES THE WHOLE CONVERSATION, from its first entry: the organisation's home holds the copy as it has been delivered, so a colleague added today opens everything sent before today. WHOEVER LEAVES LOSES IT AT ONCE — the next read answers 404 exactly as it answers a share id nobody minted, and the live view stops being written to them, because both ask the audience of the share as it stands rather than as it stood when they connected. WHO MAY CHANGE IT: the person who published the share, or a member carrying `members:manage`. Everybody else is answered 403 NRY-0028, the holder of `sessions:read-private` included — being able to read a conversation is not being able to decide who else may. A REVOKED OR EXPIRED SHARE IS OVER AND IS NOT RETARGETED. Its entries have been deleted, so an audience written onto it would describe a conversation that no longer exists. IT TRAVELS TO THE ORGANISATION'S HOME AND ANSWERS AFTER IT HAS, for the reason a revocation does: the home that decides who opens the copy is the home that holds it, so a change recorded only here is a colleague still reading a conversation they were taken off. 503 NRY-0029 means the local record is settled and this machine has told nobody. Asking again re-attempts the organisation's home and is what completes it — the same request carrying the same list is sent on again rather than recognised as already done here, because what this home holds says nothing about what the other one holds. Served AT the organisation's home — which is where the copy is — it is the local write alone, and there is nowhere further for it to go. ## OpenAPI ````yaml /es/openapi/v3-current/narya.yaml put /v1/shares/{shareId}/recipients openapi: 3.1.0 info: title: Narya Host API version: 1.0.0 description: >- The contract between the Narya host and every client. One long-lived host serves this API over a Unix socket in your Narya home. The terminal client and the one-shot command that Lerian ships drive this API, and a client you write drives the same one. Requests authenticate with a bearer token issued by the identity provider the host is configured with. An operation that declares another security scheme also accepts that credential. A request without a valid credential gets 401 with NRY-0011. A caller whose role lacks the permission an operation needs gets 403 with NRY-0028. Submitting a message returns 202 with a turn id. Everything the turn produces streams over GET /v1/events as server-sent events with a typed envelope, and a stream resumes from a Last-Event-ID header. One error envelope: code, title and message. Codes are NRY- followed by four digits. Cursors are opaque. servers: [] security: - bearerAuth: [] tags: - name: host description: The host process itself — version, uptime, mode, store. - name: sessions description: Durable conversation containers. Archive, never destroy. - name: messages description: Submitting work into a session and interrupting it. - name: events description: The server-sent event stream every client consumes. - name: lanes description: Parallel tracks inside a session — main, subagent, side. - name: agents description: Named recipes — instructions, tools, model, policy. Read-only in v1. - name: ladder description: >- What a person can type: the skills and command files in force for one repository, and expanding one into text. Five origins merged, nearest winning a name, the repository's own rungs gated on trust. - name: permissions description: Pending permission asks, decisions, and the decision audit. - name: intercom description: Sessions on one machine finding and messaging each other. - name: packages description: The one thing a user installs — resources, Go code, or both. - name: extensions description: >- Host-side extensions and the operations each exposes over the wire. This is the generic lane a host extension uses to serve its own client half (a TUI component, a web panel) or any API-only consumer, without adding routes to this contract. - name: workflows description: Deterministic multi-agent orchestration runs. - name: providers description: Model suppliers, their auth state, and the model catalogue. - name: monitors description: >- Long-running watchers a session keeps beside its conversation — a test runner in watch mode, a build, a log being followed. Started by the model or by the person, always listed, always killable. - name: records description: The queryable local record of everything that happened. - name: environments description: >- Where a session's code lives and its commands run — this machine, or a container narya operates. A session that names none runs here. - name: schedules description: >- Work the host's own clock starts with nobody present — a repository, a prompt, a rule and what one fire may spend. Cancel, never destroy. - name: sharing description: >- Publishing a session from a developer's own home to the organisation's, and what is held back before a byte leaves the machine. - name: refinements description: >- What this owner has taught narya and allowed it to keep — distilled facts, and the skills, agents and commands the model wrote for itself. Propose, read, consent, roll back. Nothing here fires until a person answers. - name: platform description: >- Calls Lerian's control plane made to a home it hosts, as this home recorded them. paths: /v1/shares/{shareId}/recipients: parameters: - $ref: '#/components/parameters/ShareIdParam' put: tags: - sharing summary: Settle who a published share is for description: >- Changes who may read a conversation that has already been published, without republishing it. The share keeps its id, its expiry and its position: this is the audience and nothing else. A REPLACEMENT, which is what makes adding and removing ONE act. The list sent is the list the share names afterwards, so a colleague added and a colleague dropped happen in one request and the two can never disagree about who is on it. Absent or empty hands the share back to the whole organisation, which is the ordinary publish. WHOEVER ENTERS RECEIVES THE WHOLE CONVERSATION, from its first entry: the organisation's home holds the copy as it has been delivered, so a colleague added today opens everything sent before today. WHOEVER LEAVES LOSES IT AT ONCE — the next read answers 404 exactly as it answers a share id nobody minted, and the live view stops being written to them, because both ask the audience of the share as it stands rather than as it stood when they connected. WHO MAY CHANGE IT: the person who published the share, or a member carrying `members:manage`. Everybody else is answered 403 NRY-0028, the holder of `sessions:read-private` included — being able to read a conversation is not being able to decide who else may. A REVOKED OR EXPIRED SHARE IS OVER AND IS NOT RETARGETED. Its entries have been deleted, so an audience written onto it would describe a conversation that no longer exists. IT TRAVELS TO THE ORGANISATION'S HOME AND ANSWERS AFTER IT HAS, for the reason a revocation does: the home that decides who opens the copy is the home that holds it, so a change recorded only here is a colleague still reading a conversation they were taken off. 503 NRY-0029 means the local record is settled and this machine has told nobody. Asking again re-attempts the organisation's home and is what completes it — the same request carrying the same list is sent on again rather than recognised as already done here, because what this home holds says nothing about what the other one holds. Served AT the organisation's home — which is where the copy is — it is the local write alone, and there is nowhere further for it to go. operationId: setShareRecipients requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/ShareRecipients' responses: '204': description: >- The share is for exactly the colleagues named, at this home and at the organisation's. '400': $ref: '#/components/responses/BadRequest' '403': $ref: '#/components/responses/Forbidden' '404': $ref: '#/components/responses/NotFound' '413': $ref: '#/components/responses/RequestBodyTooLarge' '422': $ref: '#/components/responses/UnprocessableEntity' '500': $ref: '#/components/responses/InternalServerError' '503': description: >- The organisation's home did not answer (NRY-0029), so the copy it holds is still for whoever it was for. This home's record is settled; repeating the request once the home answers re-attempts it and completes it. content: application/json: schema: $ref: '#/components/schemas/Error' components: parameters: ShareIdParam: name: shareId in: path required: true description: >- 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. schema: type: string minLength: 26 maxLength: 26 pattern: ^[A-Z2-7]{26}$ schemas: ShareRecipients: type: object description: >- 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. properties: recipients: type: array items: type: string description: >- 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. examples: - recipients: - user_grace - user_auditor - recipients: [] Error: type: object description: >- The single error envelope every operation returns. Codes are NRY- followed by four digits and are catalogued in the top-level x-error-catalog extension. required: - code - title - message properties: code: type: string pattern: ^NRY-[0-9]{4}$ description: Machine-readable error code from the NRY catalogue. title: type: string maxLength: 256 description: Short human-readable summary of the error class. message: type: string maxLength: 4096 description: Specific, actionable description of what went wrong. fields: type: object description: Per-field validation problems. additionalProperties: type: string examples: - code: NRY-0002 title: Session not found message: >- No session with id 6b9f6d2e-1c3a-4f5b-9d7e-2a8c4e6f0b1d exists on this host. responses: BadRequest: description: Malformed request — invalid parameter, cursor, or JSON body. content: application/json: schema: $ref: '#/components/schemas/Error' Forbidden: description: >- The caller is authenticated and is not allowed this operation (NRY-0028 or NRY-0030). content: application/json: schema: $ref: '#/components/schemas/Error' NotFound: description: The addressed resource does not exist on this host. content: application/json: schema: $ref: '#/components/schemas/Error' RequestBodyTooLarge: description: >- The request body weighs more than this operation accepts (NRY-0024). The host holds one ceiling per operation and refuses at the door, in front of every handler: a body whose declared Content-Length is past the ceiling is refused before a byte of it is read, and a body that declares no length is read only as far as the ceiling and refused there. Nothing was read past that point and nothing was written. content: application/json: schema: $ref: '#/components/schemas/Error' UnprocessableEntity: description: The request was well-formed but failed validation. content: application/json: schema: $ref: '#/components/schemas/Error' InternalServerError: description: The host failed — including a store that refuses writes (NRY-0012). content: application/json: schema: $ref: '#/components/schemas/Error' securitySchemes: bearerAuth: type: http scheme: bearer bearerFormat: JWT description: >- 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. ````