At this level
chat.yakka · 19- chat.yakka.ban record A member is barred from a server. Authority-written (ADR 0006). Enforcement is layered (ADR 0008): the mint refuses new credentials immediately and the realtime tier cuts the socket at once, but credentials already held live out their 2h TTL — the protocol has no revocation (Law 2). A ban is therefore effective within the TTL everywhere, and instantly where we serve.
- chat.yakka.defs defs Viewer state, kept apart from the channel because it changes on every read while the channel rarely changes.
- chat.yakka.getRealtimeTicket procedure Issue a short-lived, single-use ticket for opening the realtime socket (ADR 0034 §3). A browser cannot set headers on a WebSocket, and a cookie is the wrong instrument across origins — so the ticket goes in the socket URL, which is why it must be worth little: it authenticates one upgrade, once, within seconds. The socket is the appview's primary surface (ADR 0011), so this is not an afterthought but the only authenticated path for most of what a client does.
- chat.yakka.getSession query Who the caller is signed in as. The session cookie carries an opaque id and nothing else (ADR 0034 §2), so this is how a client learns its own DID — it cannot read one out of the cookie, by design. Answers 200 with `signedIn: false` rather than 401 for an anonymous caller: not being signed in is an ordinary state of the application, not an error in the request.
- chat.yakka.getSnapshot query Everything needed for first paint, in one round trip: the viewer's servers, the active server's channels and roster, and one channel's newest timeline page. One method rather than five because this is the server-rendered path — every extra round trip here is latency a reader sees before anything appears. Warm navigations do not call it at all; the client's store already holds the answer.
- chat.yakka.getTimeline query A page of a channel's timeline, newest first, ordered by view sequence (ADR 0012). Paging is by sequence and never by timestamp or record key: TIDs order a repo, never a channel, and two authors' clocks are not comparable.
- chat.yakka.getTimelineAround query A window centred on a sequence, for opening a permalink to an old message. Paging backwards from the tail to reach something linked from months ago would be many round trips, which is the entire reason this is a separate method rather than a parameter.
- chat.yakka.grant record One member holds one role. Authority-written (ADR 0006) — a member cannot grant themselves a role, which is why this is not self-written the way membership is. The mint reads these to decide gated-channel credentials (ADR 0007).
- chat.yakka.markRead procedure Advance the viewer's read marker for a channel. The marker is a `chat.yakka.readMarker` record in the viewer's own settings space (ADR 0017), so it follows them to any client rather than living in this appview's idea of them. Monotonic: a marker never moves backwards, so an out-of-order call from a second tab cannot un-read a channel.
- chat.yakka.member record Membership of a server, written by the member into the server's directory space. Join *is* the write (ADR 0005): there is no separate roster to keep in step, because the directory's writer set converges to the exact roster by construction. Leaving is deleting this record.
- chat.yakka.message record A message in a channel or DM space. The record lives in the *author's* repo within the space, so a message has no single owning collection to sort by — it is identified by (authorDid, tid). One collection serves channels and DMs alike (ADR 0016), which is what lets one pipeline carry both.
- chat.yakka.mute record Something the viewer does not want to hear from — a space, a server, or a person. Personal state in the viewer's own settings space (ADR 0017). A mute is a presentation preference, never access control: it hides, and hiding is not gating (Law 1).
- chat.yakka.postMessage procedure Write a message to the author's own repo, under their OAuth grant (Law 4: write admission belongs to the author's PDS, never to the appview). The appview is the caller's agent here, not an authority — a refusal from the PDS is reported as one rather than absorbed. Resolves once the record is ingested and sequenced, by which time the client has already shown a provisional copy and will reconcile on (uri, cid) (ADR 0011).
- chat.yakka.reaction record One reactor's reaction to one message. Written into the reactor's own repo within the message's space, so counts are an aggregate the view computes across the space's repos — never a mutable field on the message, which nobody but the author could write.
- chat.yakka.readMarker record How far the viewer has read in one space. Lives in the viewer's own chat.yakka.settings space, authority=self (ADR 0017), so read state follows the person across devices and into third-party clients.
- chat.yakka.resolveChannel query Resolve a URL's channel segment, which may be a name or a TID. Called by the client's route guard before anything renders. The five outcomes are distinct on purpose. Collapsing them would either lie about deleted channels or hide gated ones, and both are facts a reader is entitled to. `forbidden` deliberately reveals that a channel exists — which is safe only because channels are whole spaces and the credential mint has already made the same disclosure (ADR 0007).
- chat.yakka.resolveMessage query Resolve a permalink fragment's message ref within a channel. `ambiguous` is the case the explicit fragment form exists to avoid: two authors can in principle mint the same TID in one channel. Rare at any single channel's scale, not impossible across many — so it is a case, not an assumption.
- chat.yakka.role record A role that may be granted to members. Authority-written (ADR 0006). Roles carry no permissions of their own — they are named subjects that channel gates and the mint policy refer to (ADR 0007).
- chat.yakka.toggleReaction procedure Add or remove the viewer's reaction to a message. A reaction is a record in the viewer's own repo, so this creates or deletes one — there is no shared counter to increment, and the count a client renders is the appview's tally of records it has ingested.