6 ms·

I've never seen a compelling explanation of how this is supposed to work. Do people self-host their pods? Is the pod one more thing to sign up with an externa

by mawise 6y ago

I've never seen a compelling explanation of how this is supposed to work. Do people self-host their pods? Is the pod one more thing to sign up with an external provider? If I'm self-hosting my pod anyway, then wouldn't I want my self-hosting to include the (for example) photo-library viewing layer instead of giving google photos or flickr access to the photos in my pod? If I did give them access, then how is it more private than if they hosted it themselves? Maybe the pitch is more about mobility of services and avoiding lock-in than it is about privacy and security, but that doesn't seem to be the message I get. Does anyone have any pro-solid blog posts or articles you think might be helpful in convincing me? It smells like it is well aligned with my values but I just can't see how it will actually work.

ocdtrekkie 6y ago
Solid seems like an idea that only makes sense if your key goal is allowing cloud providers to offer proprietary services that use your data, while still storing it elsewhere. But I'd say most people fall either into "I don't mind proprietary services holding my data" or "I want to self-host the preferably open source application and my data". I don't see the benefit of separating the two at all, and I think the only reason this project keeps coming up and around is the name of the guy pushing it. "Solid is a mid-course correction for the Web by its inventor, Sir Tim Berners-Lee" is very literally the only selling point I think Solid has. Sandstorm or Cloudron have a better model, self-host (or pay someone to host for you) all of your apps and data together, in an easy interface for adding new apps like an app store.
- pbronez 6y ago
  I really liked Sandstorm’s capability-based security model. Very cool concept for a team app server.
  - rapnie 6y ago
    Spritely project is developing Goblins, implementing the capability-based CapTP transport protocol for distributed programming and the fediverse, which looks very interesting. https://spritelyproject.org#goblins https://spritelyproject.org#goblins
  - ocdtrekkie 6y ago
    It really is. The challenge is it is tough to have that app support with it, everyone expects their apps to work the old way of doing things. ;)
Vinnl 6y ago
You can choose whether to self-host or whether to have someone else handle that for you. As for also hosting your apps: I think the answer to that is the same as for why you might still choose to use an email client even if you're hosting your email server. However, I would expect the majority of people not to self-host, but to have that handled by a party they trust. They would then not be limited by that host also having to support the particular photo-viewing layer they are interested in, but instead are able to choose one independently. (Disclosure: I work for Inrupt, but opinions are my own.)
seph-reed 6y ago
I had this idea a while ago when trying to figure out how we're going to do web-tech in space. Obviously you don't want to send an entire web page, just the data. If data is clearly templated, it's up to the user to choose a UI for displaying it. Many UIs can compete. They don't have to proprietary. In time, UI would become an art form; like music.
passive 6y ago
The hosting story is still a little messy, but in my version of this, I think it needs a trusted third-party to offer hosting, along with an open committee to manage the data specifications. The advantages of separating data storage from usage are similar to those in application development. If you have a robust model for defining and retrieving your data, the tools for working with that data can be iterated on independently from the data itself. So let's say your photos are in Google Photos, because your phone backs them up there automatically, but all your friends who you want to see the photos are on Facebook. Theoretically, "Solid" could be pulling those photos into a standard data specification, and provide easy tools for automating how they get shared into Facebook. Then let's say you wanted to edit some of those photos, so you open up PhotoShop Solid, and get editing. But then you join Instagram, and you want to quickly show off your Photoshop skills. All you need to do is connect Solid. The key aspect here is that you can use as many different tools as you like to work with your data, but it's the same data, and if Facebook goes belly-up tomorrow, or you just don't want your photos there anymore, Solid has your back. One thing that I don't think is well defined yet, but really should be, is how services will request access to your data. This needs some kind of standard interface, very similar to how phones let you customize app access. It should make it very clear what data you are "selling" to the Facebook, and what they are providing in return for that data.
- mawise 6y ago
  That makes sense, but it also means the selling point is data portability more than data privacy/security. Since I would already need to give an application access to my data, I might as well have them host it for me. It still feels like Solid is a more complex and harder-to-reason-about solution to the same problem that GDPR data takeout tries to solve. Consistent open standards are nice, but it doesn't take that much work for Facebook (or others) to accept a Google Photos takeout dump as an input format. If the only real problem that Solid solves is "I loose my data if provider X locks me out or goes bankrupt", then it isn't even good enough since the third-party pod-hosting company can have the same failure mode. Maybe we should expand on GDPR data takeout legislation to require something like API-driven access that would allow people/companies to build automated backup/export solutions. That becomes a much simpler thing to build and get buy-in for instead of a whole new paradigm which companies aren't incentivized to follow and is hard for users to understand.
