Field guide · September 2026 · Personal data stores

The Personal Data Store Landscape, Compared Honestly

Fourteen projects that set out to give people — not apps — ownership of their data. Most of them are dead. Here is what each one actually is, what it got right, and where it falls down.

Disclosure. I am the author of Enbox, one of the projects compared here. It is evaluated under the same standard as everything else — including a full list of its weaknesses. Every status claim is sourced and dated; see the methodology. If something here is wrong, the correction is welcome.

The short version

If you only read one section, read this one.

Status board

Who is still standing, as of September 2026. "Dead" below means the stewarding organization is gone or unresponsive — several of these codebases remain public and forkable.

Maintenance status, verified against repos and announcements in September 2026
ProjectStewardStatusEvidence
Enboxenboxorg enboxorg (small independent org) Research preview Active development; self-declared "not production ready," unaudited, preview nodes may be wiped.
AT Protocol PDSBluesky Bluesky Social PBC Active · production Repos pushed within days of writing; ~43M accounts reported on the network (April 2026).
SolidCSS / Inrupt ESS ODI (community) · Inrupt (commercial) Active Community Solid Server actively maintained; Inrupt ESS 3.0 shipped May 2026; Solid Symposium 2026 in London.
Cozy Cloudnow Linagora Linagora (since May 2025) Active Original company liquidated Feb 2025; assets acquired by Linagora May 2025; cozy-stack pushed Sept 2026.
MeecoSVX Meeco Planet Pty Ltd Active · commercial Enterprise credential/vault infrastructure; eIDAS 2.0 ecosystem participation; 2025–26 programs and awards.
remoteStorage Volunteer community Active · low intensity IETF draft-27 (June 2026); client v2.0.0-beta.10 (Aug 2026) — the 2.0 rewrite has been in beta for years.
Perkeep Volunteer community Intermittent v0.12 (Nov 2025) ended a five-year release gap; last push Feb 2026; 400+ open issues.
Personium Personium Project (Fujitsu origin) Dormant Last release v1.8.3 (Nov 2022); core repo untouched since March 2023; not archived but unmaintained.
digi.me Digi.me Ltd Dormant · unclear Consumer app discontinued years ago; B2B pivot; site live but minimal public activity; status unverified.
Web5 / DWN-SDKBlock · TBD None (was Block/TBD; repos at DIF) Abandoned upstream Block shut down TBD Nov 2024; repos dormant since Sept–Oct 2024; DWN spec a stalled DIF draft.
FissionWNFS / UCAN None (UCAN inherited by ucan-wg) Shut down Apr 2024 Founder-confirmed shutdown; domain dead; UCAN lives on via the community working group (Storacha et al.).
CeramicComposeDB Recall Labs (pivoted) Pivoted 2025 3Box Labs merged into Recall Labs, pivoted to AI-agent tokens; ComposeDB deprecated; Ceramic One node survives as open source.
Verida Verida Pty Ltd Unresponsive Repos stale since Feb 2026; all project domains fail DNS as of Sept 2026; no formal shutdown notice found.
Nextcloudadjacent, not a PDS Nextcloud GmbH Active Very active, widely deployed — included as the self-hosting baseline people reach for instead of a PDS.

The comparison matrix

The dimensions that actually differentiate these systems. Cells are deliberately terse — the profiles below carry the nuance.

