We are developing both server and apps for [3] https://solidproject.org/ The effort is backed by Tim Berners Lee, with great auth libraries including dPop and PKCE token exchange
If it's a web app, you can check whether it's sending data anywhere but your Pod - but of course, by then it's too late.
In practice, Solid is only the technology that enables control of your data; it doesn't provide the incentives. It's still up to apps to actually provide you with that control, and reasons for it doing so can include customer demand or regulatory pressure.
But Solid can't force apps to give you control - after all, they might just choose not to use Solid in the first place.
So these services/libraries are meant to be included in apps to provide this capability?
The solution, help, I'm looking for is to be able to easily integrate this into development - to give users control of running the apps with their data but also for the ability to give access/send the data to a centralized platform - or request/command for it be removed; obviously that decision will be if they trust the platform, the governance and leadership of it.
I'm not sure exactly what you mean by "these services/libraries", but yes, in Solid, apps need to be explicitly built to support Solid, and data can only be stored in Solid Pods.
Although it's not Solid, an older project is https://remotestorage.io, which is a library that needs to be explicitly used by apps supporting RemoteStorage, but does allow users to store the data on Google Drive or Dropbox too, IIRC.
Why is Solid architected such that your data resides on a computer that you don’t own, when people own computers and phones that are plenty capable of storing data and communicating via the Internet?
There are a number of reasons you might prefer an architecture like this. The main two are resilience (don't place all your eggs in one basket -- if your computer is damaged or lost you don't lose your data) and availability (if your computer is shut down you can still access your data from your phone, tablet, or another device).
It would make great sense to have a non-hosted backend option, though, for power users who prefer to self-host their data.
Resilience and availability are two great reasons, but even then, why not get those by utilizing end-to-end encrypted sync, such that the server does not have access to the data, but the devices do?
Decoupling data storage from the application layer has some advantages, yes, but keeping the data in the clear server-side brings along many of the problems of the original:
- Data is still centralized in large repositories maintained by a company, and these repositories are still valuable and still open to attack, from both inside and outside of the company.
- There is a pinky promise between the data storage company and the consumer to treat their data properly and not to look at it or sell aggregated versions of it, but it is, at best, a pinky promise.
I agree that the open nature of the protocol making "self-hosted" an option is absolutely fantastic. But until that is accessible and easy for every single person to use, then only smart tech people will truly "own their data". That's really all I'm proposing: self-hosting being considered the default.
I'm not sure how e2e encrypted sync works in this context. Someone needs to own a key. If the app is open, then it can't be an app key (or else it doesn't protect against bad actors on the server). Is there meant to be a tertiary party that holds the key then? Probably it would be difficult for most normal people to use a product like this.
Apple syncs iMessages and Health data between a user's devices in an end-to-end encrypted manner, and plenty of normal people use those apps. They don't even need to be aware that those are end-to-end encrypted.
Imagine the device has a (non-encrypted) database, and the app runs locally and interacts with that database, like normal. Think localStorage if you are web-oriented.
The sync would be a separate background process (i.e. managed by the "Solid server" part) that handles encryption and decryption. As for how to manage a "circle" of devices that share the key without revealing it to the server: you can add a device via a key-exchange with the untrusted device asking a trusted device for the key. You can perform a key roll to remove a device. This can all be done automatically, though, where all the user sees is a control to add or remove a device. The hard part is key escrow (you throw all of your devices in a lake), by password protecting a copy of the key. Apple uses HSMs and Signal uses SGX to prevent brute-forcing this backup key.
I guess this is a design decision. Some services might be ok with the "if you lose your password you may lose everything without recourse" approach. I think it would be a tough sell for a lot of customers. Is iMessage really handled this way? I can believe that Signal is, considering how often they remind me to remember my PIN.
I said this in another comment. A small open source project I love is https://Nomie.app. Every iteration has been made so the creator can’t see any data. It has been handled well enough that two friends were able to set it up before. Though they used hosted couchdb services to store their data.
Yes, Solid comprises open specifications and anyone can implement it. The open source implementation that sees most development atm is https://github.com/solid/community-server, which is nearing a 1.0 release.
Perhaps so. I don't know the details. I was operating under the assumption that the parent comment was correct in its accusation that there was no self-hosting option.
Most users will likely prefer a secure way to sync data. There should be a self hosted option.
I am a huge fan and even started looking at Svelte to contribute to https://nomie.app. It is going back to syncing with your own CouchDB instance or just locally. Right now it’s local or to some blockchain company. I don’t remember the exact details any more but it seemed like no one had access to the data.
With Devonthink for Apple ecosystem, I synced between LAN/bonjour only for a while before switching to iCloud sync this year.
You can run the pod service on your own computer as well or on your own VPC in any cloud. Our TrinPod Server can be run on any ubuntu machine anywhere, we plan to get it to install on Raspberry Pi too. The Solid protocol is a peer to peer protocol. You just need to have 80/443 open to collaborate with the rest of the world.
