When I looked at IPFS, briefly, over a year ago, encryption was not (yet) supported and was raised in that community as well. I haven’t checked since or now but I think if a future NSS can have the option to write to an encrypt-able IPFS node that would be my preferred solution as encryption would be completely transparent to NSS.
Encrypting/decrypting content on client side only would be safe, right? Downside is that there would need to be a separate mechanism to deliver decryption key to all parties who have access to content.
There is no reason why non-technical people can’t setup their own POD if it is designed with them in mind.
I have no idea how my TV works, but have no trouble using it.
I have no idea, how MS Windows code works, but have no trouble using my laptop.
I have no idea how my radio works, but have no trouble turning it on and tuning to a radio station.
I have little idea how a car engine works, but I have passed the advanced driving test.
So complicated technology is not a problem provided design makes it easy for people to use.
That is the real challenge for those designing Solid.
4 Likes
I agree with all this [cough] but am skeptical that this is how things will develop because there are other models already changing things.
Firstly we have the centralised service model which is of course what we are trying to change. So we require businesses to develop a decentralised alternative along the lines you suggest, and to be able to compete and take business away from the already powerful entrenched incumbents.
I don’t accept that because it happened with TVs and cars etc it will inevitably happen with pods. How would you have created a centralised car industry without the Internet? Things are different now, and that’s why we are trying to change them. Pods are easy to centralise, cars less so, although I believe we may be seeing the beginnings of that.
At the same time we see incumbents like Facebook habitually buy up the businesses that would compete with them (cf Instagram and WhatsApp) in order to retain their dominance.
And we see centralisation spreading into new domains with the help of Internet technology. The so called ‘sharing’ economy (Uber, Airbnb) turns individual assets into centralised markets where the asset owners and workers have less power than ever and the service provider is in control of the terms, fees etc. This battle is just starting, but serves here to illustrate that because we want big business to help us decentralise, we cannot expect it to happen unless it serves big business.
I’m not saying there won’t be any decentralising pod businesses, but I can’t see how they can impact the ecosystem at scale. I think any that grow will be bought out (to the delight of those who set them up with VC investment).
Others may have ideas about this which I don’t understand, but I’m not able to see for myself how pods can decentralise things at scale.
Wishful thinking plays its part and is useful in that it inspires us to try. So I’m not saying give up, I’m saying don’t just expect this to happen because it happened with cars or TVs - recognise it is a tough challenge and don’t neglect that aspect.
So this is my challenge to everyone who believes in this approach! How can we ensure this happens? What’s the mechanism and how do we help it to work? I don’t have answers to that, which is of course why I’m still helping to put Solid on SAFE Network.
6 Likes
Very interesting read about encryption and the lack of it. Next to that I want to add to this: what about phishing? Because the ability to share data with whoever you want, makes it very easy to just create a look-a-like trusted Solid client app, where when authorizing, complete access to all data is acquired. 
Just curious. Has there been any developments in what you suggested POD encryption, Verifiable Claims, ZKPs, etc. ?
I am probably way behind the times with this, as it is 2024. I think it would it would be nice to see some process for versioning and labeling, key management to support Provenance. Also libp2p to allow for multiple means of Transport. Sorry for the shotgun spray of ideas, but this the first piece of something technical, I have inquired about.
Hello.
Here is some literature and implementations I have encountered in my studies so far.
Libertas at Oxford This one is excellent, I do not know Rui’s handle, but they are in some of the weekly Solid meetings. I think in the Solid Practitioner’s Group call.
Solid Verifiable Credentials @ kezike did this work, it is very good and still relevant, if a bit old.
SISSI at Karlsruhe Also a very good paper and modern
1 Like
Rui = @renyuneyun.
1 Like
Thanks. The idea of the incorporation of MPC in to Solid sounds like a step in the right direction. My view is whatever can be added in the furtherance of extreme privacy, should be the default. Make that the gold standard, then pair back to whatever level of risk is indicated, ie. encrypt at rest any PII while my current list of YouTube music videos is in the clear. All done at the decisions of the RP and the User. I still haven’t found any references to JSON LD BBS+ in what I have read about Solid. Hopefully it is something obvious that I have yet to find.
1 Like
Two years late to the April 2024 revival, but this thread directly asks a question that now has a working implementation, so it seemed worth linking.
The approach that ended up working: client-side encryption using the browser’s native WebCrypto API, storing encrypted blobs in a regular pod container alongside an opt-in plaintext RDF sidecar for indexing. The key material lives on the pod as a wrapped keystore, not on the provider’s servers. Standard AES-256-GCM for payloads, ECDH key agreement for delegation between apps.
The limitation NoelDeMartin raised in the discussion thread is real: encrypted data isn’t interoperable with apps that don’t implement the same protocol. That’s a genuine trade-off, not a solved problem — the vault is for the subset of data where you explicitly want to prioritise privacy over portability.
The SDK is open source at pod42/PDPVault-SDK — five TypeScript files, no dependencies — if anyone wants to see how the key derivation and delegation are structured, or wants to implement compatible readers in another project.
1 Like
Would you be able to describe the RDF sidecar in more detail?
I’m referring to this comment:
What is the content of this plaintext RDF document? What is its main purpose? What is indexing in this context?
I’m still learning about Solid. I haven’t really touched on linked data yet but encryption is potentially going to be an important option for some projects I have in mind.
RDF (Resource Description Framework) is the structured data format underlying Solid’s linked data model. You’ll typically see it as Turtle (.ttl) or JSON-LD files. They’re documents that express statements as subject-predicate-object triples. A “sidecar” is just a companion RDF document stored alongside the encrypted files.
The sidecar does not contain any encrypted content. With rdfIndex: true enabled in the SDK, it stores plaintext metadata about what’s in the vault: at minimum the logical filenames, content types, and creation timestamps. These are things you’re willing to expose unencrypted so that standard Solid apps can see them without needing your key.
In Solid, apps discover resources by traversing RDF documents and following links from your pod’s profile or type index to containers and files. If all your vault files are opaque encrypted blobs with randomized IDs (which is the default behavior for privacy), a standard Solid app has no way to know those files exist or what they are. The RDF sidecar is an opt-in bridge back into the normal Solid discovery world. A Solid browser or a SPARQL query over your pod could read the sidecar and see “this container has a file called medical-notes.json, created 2026-01-10, type application/json” without being able to read the actual content.
The sidecar is off by default precisely because turning it on opts you back into metadata visibility. It’s the classic privacy vs. interoperability balance: with a plaintext sidecar, any Solid app can discover your files; without one, only apps that hold your key even know the files exist. For genuinely sensitive data you’d probably leave it off. For something like a recipe collection where you’re fine sharing filenames but want the content encrypted at rest, the sidecar lets the vault play nicely with the rest of your pod’s data graph.
If any of your projects involve storing sensitive data, the Private Data Pod Developer Center is a good next step. It covers deploying Solid apps with vault support already wired in, so you can experiment with both encryption modes and the RDF sidecar without having to set up infrastructure from scratch. Given that encryption is already on your radar for some of your projects, it might be a useful sandbox to get a feel for how all of this fits together before committing to an architecture.
1 Like
Thank you for the clear and detailed response. I will check out the sandbox you mentioned.
I should have looked at the source code before asking. You’ve provided some useful and detailed comments throughout the code.
One question after looking at sidecar.ts.
Would it be useful to allow custom metadata properties in the index file on a case-by-case basis? Currently there is a fixed set of properties.
I’m probably missing something important in my understanding of how these things are supposed to work though…
Is your sidecar a .meta resource ?
In such case it would looks very near to what is used in CSS.
In Solid .meta Resources populates automatically Container rendering.
1 Like
The current fixed set (filename, content type, size, timestamp in schema.org terms) was chosen deliberately to give indexing tools and Solid agents a stable, predictable contract. If the schema varies per file or per app, a generic backup tool or search agent has to handle arbitrary shapes, which pushes complexity onto every consumer of the sidecar.
That said, there’s a real case for custom properties. An app managing medical records might want to expose a category or document type field so a Solid agent can organize vault contents without needing the decryption key. A photo vault might want to expose a date taken or album name. Those are legitimate needs.
The wrinkle is that everything in the sidecar is plaintext and visible to the server operator. That’s fine for filename and size, but as soon as you allow arbitrary custom properties, it becomes easy for developers to inadvertently leak meaningful data about what’s inside the encrypted blob. The fixed schema acts as a guardrail against that.
One approach worth considering: allow custom properties but only as an opt-in at the vault or container level, with clear documentation that anything placed there is unencrypted and operator-visible. The SDK could expose a typed extension point that encourages developers to think deliberately about what they’re exposing rather than treating the sidecar as a free-form metadata store.
If that kind of extension point would be useful for something you’re building, I’d be happy to think through what the API should look like. What’s the use case you have in mind?
It’s not a .meta resource, and that’s an intentional choice rather than an oversight.
In CSS, a .meta resource is automatically merged into the container’s RDF representation when a client does a GET on the container. That’s useful for container-level description, but it means anything in .meta is effectively visible to anyone who has read access to the container itself. You can’t separately control who sees it.
The vault sidecar is a named Turtle document stored inside the vault container, with its own URL and its own ACL. That separation matters because the vault owner may want to grant a backup tool or a Solid agent read access to the sidecar for indexing purposes, without granting that agent access to the encrypted blobs themselves. If the sidecar were a .meta resource, that distinction would collapse.
The trade-off is discoverability. Because the sidecar is a regular resource rather than a .meta resource, a generic Solid client browsing the container won’t automatically pick up the metadata. Apps that want to use it need to know where to look, which is a reasonable expectation for apps that are vault-aware.
That said, your observation points at something worth considering for a future version. If CSS’s .meta handling ever gains support for per-resource ACLs or conditional inclusion, it would make sense to revisit whether the sidecar should integrate more directly with that mechanism. For now the named resource approach gives more control at the cost of some discoverability.
Docs combined with typed extension sounds like a reasonable approach if you wanted to add flexibility.
I don’t have an immediate use case in mind though. Just figured it could be useful in some cases (like the examples you mentioned).