Hacker News Reader

Comment by mawise | Hacker News Reader

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.

View on HN

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.

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.

I think data portability is the most obvious value proposition for most people, especially between potentially hostile services (Facebook and Google Photos could easily inter-operate, but that's not something either company wants to invest in). For someone like me, who has moved a streaming music "collection" between 4 services over the past decade or so, it would have been real handy.

It also, conceptually at least, dramatically lowers the barrier to entry for new services in the same space, since they can use the existing data models and persistence layers.

The privacy aspects are secondary, at least to start, though I think the last few years have helped establish more context for them. Providing granular controls for data access in a common format across services seems like a big win, at least compared to my experience hunting through preferences/settings/account details/etc menus in Facebook and other places.

Finally, I think there's significant potential value in this being used as way to authenticate the source of media. As deepfakes are getting better and easier to create, having all the video and audio of you connected to a known identity seems like a necessity. Letting Facebook or Google be that identity provider would be very bad.

The privacy aspects need more attention. There does need to be a neutral and trusted identity provider. It should be possible for the pod owner to control access via some kind of scope/role/policy setup. That's going to be complicated for most people. Using an example from elsewhere in this thread, I probably would want PhotoShop to be able to have full access to many (but not all) images my pod, but Instagram should really only be able to read the images I want to post there.

I think federated identity is the way to go. Technically that's what we have now, ie every identity provider I'm aware of lets you reset your password via email, which is federated.

But we tried federated and users didn't care. They want convenience. Maybe with privacy apparently picking up some public interest, we can try again.

> every identity provider I'm aware of lets you reset your password via email, which is federated

I'm not sure I understand what you're getting out. Federated identity is far more than self-service password reset. And as far as convenience goes, how many places do you use your google/github/facebook/linkedIn/twitter credentials to log into a third party? How convenient is that? That's identity federation. The problem is that those companies own your identity profile and use it for their purposes, not yours.

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.

I really liked Sandstorm’s capability-based security model. Very cool concept for a team app server.

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

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

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.

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

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

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.

Reply on news.ycombinator.com