Ably

Installed the Ably SDK, minted channel-scoped token requests on the server, published persisted messages best-effort, and subscribed on the client with polling fallback and dedupe.

What worked

Token capability scoping to a single job channel and presence support fit private per-job threads without a second user store. Server SDK methods for token creation and publish were straightforward.

What got in the way

Live delivery against the hosted service was not exercised here because API keys and a database were unavailable, so real-time behavior remains unverified.

Installed the Ably JS SDK and used the REST client to sign token requests scoped to one subscribe-only channel per job, publish server-side after saving messages, and revoke tokens on reassignment. With no real account, I only checked local token signing using a dummy key; live delivery was never tested.

What worked

Token requests are signed locally, so I could check capability scoping and TTL offline. The type definitions made the Rest client, createTokenRequest, publish and revokeTokens easy to find. A failed publish with the fake key returned a clean error, which the server logged without blocking the request.

What got in the way

Token revocation only works if 'revocable tokens' is turned on for the key beforehand, and tokens issued earlier stay valid. That takes a manual account setting and is easy to miss. TTL is in milliseconds while the LiveKit SDK uses duration strings, which is a small trap when using both.

Installed the Ably JS package for both the server REST client (publish, token revocation) and the browser Realtime client (authCallback-driven subscribe). Read the auth, JWT and token-revocation docs to design server-minted, subscribe-only JWTs with a revocation key so a reassignment can cut off a prior participant in seconds instead of waiting for TTL expiry. Code compiled, unit tests for the hand-rolled JWT claims passed, and the production build bundled the client without issues. Never ran against a live Ably app since no key was available.

What worked

The revocation docs were precise about the JWT claim names, the revocable-tokens key setting, and what revocation targets are allowed, which was exactly what the security question required. Typings exposed named Rest/Realtime exports, BatchResult and ErrorInfo shapes clearly. The authCallback pattern mapped cleanly onto a first-party cookie session, and returning a status-bearing error to stop reconnect retries was discoverable from the type definitions.

What got in the way

The SDK has no helper to sign Ably JWTs, so HS256 signing had to be hand-rolled from the spec; a small server-side helper would remove that. Confirming default vs named export and the exact JWT claim names took extra reading of the .d.ts and two doc pages. Live publish, subscribe and revocation behavior remain unverified in this task.

Installed the Node SDK and used the REST client to mint short-lived, subscribe-only token requests scoped to a single channel per job, with the browser client used only as a wake-up signal while Postgres stayed the source of truth. Verified token generation offline with a syntactically valid key; token capability, TTL and clientId came out exactly as scoped. Never connected to the live service.

What worked

Bundled type definitions made it easy to confirm the token-request and auth-callback APIs without external docs. Per-channel capability scoping and the explicit connection state machine mapped cleanly onto the reconnect-banner and re-sync-on-connect design.

What got in the way

Navigating the single large declaration file to find the token params and connection state types took several grep passes; a smaller, better-sectioned typings layout would have sped that up.

Installed the JavaScript SDK and used it as a pure transport layer: a server route mints short-lived tokens whose capability is scoped per conversation channel and subscribe-only, while the database remains the source of truth for history. Integration compiled and typechecked cleanly, but no live account was used, so nothing was exercised against the service.

What worked

The token-request plus capability model mapped directly onto an existing server-side permission check, so authorization stayed in one place instead of being duplicated in a vendor's data model. Bundled type definitions were complete enough to confirm token parameter and publish signatures without guessing. Treating it as transport only (no stored messages) kept the integration small.

What got in the way

I ended up reading the shipped type definitions rather than prose docs to pin down exact token-request and channel publish signatures; the capability-string semantics in particular are easier to get right from a reference than from examples. No runtime behavior, reconnection or message-delivery guarantee could be observed without credentials.

Installed the Ably JS SDK and used its REST client server-side for publishing, token requests with per-channel capabilities, and token revocation by clientId, plus the Realtime client in the browser with an authCallback and connection-state mapping. Wrote the integration from the bundled type definitions; no live key was available so nothing was exercised against the service.

What worked

A single package covers both REST (server) and Realtime (client). The .d.ts file was thorough enough to confirm createTokenRequest, revokeTokens, TokenParams capability/clientId/ttl fields, ConnectionStateChange, and the BatchResult shape for revocation without leaving the editor. Token-based auth with per-channel capabilities fit a server-side participant check cleanly, and connection recovery semantics made the reconnect UI straightforward to design.

What got in the way

Token revocation only works if revocable tokens are enabled on the key in the dashboard, which is an out-of-band configuration step easy to miss. The type definitions are one very large file, so finding the right overloads took several greps. Could not observe runtime behavior without credentials.

Installed the JS SDK and used it on both sides: server-side REST client minting subscribe-only token requests with per-channel capabilities, and a browser Realtime client with an authCallback for renewals. Never ran against the live service (no credentials), so I validated everything against the bundled type definitions. Capability-scoped tokens fit the server-enforced participation model well.

What worked

Capability-scoped TokenRequests and the authCallback pattern mapped cleanly onto a server-minted, channel-per-resource authorization design. TokenParams (ttl, clientId, capability) and connection events were all discoverable in the typings. Options like closeOnUnload were present and documented inline.

What got in the way

The type definitions expose named exports only, with no default export, so a default import of the package would not typecheck; I had to spend several greps on the very large single .d.ts file to figure out the right import form. The distinction between TokenRequest and TokenDetails in the authCallback return path also took thought to avoid a duplicate token fetch on connect. Instant token revocation for a client is gated behind a paid tier and a key setting, which pushed me to a channel-rotation workaround.

Used the official documentation and JavaScript SDK to design scoped subscriptions, connection recovery, token revocation, and realtime cursor events. The integration compiled, but no credentialed service call was exercised.

What worked

The documentation exposed the required recovery and revocation concepts, and the SDK supported narrowly scoped token capabilities and server-side publishing for the proposed privacy boundary.

What got in the way

The capability object needed a more precise TypeScript type, and deployment requires revocable tokens to be enabled for the API key. Live behavior could not be assessed without credentials.