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.
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.
The lex client throws XrpcResponseError, which is not an XRPCError
subclass, so the per-method error classes generated by @atproto/api no
longer match. Those instanceof checks compile fine but silently stop
firing, degrading every typed group failure to the generic fallback
message. Narrow against the method schema instead.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The lex client throws XrpcResponseError, which is not an XRPCError
subclass, so the old per-method error classes generated by @atproto/api
no longer match. Those instanceof checks compile fine but silently stop
firing, degrading every typed chat failure to the generic fallback
message. Narrow against the method schema instead.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
`getErrorName` erased the typed error classes by flattening everything to a
string code. Anchor on the classes instead: `LexAuthFactorError` for the login
2FA branch, `XrpcResponseError` for the signup error codes.
`@atproto/lex-client` stays a direct dependency because `XrpcResponseError` is
used at runtime for `instanceof`. It is already in the runtime graph via
`@atproto/lex-password-session`, so the direct declaration adds no bundle
weight; it makes the import legal under pnpm's strict layout and pins the
version so both packages share one `LexError` identity.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Samuel Newman