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.
`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 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>
Samuel Newman