Technical comparison · scroll horizontally
Project Identity Data model Encrypted at rest? Access control Self-hosting Stack & license
Enbox DIDs (did:dht default; jwk/web) Typed JSON records under declarative protocols; local DWN + sync to remote nodes Yes — protocol-level, per record type (key agreement + JWE); local vault encrypts keys Protocol rules + permission grants with delegated decryption keys; revocation follows sync Yes — Docker; SQLite/MySQL/PostgreSQL Bun/TypeScript · Apache-2.0
Web5 / DWN-SDK DIDs (did:dht default) Records under protocols; DAG-CBOR/IPLD; query filters Yes (designed) — per-message keys, HKDF along protocol paths, X25519/AES-GCM Protocol $actions rules, roles; permissions protocol largely unfinished Embeddable TS server (LevelDB); no surviving hosted service TypeScript (+ dormant Kt/Go/Swift/Rust) · Apache-2.0
Solid WebID + Solid-OIDC RDF / Linked Data in LDP containers No — pod operator sees plaintext; client-side encryption breaks server features WebACL / ACP, per-resource (not per-field) Yes — CSS (MIT) via npx/Docker; enthusiast-grade TypeScript (CSS), proprietary ESS · MIT / commercial
ATProto PDS did:plc (Bluesky-run directory) or did:web Signed repository: Merkle Search Tree of records typed by Lexicons; blobs by CID No — public by design; "Spaces" add ACLs, explicitly not encryption OAuth 2.1 profile; repo is world-readable Yes — excellent; Docker installer, cheap VM, CAR export, account migration TypeScript + Go · MIT/Apache-2.0
remoteStorage user@host via WebFinger Folder/document tree; JSON docs + binaries; per-category conventions No — plaintext on server; TLS in transit only OAuth bearer tokens scoped per category (r/rw) Yes — Armadietto (Node), php-remote-storage, 5apps hosted JavaScript · MIT (client); Armadietto has no license file
Cozy Cloud Instance account (email, 2FA); OAuth2 for apps CouchDB JSON docs typed by "doctypes"; Mango queries; virtual FS Partial — Cozy Pass is zero-knowledge (Bitwarden-compatible); files/doctypes are not E2E Per-doctype permissions declared by apps; sandboxed konnectors Yes — Go server + CouchDB, Docker image Go + JS/TS clients · AGPL-3.0
Perkeep Local keys (age; historically GPG) — no global identity Content-addressed blobs; permanodes + signed claims; search index Optional — client-side encrypted blob storage (age, v0.12) Single-user model; whole-server auth; per-item share links Yes — exclusively; single Go binary Go · Apache-2.0
Personium Cell per person; accounts/roles; PKI trans-cell tokens Boxes per app; WebDAV collections + OData structured data No — HTTPS/PKI in transit, XML token signatures Role-based ACLs within and across cells Yes — Java/Tomcat + Elasticsearch, Docker/Ansible Java · Apache-2.0
Verida DIDs (custom did:vda, Polygon-anchored) Encrypted JSON datastores per app context; CouchDB-style replication Yes — NaCl keys, user-held keyring Consent-based app access per context Partial — open-source storage node (stale since Apr 2025) TypeScript · ISC
Ceramic DIDs (did:pkh, did:key) Append-only signed event streams; ComposeDB added GraphQL models (dead) No — streams public unless apps add encryption Authorship signatures; no read ACLs at protocol level Yes — Ceramic One (Rust node) is now the only way to run it Rust node + JS client · MIT
Fission did:key + UCAN capability tokens WNFS: encrypted, content-addressed file system on IPFS (file-centric) Yes — zero-knowledge private partition, client-side keys UCAN capability delegation (lives on via ucan-wg) Protocol open; polished DX depended on the dead hosted service TypeScript/Rust/Haskell · Apache-2.0
Meeco W3C VCs + DIDs; OpenID issuance/presentation; eIDAS 2.0 aligned Encrypted vault + verifiable-credential exchange (SVX) Yes — zero-knowledge E2E vault Consent flows, enterprise key management Commercial — "your cloud, on-prem, or managed" Proprietary (some open SDKs)
digi.me Account-based; consent certificates Personal data library; normalized imports (health, finance, social) Yes — client-side encryption, user-held keys Purpose-limited consent-based sharing No — hosted platform, proprietary Proprietary
Nextcloud Server account (SSO/LDAP optional) File-centric: WebDAV files, calendar, contacts, apps Mostly no — optional server-side encryption; E2E app covers designated folders only Server-side share permissions; admin-trust model Yes — the category benchmark; huge ecosystem PHP (+ Go components) · AGPL-3.0

Profiles

Same format for every project — strengths and weaknesses alike. Enbox goes first because it is the subject of this page, not because it wins.

The subject

Enbox

Research preview enboxorg · Bun/TypeScript · Apache-2.0 · repo

A Decentralized Web Node (DWN) stack: a high-level SDK with typed protocols, a headless auth layer, an agent runtime with an encrypted identity vault and bidirectional sync, and a self-hostable multi-tenant DWN server with SQL backends. Apps define portable record schemas and access rules; users hold DIDs (did:dht by default) and choose their DWN endpoints; records marked encryptionRequired are encrypted at the DWN layer, and sync converges data across a user's devices and permitted apps.