treis 6y ago
>photo-library viewing layer instead of giving google photos or flickr access to the photos in my pod? IMHO, privacy is the wrong tack for these arguments. The issue is that Flickr or Google Photos can shut down and/or raise prices while all your data is stuck there.
tasn 6y ago
You may also like Etebase (I created it), which is an open-source and end-to-end encrypted backend for apps. So it removes the extra layer (an additional provider) but still maintains the privacy and security benefits of self-hosting.

by mawise 6y ago

ocdtrekkie 6y ago

Solid seems like an idea that only makes sense if your key goal is allowing cloud providers to offer proprietary services that use your data, while still storing it elsewhere. But I'd say most people fall either into "I don't mind proprietary services holding my data" or "I want to self-host the preferably open source application and my data". I don't see the benefit of separating the two at all, and I think the only reason this project keeps coming up and around is the name of the guy pushing it. "Solid is a mid-course correction for the Web by its inventor, Sir Tim Berners-Lee" is very literally the only selling point I think Solid has. Sandstorm or Cloudron have a better model, self-host (or pay someone to host for you) all of your apps and data together, in an easy interface for adding new apps like an app store.

pbronez 6y ago
I really liked Sandstorm’s capability-based security model. Very cool concept for a team app server.
- rapnie 6y ago
  Spritely project is developing Goblins, implementing the capability-based CapTP transport protocol for distributed programming and the fediverse, which looks very interesting. https://spritelyproject.org#goblins https://spritelyproject.org#goblins
- ocdtrekkie 6y ago
  It really is. The challenge is it is tough to have that app support with it, everyone expects their apps to work the old way of doing things. ;)

Vinnl 6y ago

You can choose whether to self-host or whether to have someone else handle that for you. As for also hosting your apps: I think the answer to that is the same as for why you might still choose to use an email client even if you're hosting your email server. However, I would expect the majority of people not to self-host, but to have that handled by a party they trust. They would then not be limited by that host also having to support the particular photo-viewing layer they are interested in, but instead are able to choose one independently. (Disclosure: I work for Inrupt, but opinions are my own.)

seph-reed 6y ago

I had this idea a while ago when trying to figure out how we're going to do web-tech in space. Obviously you don't want to send an entire web page, just the data. If data is clearly templated, it's up to the user to choose a UI for displaying it. Many UIs can compete. They don't have to proprietary. In time, UI would become an art form; like music.

passive 6y ago

The hosting story is still a little messy, but in my version of this, I think it needs a trusted third-party to offer hosting, along with an open committee to manage the data specifications. The advantages of separating data storage from usage are similar to those in application development. If you have a robust model for defining and retrieving your data, the tools for working with that data can be iterated on independently from the data itself. So let's say your photos are in Google Photos, because your phone backs them up there automatically, but all your friends who you want to see the photos are on Facebook. Theoretically, "Solid" could be pulling those photos into a standard data specification, and provide easy tools for automating how they get shared into Facebook. Then let's say you wanted to edit some of those photos, so you open up PhotoShop Solid, and get editing. But then you join Instagram, and you want to quickly show off your Photoshop skills. All you need to do is connect Solid. The key aspect here is that you can use as many different tools as you like to work with your data, but it's the same data, and if Facebook goes belly-up tomorrow, or you just don't want your photos there anymore, Solid has your back. One thing that I don't think is well defined yet, but really should be, is how services will request access to your data. This needs some kind of standard interface, very similar to how phones let you customize app access. It should make it very clear what data you are "selling" to the Facebook, and what they are providing in return for that data.

mawise 6y ago
That makes sense, but it also means the selling point is data portability more than data privacy/security. Since I would already need to give an application access to my data, I might as well have them host it for me. It still feels like Solid is a more complex and harder-to-reason-about solution to the same problem that GDPR data takeout tries to solve. Consistent open standards are nice, but it doesn't take that much work for Facebook (or others) to accept a Google Photos takeout dump as an input format. If the only real problem that Solid solves is "I loose my data if provider X locks me out or goes bankrupt", then it isn't even good enough since the third-party pod-hosting company can have the same failure mode. Maybe we should expand on GDPR data takeout legislation to require something like API-driven access that would allow people/companies to build automated backup/export solutions. That becomes a much simpler thing to build and get buy-in for instead of a whole new paradigm which companies aren't incentivized to follow and is hard for users to understand.

treis 6y ago

>photo-library viewing layer instead of giving google photos or flickr access to the photos in my pod? IMHO, privacy is the wrong tack for these arguments. The issue is that Flickr or Google Photos can shut down and/or raise prices while all your data is stuck there.

tasn 6y ago

You may also like Etebase (I created it), which is an open-source and end-to-end encrypted backend for apps. So it removes the extra layer (an additional provider) but still maintains the privacy and security benefits of self-hosting.