What Makes Personal Data Actually Portable?

"Portable" is not one property. It's three, and conflating them is the actual mistake: the one that lets a vendor say "your data is portable" while quietly meaning only one-third of that sentence. Before any claim about what Solidus Pod does or doesn't do, the three questions have to be separated:

Three identical padlocks in a row, each attached to a different icon, a document for format, a plug for protocol, a key for identity, with no visual distinction marking any lock as solved or unsolved.

① Format lock-in: can the data leave in a shape another system can read? ② Protocol lock-in: can it move through a channel other systems already speak? ③ Identity lock-in: is it tied to one identity system, or can that travel too? The three locks look identical here on purpose: this page will not pre-judge which one is open.

A system can answer "yes" to one and "no" to the other two, and a vendor that only talks about the one it solved isn't lying, exactly, it's letting you assume the other two came free. They don't. Each is separate engineering, with its own proof.

Format lock-in: can the data leave in a shape another system can read?

Format is about the bytes themselves. Solid's native answer is RDF, commonly serialized as Turtle. A graph-shaped, self-describing format that any Solid-aware tool can parse without knowing anything about who wrote it. That's a real, independently-designed answer to format lock-in, and it predates this product entirely.

Solidus Pod's own answer is smaller and more conventional. Its app-level data, the JWT+Postgres layer this product actually owns, is relational and JSON, not RDF triples. That's a real gap, not a rounding error: a JSON export from a Postgres row is portable in the ordinary sense (any system reading JSON can use it), but not in the RDF sense (a Solid-native tool expecting Turtle gets nothing useful without a translation step nobody has built). Locally, the Community Solid Server component this product runs does serve real RDF/Turtle, because CSS is unmodified upstream Solid software, but that's CSS's format answer, not one Solidus engineered.

Protocol lock-in: can it move through a channel other systems already speak?

Format answers "what shape is the data." Protocol answers "how do you ask for it." Solid's answer here is LDP, Linked Data Platform, a W3C Recommendation older than Solid itself, which defines containers, read/write semantics, and content negotiation that any LDP-aware client already knows how to use, without a custom integration.

Solidus's own bridge and API endpoints are a conventional REST API, request in, JSON out, no container semantics, no content negotiation against RDF media types. That's not "LDP running under a different name"; it's a different layer, doing a related job with different guarantees. A REST client can talk to it easily, but an LDP client, the kind that already exists for real Solid pods, gets nothing it recognizes. Where this actually gets tested is the deployed instance: curl -sI https://pod.solidus.network/ returns a Next.js frontend, not LDP headers: the LDP-speaking half of this stack runs locally against Community Solid Server, not yet in front of the public domain. Run pnpm install && pnpm start and curl -sI http://localhost:3101/ to see the real LDP + Accept-Patch headers CSS returns on its own; that's the fuller conformance picture, laid out in full on Solid Compatibility rather than repeated here.

Identity lock-in: does the data stay tied to one identity system?

The third question is separate from the first two: even if your data can leave in a portable format, through a portable protocol, is it still addressed by an identifier only one system recognizes? Solid answers this with WebID, a web address that resolves to an RDF profile, usable by any Solid-aware client, with years of real institutional deployment (the BBC, the NHS, the Flemish government) behind it.

Solidus answers it with did:solidus instead: a chain-anchored identifier, registered in the W3C DID Method Registry (a registry listing, not a W3C standard), with revocation enforced as a consensus rule rather than a document edit. That is a genuine architectural bet, not a proven superiority, and it is not this page's job to re-argue it: the full symmetric tradeoff, what each side gains and gives up, is worked through on WebID vs. did:solidus. What matters here is narrower: did:solidus does not resolve inside the Solid ecosystem the way a WebID does, and a Solid-native app expecting a WebID profile gets nothing usable from a did:solidus identifier without a bridge that, in production, is still architected rather than live.

The verdict, precisely

None of the three locks is a clean "solved." Sourced against the ledger on What's Actually Live in Solidus Pod and checked against the live instance on the day this was drafted (curl -sI https://pod.solidus.network/ returns a Next.js frontend, not LDP headers; curl -sI http://localhost:3101/ locally returns real LDP + Accept-Patch):

Format lock-in, partially open. Real RDF/Turtle exists, but only in the local Community Solid Server instance, not proven in production; the app-level data this product actually owns is JSON/relational, not RDF.
Protocol lock-in, partially open, same shape. LDP is real, locally, in unmodified CSS; the public-facing bridge and API layer is conventional REST, and CSS itself is not yet the thing answering requests at pod.solidus.network.
Identity lock-in, architected, not shipped. The did:solidus↔Solid-OIDC/WebID bridge that would let identity travel between the two systems is a planned, unchecked item, not a live production path today.

None of that rounds up to "solved" and none of it rounds down to "nothing here", CSS unmodified, running locally, is real, proven Solid software; the production bridge across all three locks is real, unfinished engineering. Both halves are true at once.

What this means, and what it doesn't

This is not a claim that Solidus Pod is fully portable, and it is not a claim that it isn't trying. It's a claim that "portable" needs three separate verdicts instead of one word, and that a vendor unwilling to give you all three separately isn't done answering the question. Solid solved personal data storage and access control, WebID, LDP, WAC/ACL, RDF, with real institutional deployments years before this product existed, and Solidus did not build any of it. Where this product touches Solid, it composes Community Solid Server, real software from that community, and layers one identity bet on top. The full shipped/planned ledger these three verdicts are drawn from lives on What's Actually Live in Solidus Pod; the fuller conformance treatment behind the protocol-lock-in section lives on Solid Compatibility.