Companion to REPORT.md (what to build into the api next). This file answers the other question: where does a JSS + plugins stack sit in the ecosystem, what's missing, and what's the realistic play? Written 2026-07, at 33 plugins / 386 tests.
One data plane, many protocol views. A single small Node process
where your data lives once — and Mastodon clients, Bluesky clients,
Element, CalDAV phones, IndieWeb editors, remoteStorage apps, aws-cli,
JMAP mail clients, nostr, and WebDAV mounts are all just views of the
same pod, each behind WAC. serve.js runs this today. Nothing else in
the ecosystem does.
| JSS + plugins | WordPress | Drupal | Nextcloud | |
|---|---|---|---|---|
| Core domain | personal data server (pods, WAC, identity) | CMS/publishing | CMS/framework | file sync + groupware |
| Plugin model | route-ownership + loopback; plugins cannot touch core's pipeline (measured, NOTES.md #564) | hooks/filters everywhere — plugins are pipeline modification | hook system, heavyweight | PHP apps, signed, runtime enable/disable |
| Ecosystem size | 33 | ~60,000 plugins, 20 years | ~50,000 modules, declining | ~300–400 apps |
| Marketplace / install | none — boot-time config (the #200 gap) | wp.org + one-click + auto-update | drupal.org | in-app store, occ app:enable |
| Admin | read side ✅ (admin/), write side impossible — each absence names a seam |
the gold standard | strong | strong |
| Identity | WebID / did:nostr / Bearer — protocol-grade | email+password | email+password | email+password, LDAP/SSO |
| Protocol reach | Mastodon, Bluesky, Matrix, AP, JMAP, DAV×3, S3, remoteStorage, Micropub, oEmbed, WebFinger, nostr — one pod behind all | RSS + REST | similar | DAV family, some AP via app |
The architecture comparison flatters JSS: WordPress's hook soup is exactly what the #564 line forbids, and it's why WP plugins conflict and are a security tar pit. But architecture has never been why WordPress wins. Distribution is.
Grouped by distance from what JSS actually is:
Same square — personal data servers with a protocol identity
| Project | Note |
|---|---|
| ATProto PDS (+ Tranquil, Cocoon) | closest live competitor for "PDS" mindshare; real momentum, genuinely easy self-hosting — but single-protocol |
| Solid siblings (CSS, Inrupt ESS, NSS) | spec-complete, app-light, a decade of that; none has a plugin ecosystem — that is JSS's differentiator within Solid |
| Nostr relays (strfry, nostream…) | event stores, no personal data plane; JSS embeds a relay as one plugin |
| remoteStorage / 5apps | near-dormant; remotestorage/ here may be among the more complete servers anywhere |
| Peergos | strong E2E-crypto story, weak protocol-bridge story |
Adjacent — self-hosted groupware/CMS: Nextcloud (the giant), ownCloud/oCIS, Seafile; WordPress/Drupal on the publishing side. They win on distribution and end-user UI, not architecture.
Adjacent — "run apps on your box" platforms: Umbrel (the app-store
UX bar), CasaOS/Cosmos (lowest-friction onboarding), YunoHost (best
operator experience — built-in SSO is what the api.isOperator finding
gestures at), Cloudron/Start9 (packaging-as-product), Sandstorm (the
philosophical cousin — capability-secure, effectively frozen, no
successor). Key structural difference: these run apps as isolated
containers side by side — apps don't share data. JSS is the inverse.
Adjacent — single-protocol servers people actually self-host:
Mastodon/GoToSocial, Matrix (Synapse/Conduit), Owncast, micro.blog.
Each is one protocol and one silo. The pitch to exactly these users:
one small process instead of five, one identity, one backup/.
It is not sparse because nobody noticed it. FreedomBox, Diaspora, Unhosted/remoteStorage, Sandstorm, arguably a decade of Solid itself — smart people kept entering this square and finding that technology was never the bottleneck. Demand and distribution were. Most people won't run a server; the ones who will already have opinions. An empty square can be an opportunity or a kill zone; this one has been both.
- The concept has mainstream legs. Bluesky made "PDS" a word. Nobody must explain why you'd want your own data server the way Diaspora had to in 2011.
- The homelab wave built the rails. Umbrel/CasaOS/YunoHost users already run boxes and browse app stores. The habit exists; be in the catalog.
- The build cost collapsed. What killed most graveyard projects was ecosystem starvation — years to twenty apps. This repo added eleven protocol implementations in a day, each ~one agent-session, findings included (AGENT.md is the contract that makes that repeatable). The historical moat — thousands of developer-years of plugins — deflates when plugins cost hours. This is the one structural trend running in our favor.
- Distribution — no marketplace, no one-click hosting, no auto-update. 90% of why WordPress is WordPress. (#200 + the runtime-lifecycle seam in REPORT.md.)
- End-user UI — everything here is protocol surface. WP gives a human a website; Nextcloud gives them files; a pod gives them a URL. Solid's decade-old killer-app problem.
- Identity UX — WebID/bearer beats passwords technically and loses at onboarding every time.
- Trust signals — 0.0.x versioning; no third-party-plugin security story (and plugins can intercept each other today — NOTES.md #9). A first four-axis internal audit is done (SECURITY.md) and the WAC-deferral pattern held, but third-party-plugin sandboxing and signing remain open.
- Bodies — one maintainer + agents vs. twenty-year communities. (But see "what changed", point 3.)
Not a WordPress/Nextcloud competitor. The realistic wedge, in order:
- Lead with the demo nobody else can run — one pod, every
protocol, live (
npm run serve, front door/admin/). This is the asset; Solid-the-spec is not the pitch. - Ride existing networks' onboarding — Bluesky PDS self-hosters and Nostr users are the two crowds already primed to run a personal server. Be the PDS that also does their calendar, files, mail.
- Get into the catalogs — one Umbrel/CasaOS/YunoHost app that replaces five. The rails exist; use them.
- Close the self-description loop — the four seams +
api.plugins(REPORT.md's order of work), then a registry/marketplace story, so the ecosystem can grow and describe itself. - Keep the findings discipline. The repo's real moat is not the 33 plugins; it's the measured, evidence-per-claim method that produced them and can produce the next 33.
An uncrowded space with a high body count, entered at the first moment all three historical causes of death — no demand, no distribution, no ecosystem — are weakening at once. The technology position is genuinely strong and the ecosystem-growth cost just dropped by orders of magnitude. The execution risk lives almost entirely in distribution and onboarding, not in anything built in this repo. That's a real shot.