Skip to content
Colibri Social Documentation

AppView

Colibri’s AppView is what you would call the backend in a conventional full-stack application. It serves the XRPC API and the event socket, holds each community’s credentials and writes records on its behalf, keeps a synced copy of every space it serves, and hosts the voice SFU.

What the AppView is

Section titled “What the AppView is”

A typical atproto AppView subscribes to a relay, consumes a firehose of public records, and indexes what it cares about. Colibri cannot work that way. Its data lives in permissioned spaces, and there is no relay for permissioned data.

The AppView therefore pulls each member’s repository from that member’s own host, holding a credential the community issued it. There is no firehose subscription for community content and no public repository indexing. Sync covers how that works.

Colibri AppView architectureThe client sends requests through the user's PDS to the AppView and opens a direct WebSocket to it for live events. The community's PDS asks the AppView whether a user may read a space, and the AppView writes the community's records back to it. Holding a space credential, the AppView pulls each member's repository from that member's own host and stores what it reads locally.requestsservice authsubscribeEvents (direct WS connection)checkUserAccesscommunity writeslistRepoOps / getReporead / writeClientSolidJS UIYour PDSATproto proxyCommunity PDSspace authorityMember reposon their own hostsLocal storelibSQL or PostgresAppViewNode

Reachability is a hard requirement

Section titled “Reachability is a hard requirement”

Every community space uses a managing-app policy naming the AppView, so the community’s PDS calls com.atproto.simplespace.checkUserAccess before it mints any credential.

An AppView that cannot be reached from wherever the community’s PDS runs makes its communities unreadable, even with the PDS itself perfectly healthy. It also costs writes made during the outage their place in the writer set.

Authentication

Section titled “Authentication”

Clients authenticate with an atproto service auth JWT that their own PDS minted for one specific method, sent in the Authorization header. The usual way to get one is to call the AppView through the user’s PDS with an atproto-proxy header, which makes the PDS mint and attach the token.

On top of the standard checks, the AppView enforces a maximum token lifetime. An issuer picks its own expiry, so a token captured from a log or a proxy stays replayable for however far ahead that was set.

Voice

Section titled “Voice”

Voice and video run on a mediasoup SFU embedded in the AppView process rather than a separate service. Session setup and control happen over a dedicated signalling WebSocket, not over XRPC. Only moderation actions have an XRPC method.

See also

Section titled “See also”