Strengths

  • Encryption at rest is a protocol feature, not an app afterthought — the clearest design differentiator in this field now that Verida and Fission are gone.
  • Portable identity without a central directory: did:dht needs no Bluesky-style plc.directory equivalent.
  • Multi-device sync and delegated, revocable read grants are built into the agent, not left to each app.
  • Self-hostable server on standard SQL (SQLite/MySQL/PostgreSQL); Apache-2.0 throughout.
  • Actively developed with a coherent monorepo: SDK, auth, agent, server, CLI, codegen.

Weaknesses

  • Self-declared research preview: APIs break, preview nodes can be wiped, code is not externally audited. The README itself says not to store sensitive or irreplaceable data.
  • The DWN specification it implements is a stalled DIF draft whose original steward (Block's TBD) shut down in 2024 — Enbox is now effectively the only active implementation of an orphaned spec, and is diverging from it alone.
  • One small organization; bus factor is real and there is no ecosystem of third-party apps or hosted nodes to fall back on.
  • Bun/TypeScript only — no Kotlin, Swift, Go, or Rust SDKs, so mobile and non-JS stacks are out.
  • Permission revocation is enforcement-on-sync: a revoked grantee keeps access until the revocation record reaches them. Key recovery and identity UX are unproven with real users.
  • No adoption numbers to point to — it is a bet, not a network.

Still standing

AT Protocol PDS

Active · production Bluesky Social PBC · TypeScript/Go · MIT/Apache-2.0 · atproto.com

The personal data server of the AT Protocol: each account is a signed repository — a Merkle Search Tree of records typed by Lexicons — hosted on a PDS of the user's choice, with did:plc/did:web identity, OAuth 2.1 authorization, CAR-file export, and a designed account-migration flow. Third-party apps write their own Lexicon collections into the same repo, so it functions as a general (if public-oriented) personal data store, at production scale.

Strengths

  • The only PDS here with mass adoption: tens of millions of accounts, independent infrastructure (Blacksky, alternative relays), and repos pushed daily.
  • Best-in-class exit story: CAR export plus documented account migration, including the "credible exit" path from an uncooperative host.
  • Self-hosting is genuinely first-class — Docker installer on a cheap VM.
  • Self-certifying data: signed commits make records verifiable wherever they travel.

Weaknesses

  • Public by design. Repository contents are unencrypted and world-readable; private data lives outside the protocol's core model, and the newer "Spaces" add access control explicitly without encryption.
  • did:plc's directory is operated centrally by Bluesky PBC — a known and acknowledged centralization point.
  • Spec governance sits with Bluesky PBC; there is an IETF draft but no completed standard.
  • federation is real but Bluesky's Relay/AppView dominate in practice; non-social use cases are early.

Solid

Active ODI / Inrupt · TypeScript (CSS) · MIT / commercial · solidproject.org

Tim Berners-Lee's web-decentralization protocol: users keep data in "pods" (Linked Data containers), apps request access rather than holding the data. Identity is WebID + Solid-OIDC; access control is WebACL or ACP; the open-source Community Solid Server (MIT) is the main self-host path, with Inrupt's proprietary ESS powering enterprise deployments — most notably the Flanders data utility Athumi.

Strengths

  • Strongest institutional backing in the field: ODI stewardship, a W3C working group (Linked Web Storage), and a real government-scale deployment in Flanders (diplomas, credentials, health-research consent).
  • A decade of spec work and multiple independent server implementations.
  • Web-native: everything is a dereferenceable URI, so pod data links into the broader web.

Weaknesses

  • Pods are plaintext to the pod operator — privacy from your host is contractual, not technical. Encrypting client-side breaks the server-side Linked Data features that justify Solid in the first place.
  • RDF/Linked Data imposes real developer cost; there is no server-side query layer, so apps cache and index client-side with no transactional guarantees.
  • Authorization is per-resource, not per-field; app interoperability remains largely aspirational.
  • Still not a W3C Recommendation — the LWS working group missed its charter deadline and was extended into 2027. The headline "6.5M Flemings" is an addressable population, not measured active users.

Cozy Cloud

Active · new owner Linagora · Go + JS · AGPL-3.0 · cozy.io

A French personal cloud that aggregates your data — bank statements, utility bills, health records — via sandboxed "konnectors" into one per-user server, with apps for files, photos, contacts, and a zero-knowledge password manager (Cozy Pass, Bitwarden-compatible). The original company went through receivership (2024) and judicial liquidation (Feb 2025) before Linagora acquired the assets in a court-supervised sale (May 2025); development continues under the Linagora org.

Strengths

  • The most consumer-complete product here: aggregation, apps, sync, and a password manager in one stack.
  • Cozy Pass is genuinely zero-knowledge; konnectors run sandboxed server-side with per-doctype permissions.
  • Self-hostable (Go + CouchDB, Docker) and AGPL — survived its own company's death, which says something about open licensing.

Weaknesses

  • Corporate near-death: liquidation and acquisition is a reminder that the hosted service depends on a small company's fortunes; it is now being folded into Linagora's Twake suite.
  • Only the password vault is end-to-end encrypted — files and doctypes are plaintext to the server; credentials handed to konnectors have a controlled server-side decryption path.
  • Primarily a French-market product; smaller ecosystem than Nextcloud.
  • Identity is an instance account, not a portable identifier — leaving your host means exporting, not pointing your identity elsewhere.

remoteStorage

Active · low intensity Volunteer community · JavaScript · MIT · remotestorage.io

The oldest open protocol in the list (2011, "unhosted" movement): unhosted web apps store per-user JSON documents on a server of the user's choice, discovered via WebFinger from a user@host address, authorized by OAuth bearer tokens scoped per data category. Deliberately minimal — a folder tree, ETags, and a /public subtree.

Strengths

  • Radically simple — a developer can understand the whole protocol in an afternoon, and apps genuinely are unhosted.
  • Fifteen years of continuity; spec still moving (IETF draft-27, June 2026) and client still releasing.
  • Multiple independent servers (Armadietto, php-remote-storage, 5apps hosted).

Weaknesses

  • No encryption at the protocol level — your storage provider reads everything.
  • No queries, relations, or sync semantics; per-category bearer tokens are the entire permission model.
  • The 2.0 client rewrite has been in beta for years; the ecosystem is a niche enthusiast circle.
  • Armadietto, the main community server, has no license file — a real adoption hazard.

Perkeep

Intermittent Volunteer community · Go · Apache-2.0 · perkeep.org

Brad Fitzpatrick's "personal storage system for life" (née Camlistore): content-addressed blobs with a schema layer of permanodes and signed claims, importers for third-party services, full-text search, and optional age-encrypted blob storage. Single-user by design — it is a vault for one person's lifetime of data, not a multi-tenant app backend.

Strengths

  • Architecturally principled: content addressing, signed claims, and optional client-side encryption that keeps the server blind.
  • Self-hosting is the whole point — a single Go binary; v0.12 added Tailscale/tsnet for private networking.
  • Influential design; 7k+ GitHub stars.

Weaknesses

  • Sporadic maintenance: a five-year release gap (2020–2025), 400+ open issues, and no predictable cadence.
  • Single-user model — no meaningful multi-app permission system; sharing is per-item links.
  • For technical users only; there is no app ecosystem writing to your Perkeep.

Meeco

Active · commercial Meeco Planet Pty Ltd · Proprietary · meeco.me

Sydney-based enterprise company (founded 2012) selling verifiable-credential infrastructure (SVX) and a zero-knowledge, end-to-end-encrypted digital vault. Aligned with eIDAS 2.0 / EUDI Wallet and the MyData movement; the rare PDS-era company that is unambiguously alive — because it went enterprise and proprietary rather than open protocol.

Strengths

  • Solvent, active, and aligned with the biggest regulatory tailwind in identity (eIDAS 2.0).
  • Genuine zero-knowledge vault with enterprise key management and certifications (ISO 27001).

Weaknesses

  • Proprietary SaaS — "self-hosting" means an enterprise contract, not a docker-compose file; no open protocol or community.
  • Focused on credential exchange rather than a general app-data store for arbitrary applications.

Gone, dormant, or pivoted

Web5 / DWN-SDK (Block · TBD)

Abandoned upstream was Block/TBD · TypeScript · Apache-2.0 · repo

The reference implementation of the Decentralized Web Node spec — the same lineage Enbox continues. Block shut down its TBD division in November 2024; the repos moved to the Decentralized Identity Foundation org and have been dormant since autumn 2024 (not archived, but unmaintained). The DWN spec remains a draft that its DIF page still calls an "active work item," despite no substantive commits since September 2024.

Strengths

  • The design work is real: protocol-scoped encryption with HKDF key derivation, declarative protocols, DID-native identity — much of it carried forward in Enbox.
  • Apache-2.0 code across five language SDKs, all forkable.

Weaknesses

  • No steward, no hosted service, no maintainers — 45+ open issues on dwn-sdk-js with no one to triage them. The permissions protocol was left largely unfinished.
  • A cautionary tale for the whole category: even a well-funded effort from a public company can vanish in a quarterly letter.

Fission (WNFS / UCAN)

Shut down Apr 2024 was Fission Codes Inc. · TS/Rust/Haskell · Apache-2.0

Vancouver startup building user-owned-data infrastructure: UCAN capability tokens and WNFS, an encrypted, content-addressed file system on IPFS with a genuinely zero-knowledge private partition. The company shut down in April 2024 (founder-confirmed); the domain is dead. UCAN outlived it — the community working group maintains v1.0 in production use at Storacha — while WNFS itself has no active maintainer.

Strengths

  • Proved zero-knowledge hosting could be a polished developer experience, and produced UCAN — the one artifact here that escaped its company's death.

Weaknesses

  • The polished DX depended on the hosted service, which died with the company; file-centric model never grew a structured-data app ecosystem.

Ceramic / ComposeDB

Pivoted 2025 3Box Labs → Recall Labs · Rust/JS · MIT · Ceramic One

The dominant "Web3 data" stack of 2021–2023: DID-authored, append-only signed event streams, with ComposeDB's GraphQL models on top. 3Box Labs merged with Textile into Recall Labs (Feb 2025), then pivoted to an AI-agent token network and deprecated js-ceramic and ComposeDB (Apr 2025), shutting down the hosted anchor service. The Rust node, Ceramic One, survives as MIT open source with best-effort maintenance.

Strengths

  • Elegant stream/reconciliation protocol (Recon); Ceramic One runs with no dependency on the company's infrastructure.
  • Honest, well-documented deprecation with migration guidance — a more graceful exit than most.

Weaknesses

  • The company left personal data entirely; ComposeDB apps were told to migrate or break.
  • Streams are public by default — encryption was always the app's problem.
  • The ecosystem (Orbis, Geo, Passport stamps) largely died or migrated with the pivot.

Verida

Unresponsive Verida Pty Ltd · TypeScript · ISC · GitHub org

Australian project offering encrypted, user-owned document databases scoped per application "context," with NaCl keys held by the user, CouchDB-style replication between storage nodes, and a mobile Vault app — architecturally the closest recent sibling to Enbox's encrypted-data thesis. As of September 2026: repos stale since February, all project domains fail DNS resolution, and the VDA token trades near zero. No formal shutdown notice was found, but the project appears to have quietly collapsed.

Strengths

  • Showed real demand for the encrypted-per-context data model — its data connectors into Google/Fitbit/Strava were genuinely useful.

Weaknesses

  • Token-funded economics didn't sustain the network; custom did:vda method tied identity to a chain ecosystem; adoption stayed grant-driven.
  • Disappearing without a shutdown notice strands users — the exact failure mode personal data stores are supposed to prevent.

Personium

Dormant Personium Project (Fujitsu origin) · Java · Apache-2.0 · personium.io

MyData-aligned open-source PDS server from Fujitsu Labs: a "cell" per person containing per-app "boxes," WebDAV for files and OData for structured data, with PKI-signed tokens for cross-cell access. Won MyData Operator awards in 2020–21; last release November 2022, core repo untouched since March 2023.

Strengths

  • Sophisticated cross-cell trust model, years ahead of most; real government/enterprise pilots in Japan.

Weaknesses

  • Dormant and effectively unmaintained; heavyweight Java/Tomcat + Elasticsearch stack; never gained international developer traction (91 stars).

digi.me

Dormant · unclear Digi.me Ltd · Proprietary · digi.me

One of the original commercial PDS plays (founded 2009 as SocialSafe): a client-side-encrypted "personal data library" with user-held keys and consent-based sharing to apps. The consumer app was discontinued years ago in a B2B pivot; the website is live but public activity is minimal, and the company's current operating status could not be verified as of September 2026.

Strengths

  • Historically credible: health-data integrations, an Icelandic health-records pilot, and a real consent architecture with zero-knowledge design.

Weaknesses

  • Fully proprietary platform; consumer product gone; no self-hosting, no open protocol — users depend entirely on the company's continued existence.

Adjacent — the practical alternative

Nextcloud

Active Nextcloud GmbH · PHP/Go · AGPL-3.0 · nextcloud.com

Not a PDS, but the thing most people actually deploy when they want their data back: a self-hosted file sync and collaboration suite. Included because any honest comparison has to admit that for "my files, my server," the boring incumbent wins today.

Strengths

  • Massive deployments, mature apps, huge ecosystem, and a sustainable company. It works, today, at every scale from Raspberry Pi to government.

Weaknesses

  • File-centric, not a structured app-data store; identity is a server account that doesn't travel with you; and the trust model is admin-centric — whoever runs the server can typically read the data, with E2E encryption covering only designated folders.

So which one should you use?

Honest guidance, including the cases where the answer is not Enbox.

You need production scale and real users today
AT Protocol PDS — if and only if your data can be public. Nothing else in the field comes close on adoption, exit story, or self-hosting polish.
You need institutional backing and a standards track
Solid — the W3C path, the Flanders deployment, and Inrupt's enterprise support are real. Budget for the RDF learning curve and accept that your pod host sees plaintext.
You need encrypted-at-rest application data with portable identity
Enbox is one of the only designs left standing that does this — the others (Verida, Fission) are gone. But it is a research preview: build on it to learn or to bet, not to store anything you can't lose. Audit the code yourself before trusting it.
You want the simplest possible unhosted web app
remoteStorage — an afternoon to learn, fifteen years old, and still breathing.
You want a consumer personal cloud that pulls your data in
Cozy — files, photos, passwords, and bank aggregation in one self-hostable stack, now under Linagora.
You want your files and photos under your own roof, nothing more
Nextcloud, and don't overthink it. Or Perkeep if you're technical and think in decades.
You're an enterprise needing verifiable credentials and encrypted vaults
Meeco — the only solvent commercial survivor, precisely because it sells to enterprises rather than waiting for a consumer revolution.

What the graveyard teaches

Five of the fourteen projects here are dead or dormant. The pattern is consistent:

Methodology & sources

Compiled September 2026. Maintenance-status claims were verified against live GitHub API data (push dates, releases, issue counts), company announcements, and press coverage. "Encrypted at rest" means the host cannot read stored data by design — not TLS in transit, which everything has. Enbox's claims are drawn from its own repository documentation, including its self-declared research-preview warning. Where a status could not be verified (digi.me, Verida's corporate state), that uncertainty is stated rather than smoothed over. Errors and corrections: open an issue.

  1. TechCrunch — Block shutters TBD (Nov 2024)
  2. decentralized-identity/dwn-sdk-js (dormant since Oct 2024)
  3. DWN specification (DIF draft)
  4. DIF — DWN Community Node announcement
  5. AT Protocol — repository spec
  6. AT Protocol — cryptography ("data encryption is not used directly in the protocol")
  7. ATProto Spaces alpha (ACLs, not encryption)
  8. bluesky-social/pds self-hosting
  9. did:plc method (acknowledged centralization)
  10. ODI becomes Solid's organizational home (Oct 2024)
  11. W3C Linked Web Storage WG charter
  12. LWS WG recharter (deadline extension into 2027)
  13. Community Solid Server (MIT)
  14. Inrupt — Flanders/Athumi case study
  15. Peer-reviewed security/privacy assessment of Solid
  16. Leigh Dodds — "Baffled by Solid" (granularity, query critiques)
  17. remoteStorage IETF draft (draft-27, June 2026)
  18. remotestorage.js (v2.0.0-beta.10, Aug 2026)
  19. Linagora — Cozy Cloud acquisition (May 2025)
  20. Cozy Pass zero-knowledge / Bitwarden-compatible docs
  21. linagora/cozy-stack
  22. Perkeep (v0.12, Nov 2025)
  23. Boris Mann — "We shut down Fission as of April 2024"
  24. UCAN working group (active)
  25. Ceramic — "The future of Ceramic: focusing on Recall" (Apr 2025)
  26. Ceramic One (rust-ceramic)
  27. Verida GitHub org (stale since Feb 2026; domains failing DNS, Sept 2026)
  28. Personium core (dormant since Mar 2023)
  29. Meeco / SVX
  30. Enbox (research-preview warning, architecture docs)