Goal

Sister issue to #515 (Phanpy). Make JSS speak enough of the Mastodon + Pleroma API surface that Soapbox can sign in to a pod and use it.

Soapbox is a feature-rich web client originally built for Pleroma/Akkoma, also Mastodon-API compatible. Heavier UI than Phanpy, broader feature set (custom emoji, quote posts, chats, polls, groups), AGPL-3.0 licensed.

Why a separate issue

Most of the work is shared with #515 — Phase 1 of the Phanpy shim covers the core Mastodon REST endpoints Soapbox also uses. This issue scopes the delta: extra endpoints, Pleroma-specific extensions, and the architectural questions Soapbox raises that Phanpy didn't.

What's different vs Phanpy

The Pleroma extensions are the only material extra work. Skipping them gets ~85% of Soapbox functional (it gracefully degrades when the server doesn't expose them — Soapbox works against Mastodon servers today, and Mastodon has no Pleroma extensions either).

License consideration

Soapbox is AGPL-3.0. That changes the embed calculus vs Phanpy (MIT):

• Linking only (links.jsonld opens the hosted Soapbox UI in a new tab) → no license obligation.
• Embedding/bundling Soapbox into a Solid app on the pod → AGPL would attach. Anyone running it serves source-availability obligations under network use.

If the suite is AGPL-friendly (solid-apps already is, AGPL-3.0-only), bundling is fine. If we ever want a permissive option to ship alongside, Phanpy is the cleaner choice; Soapbox is the richer one.

Recommendation

• Use Feature: Mastodon-API shim — make JSS work as a backend for Phanpy (and every other Mastodon client) #515's shim as the foundation; both clients work against it once Phase 1 lands.
• Phase 1.5: add /api/v1/custom_emojis, conversations, markers — small additional work that benefits Soapbox without changing the Phanpy story.
• Pleroma extensions: park behind a flag or skip entirely. Soapbox degrades gracefully and the marginal feature gain isn't worth the API surface.

Success criteria

A user opens Soapbox at e.g. soapbox.pub, enters their pod URL as the server, authenticates via OAuth, sees their home timeline, posts, sees realtime updates. Pleroma-only features (quotes, reactions, chats) are absent — same as connecting Soapbox to a vanilla Mastodon instance today.

Notes

• Same big leverage point as Feature: Mastodon-API shim — make JSS work as a backend for Phanpy (and every other Mastodon client) #515: a shim that supports the Mastodon API tier unlocks Soapbox, Phanpy, Elk, Tusky, Ivory, Ice Cubes, and the Mastodon stock UI at once.
• Soapbox is a useful "stretch target" — if the shim is good enough for Soapbox, it's good enough for everyone in the ecosystem.