Five sites read `AtpAgent.appLabelers`, which the previous commit stopped
populating - a silent regression, since an empty static reads as "no
authorities" rather than failing. All now read `Client.appLabelers`, the static
that is actually configured:
- `lib/moderation.ts`'s `isAppLabeler`, which decides whether a labeler is
non-removable in the UI;
- `preferences/moderation.ts`'s `useMyLabelersQuery`, which seeds the labeler
list with the app authorities;
- `feed/custom.ts`'s hand-rolled logged-out `getFeed`, which reproduces the
header lex would have emitted because the request bypasses the client.
`sessionAccountToSession` (the `AtpSessionData` conversion) had no callers left
once the bridge agent went, and the age assurance config read - the one
standalone `new AtpAgent` the age assurance slice deliberately left behind -
moves to the public appview client, which is what it was approximating.
That is the last `AtpAgent` in src. What remains of `@atproto/api` in the
session layer is types and `BSKY_LABELER_DID`, which S4d owns.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The bundle becomes `{session, appviewClient, pdsClient, chatClient, service}`
and the hooks read those fields directly, so `useAgent` and the three
`agentTo*Client` memo maps go with the agent. The WeakMaps existed only because
clients were derived from a long-lived agent; a bundle that HOLDS its clients
gets identity stability for free.
The clients are now the sole producers of their own headers, which is what lets
`bridge-agent.ts` (442 lines) and `agent.ts` go:
- the appview client passes BLUESKY_PROXY_HEADER as its `service`, so it emits
atproto-proxy itself rather than inheriting it from a configureProxy call
sequenced after the PDS-targeting setup;
- labeler subscriptions go on the appview instance via `setLabelers`, and the
global `;redact` authorities come from the `Client` static alone. Both halves
of the double-emit hazard the previous slice documented are closed by there
being one producer instead of two, so the appview client no longer suppresses
`appLabelers` - only the PDS and chat clients do, because those services take
no moderation authorities at all;
- `configureGlobalAppLabelers` drops its `AtpAgent.configure` half.
PDS routing for the pre-didDoc window is `routeSessionToPds`, a 10-line shim
replacing the manager's dispatchUrl/extractPdsUrl/identity-cache apparatus.
`PasswordSession` resolves each request against `extractPdsUrl(didDoc) ??
service`, so an entryway account with no didDoc yet - the synchronous resume
fast path, i.e. the common cold start - would send every request to the
entryway. The shim absolutizes against the stored url first, which survives
`new URL(path, base)` untouched. It pins that url for the bundle's lifetime
where the manager would have preferred a later didDoc endpoint; that only
differs if the account's PDS moved, and the next cold start pins the new one.
Four cases in clients-test cover this, including the two the old suite could
not express (pinned-vs-didDoc precedence, and didDoc routing with nothing
pinned).
`createPublicSessionBundle` now runs `configureModerationForGuest` itself. That
is a behavior fix, not a refactor: it populates the `Client.appLabelers` static
the public appview client reads, and with no agent left to stamp the header a
logged-out read would otherwise carry no moderation authorities.
finishPreparation, the kill-switch disposal, the redacted logging, refreshSession
and the expiry-rescue path are unchanged - only how the bundle is constructed
moved. Disposal is now just the hook kill: the clients hold no state, and every
request they make goes through the session's injected fetch.
bridge-agent-test.ts is deleted with its subject. clients-test.ts is rewritten
against session-built clients, keeping every header canary (exactly-once on the
appview, none on pds/chat, exact proxy values, the throwing client's cause
chain). The three provider suites and session-core-test are adapted in place -
their constructions change, their assertions do not.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The last non-session `useAgent` consumers, all thin aliases over calls the
clients already make:
- `handle.ts`: `getProfile` / `resolveHandle` to the appview client.
- `post.ts`: the three post readers share one `fetchPost` helper on the appview
client. Their consumers still want `@atproto/api` views, so the generated view
is asserted across at that single boundary rather than at each call site.
- `post-feed.ts`: `agent.session` gated the logged-out "did any post survive
moderation" assertion, which is a question about the session, not the
transport - it reads `hasSession` from the session context now.
- `ChangeHandleDialog`: `agent.serviceUrl` becomes `currentAccount.service`.
- `TestCtrls.e2e`: drops the `configureProxy` call. The appview client reads
`BLUESKY_PROXY_HEADER` when the bundle builds it, and the gate around this
input means no bundle exists yet, so setting the constant is sufficient.
`preferences/index.ts` still writes labeler subscriptions to the agent; that
one moves with the bundle rework, which is what gives it a client to write to.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
`resolveLink` took an agent and used it for four appview reads plus the chat
invite preview, so it now takes both clients as a `LinkResolvers` pair - the
caller cannot know which branch a URL will take until it is parsed. That was
the last DM_SERVICE_HEADERS site, so the constant is deleted.
`resolveGif` never touched the agent at all (it is pure URL metadata work on
what the picker already returned), so its parameter is dropped rather than
replaced, along with the one on `fetchResolveGifQuery`.
With the resolvers on clients, `apilib.post` loses the agent parameter the
previous slice kept solely for them, and `composerStateToDraft` takes the
resolver pair instead of minting a throwaway public agent.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Convo and MessagesEventBus were the last two useAgent consumers holding a
long-lived agent rather than reading one per render. Both now take a chat
client, which carries the atproto-proxy header itself, so the per-call
DM_SERVICE_HEADERS drop out under the double-set rule.
Both providers gained an effect that pushes the current client into the
instance. The instances are created once with useState and outlive the client
they were built with: an account switch, a cross-tab token sync or an expiry
rescue replaces the bundle and disposes the previous clients, so without the
sync a convo would keep sending through a dead session.
`handleSendMessageFailure` narrows on XrpcResponseError rather than XRPCError.
The lex client throws the former, so the status branch (and the recoverable /
unrecoverable split that drives the retry banner) had silently stopped firing.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
`configureGlobalAppLabelers` now writes both `AtpAgent.configure` and
`Client.configure`, so a client built without a wrapped agent carries the
global `;redact` moderation authorities. That is what the logged-out appview
client needs: it has no agent underneath to stamp the header, and after the
bundle rework no client will.
Flipping the static alone double-emits, which two probe runs confirmed. Neither
producer dedupes against the other - the agent joins its list with whatever is
already on the request while lex collects into a `Set` keyed on the
`;redact`-suffixed string - so a DID in both statics produced
`did:plc:x;redact, did:plc:x;redact`. Separately, the PDS and chat clients wrap
the session manager *below* the agent's header layer and so emitted no labelers
at all; the static would have started adding them to non-appview requests.
Both are closed by building the three agent-wrapping clients with
`appLabelers: null`, which suppresses the class-wide static per instance. That
leaves exactly one producer on an appview request and none on a PDS or chat one,
while the static stays populated for the clients that read only it. The
labeler-header tests cover all three surfaces and fail without the suppression.
The per-account subscriptions stay on the agent for now, behind
`applyLabelersToClient`, because the agent is still what stamps the header on
the wrapping client's requests. The bundle-rework slice repoints that one
function body at `appviewClient.setLabelers` and drops the agent statics; the
`Client.configure` half of `configureGlobalAppLabelers` and the
`appLabelers: null` on the appview client both stay as they are.
`configureModerationForAccount` takes the bundle rather than a bare agent,
matching the signature the bundle rework needs.
The rest of the consumer surface - components, screens and the legacy `view`
tree - takes its moderation types from `@bsky.app/sdk/moderation` and its
`moderate*` calls from the `lib/moderation/subjects` seam.
`DebugMod` constructs a `ModerationOpts` by hand for its scenario matrix, so
its literal `userDid` is branded at the construction site.
Query, notification and feature-level moderation reads switch to the sdk types
and take their `moderate*`/`hasMutedWord` entry points from the
`lib/moderation/subjects` seam, since these paths still carry
`@atproto/api`-typed views.
`shouldFilterNotif` is the one behavioral seam worth noting: its notification
and facet values come from an unmigrated read, so the mute-word check goes
through the widening wrapper rather than the sdk export directly.
`UsePreferencesQueryResponse` now derives from the sdk's `BskyPreferences`
rather than the legacy one, which removes the cast the previous slice put on the
assembled response - the query already returns the sdk action's result, so the
two now type structurally.
`labeler.ts`'s three service reads move to the appview client and return
`app.bsky.labeler.defs` views, because `interpretLabelValueDefinitions` takes
the lexicon-typed view. `moderation-opts.tsx` reads `Client.appLabelers`
instead of `AtpAgent.appLabelers`: the lex static is already branded, so the
fallback labeler list satisfies `ModerationPrefsLabeler` without a cast.
`MutedWords` follows the prefs types: `expiresAt` is a `DatetimeString` now,
built with `toDatetimeString` rather than `Date.toISOString`, and
`sanitizeMutedWordValue` comes from `@bsky.app/sdk/utils`.
Point the moderation primitives - the label definitions, the cause/UI/decision
types and the label-info hooks - at `@bsky.app/sdk/moderation` instead of
`@atproto/api`.
The two implementations are mutually unassignable: the sdk's subject types are
the generated `#/lexicons` views, so their `did`/`uri`/`cid` fields are
branded (`DidString`, `AtUriString`) where the `@atproto/api` views type the
same fields as plain `string`. That rules out a partial swap - a decision made
by one implementation cannot be read by the other - so the whole moderation
layer moves together.
`lib/moderation/subjects.ts` is the transitional seam for the brand mismatch.
Every `moderate*` entry point is re-exported through a wrapper that widens its
subject parameter to accept a view from either world, because many read paths
still emit `@atproto/api` views while the moderation runtime only ever reads
`.did`, `.labels` and `.viewer` - none of which the brand affects. It is
deleted in the `@atproto/api` removal pass.
getOtherRequiredData's getPreferences read moves onto the sdk action, which
also unblocks fetchActorDeclarationRecord - its only caller - so the record
read moves to the pds client too.
The prefetch and refetch entry points now take the transport they need
rather than an agent: the appview client for getState and device signals,
the account client for preferences and the declaration record. The session
bundle still carries only an agent, so the three session call sites derive
both clients from it; the full bundle rework is a later slice. The standalone
config read stays on its own unauthenticated agent.
The preferences hooks, nuxs, labeler subscriptions, list mute/block, post
interaction settings, interests and live event preferences move onto
@bsky.app/sdk actions. Preference reads and writes route through the pds
client because they live on the account's actor store, not behind the
appview proxy; the list mute writes stay on the appview client, which is
where that graph endpoint lives.
BskyAgent.getPreferences configured the agent's labelers as a side effect,
so a labeler subscription took effect on the next appview read. The sdk
action does not, so the query now calls configureLabelers explicitly.
Exported hook signatures, query keys and the usePreferencesQuery response
shape are unchanged: the sdk's BskyPreferences is field-for-field identical
to the legacy one apart from branded strings, so the response is cast at
that single seam and the muted-word and nux mutation inputs stay
legacy-typed with a cast into the action.
The post-signup and onboarding writes (setPersonalDetails, upsertProfile,
overwriteSavedFeeds, setInterestsPref) move onto sdk actions over the pds
client, and the starter-pack and contact-import reads move to the lex
clients. Every upsertProfile call now writes a lex blob directly, so the
toLegacyBlobRef bridge has no remaining callers and is deleted.
like/repost/follow/delete and upsertProfile move off the bridge agent's
sugar methods onto @bsky.app/sdk actions over the pds client. The
mute/unmute and thread-mute writes route through the appview client, and
the profile reads move to the appview client behind their existing
legacy-typed hook signatures.
The two RichText classes are not mutually assignable - `UnicodeString` has a
private field and the SDK brands `did`/`uri` as template literal types - so
every producer and consumer of a RichText instance has to move in one step.
`detectFacets` now takes a lex client instead of the legacy agent, which is
what removes the last hard agent dependency from these files. Handle
resolution is an appview job, so the appview client is threaded in: through
`useAppviewClient` in the hooks and dialogs, and through a new
`appviewClient` option on `apilib.post` (Composer already had the client to
hand). The rest of the post pipeline still writes through the agent.
Facet feature checks move from the `AppBskyRichtextFacet` validators to the
generated `#/lexicons` schemas, matching how the rest of the app narrows
lexicon types.
Display sinks still read facets off `@atproto/api` view types, which are the
same lexicon but typed with plain strings. `asSdkFacets` widens them at those
call sites and goes away once the view types come from the SDK too.
aliased npm install of bsky-sdk-preview - it is where RichText and the
moderation helpers now live. its lex-* deps resolve to the copies the app
already uses, so there is a single @atproto/lex in the tree.
Samuel Newman