7 ms·

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 d

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?

asdfasgasdgasdg 6y ago
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.
- somdax 6y ago
  You can host your own solid server, right?
  - asdfasgasdgasdg 6y ago
    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.
    - conradev 6y ago
      It doesn't matter in the aggregate if there is a self-hosting option if only the tech-savvy can use it.
  - Vinnl 6y ago
    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 https://github.com/solid/community-server, which is nearing a 1.0 release.
- conradev 6y ago
  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.
  - asdfasgasdgasdg 6y ago
    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.
    - conradev 6y ago
      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.
anderspitman 6y ago
You can self-host a Solid server. And if you combine it with a tunnel proxy[0], get the best of both the cloud and personal hardware worlds. [0]: https://github.com/anderspitman/awesome-tunneling https://github.com/anderspitman/awesome-tunneling
gibsonf1 6y ago
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.
skinnymuch 6y ago
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 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.

asdfasgasdgasdg 6y ago

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.

somdax 6y ago
You can host your own solid server, right?
- asdfasgasdgasdg 6y ago
  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.
  - conradev 6y ago
    It doesn't matter in the aggregate if there is a self-hosting option if only the tech-savvy can use it.
- Vinnl 6y ago
  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 https://github.com/solid/community-server, which is nearing a 1.0 release.
conradev 6y ago
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.
- asdfasgasdgasdg 6y ago
  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.
  - conradev 6y ago
    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.

anderspitman 6y ago

You can self-host a Solid server. And if you combine it with a tunnel proxy[0], get the best of both the cloud and personal hardware worlds. [0]: https://github.com/anderspitman/awesome-tunneling https://github.com/anderspitman/awesome-tunneling

gibsonf1 6y ago

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.

skinnymuch 6y ago

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 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.