kjetilk

OK, so nobody said decentralization is easier. There's been plenty of academic papers saying pretty much the same as you do. But we have to, not for technical reasons, but for ethical and social ones. So, we're starting to tackle it head on.

Your TV Guide is a good example of things that aren't hard. They don't change very quickly, so you can just use a cache. That's easy.

Finding the number of RTs, that's also easy, apart from it being an open world of course. When they RT, they notify you. And you want to display those RTs with your tweet? Just cache those who notified you.

Stable data access standard? That is Solid itself. And the data model, that's RDF.

There are ways that you can go about doing this stuff.

Finally, we're also getting some traction around this in academia, they've been hung up in stuff that isn't helpful for too long.

Right, but if you had data that were just that confidential to you, that's the easy part. Just encrypt it and don't let anybody look. I don't really have that kind of data, but I do have a lot of stuff that's just private, in the sense that I don't have anything to hide, but I close the door when I'm in the toilet. So, really private data, encrypt it, store copies in many safe places, you're done.

That's not really what Solid is about. Solid is not just about me, it is about us. The stuff we do together. The sharing we do, but we share not just with anybody, but with someone we trust. It may be something really trivial: I share my grocery shopping list with my wife. It is not sensitive by any means, but it is also nobody else's business. Those are data used on my terms. Nobody should be peeking into my life to map me, as I go along with my daily business, but my daily business consists of interacting with a lot of people, and I do share and I want to share, but I want personal data control.

Now, personal data control is really the key to permissionless innovation. So, we're not just doing it to protect from snooping, once people have their data then you get a level playing field were there can be competition for the best user experiences.

Oh, but that's more a matter of where you start and what you bootstrap.

In both cases, DNS and TLS CA-based stuff is about trust. You need to trust the DNS server, as there could be malicious servers sneaking in, and you need to trust the cert.

But once you have a social network with a large strong set, you could base the trust on the strong set, and in particular, individuals in that strong set who can demonstrate that they have a clue.

Once we have that, we can get rid of these achilles heels, but quite frankly, I don't believe in a strategy that takes on those problems first.

Sure, I obviously got OpenNIC in my DNS resolution. Haven't once seen an address that required me to use it beyond when I set it up. I think our approach is much better. Base it on people and the strongest part of their network.

Oh, but Solid isn't just a social network. True, social networks have really powerful network effects, so it is a key to success, but not the only key. We're separating data from apps, which enables permissionless innovation. That means a lot of people can start writing cool things that they just can't now, because they are constrained by those platform companies. We're doing that too. And once people start doing that, every useful app that comes to Solid will grow the platform, first probably as small communities here and there, and then those communities get new connections, and boom, disruption! :-)

Not really, it is pretty much the other way around. :-) We're basically building the simplest thing that could possibly work, they are rebuilding a lot of infrastructure that they have to use, but we can use where it makes sense. So, they are kinda trying to implement the Web, which is a much bigger task than adding access control and identity... :-) There's also been quite a lot of overlap between people working on Solid and working on Blockchains in the past, so we know it well. But we're not really in competition, we'd be fine coexisting.

Great question, because it is basically the most ignored problem in the Semantic Web community and thus the one that we are spending quite a lot of time on.

So, basically, there is one data model, RDF, but RDF does not require the same set of fields, to the contrary you are free to write your own. Obviously, you wouldn't get good interoperability if you do. So, there are several things you can do:

1) Adopt what others are using 2) Map your "fields" (we're more for calling it vocabularies), to the stuff others are doing, and rely on apps to figure out interop using reasoners. 3) Don't care, your app will work fine for you.

I mean, 3) is fine, it is just that you'd be missing out. 2) also works, kinda, but reasoners aren't all that easy to use, so I'd mostly like to see people go for 1).

So, we need to make it really easy to find existing stuff. You could go for the big one, i.e. https://schema.org/ or you could go more in detail and look at https://lov.linkeddata.es/dataset/lov/ . The former has a lot of traction, the latter is real decentralized, so I kinda prefer that.

Then, we have to make it real easy to author new stuff when you can't find existing stuff, because that will happen. Then, we need to make it easy for others to find yours, so that they can start using it too for similar applications. And, I'm thinking that it will be kind of a graduation process, where you first look for existing stuff, and when failing to find anything, you just mint your own without thinking about others, just to get something that works up and running. Once your app starts gaining traction, you tighten it up, and if then something other gets popular, you can migrate to that with little disruption.

So, we're not there yet, but we're thinking and working on it a lot.

Actually, we've been chatting about this, and I think it would be great to start selling Solid servers on a OLinuXino board with a nice box around. Not because it would make us a lot of money, but to demonstrate that you, at least a bunch of nerds, can easily take complete control, from everything to the Open Hardware to the MIT-licensed server.

I'm running Solid on my own box, and I can't see myself doing it any other way, but it was pretty hard to set it up. We need to change that.

Mmmmm, sorry. So, we have an #UXFAIL here. I've relayed it on to the rest of the inrupters. Obviously, we're happy if you have more detailed experiences to share, there's a bunch of frontend stuff to fix (I'm working mostly on the server side and developer experience stuff).

Yup, it is. Though, I'm not sure about homomorphic encryption, but there has been some work on encryption in the academic community that has very clear application to Solid. Here's a paper written by some friends of mine: http://epub.wu.ac.at/5818/1/10.1007_978-3-319-58068-5_37.pdf

Right, so that's one of the reasons why Solid is built on top of Linked Data and RDF, we need the power of these technologies to support those advanced use cases.

The Web Access Control spec is here: https://github.com/solid/web-access-control-spec . In principle, we could support really granular data ACLs based on that spec, the ACL applies to a URL, and you can give any datapoint a URL, so problem solved. In practice, it may become a bit cumbersome, I suppose it remains to be seen how you'd do it in practice, but I think we have a really good start there, there's lots of stuff that can be realized now.

There's a wealth of academic research that applies to these problems, the problem of the Semantic Web community has been that it has been strong on the academic stuff, but not very focused on truly useful stuff that can be done right now (to quote AaronSw). That's one of the things that Inrupt sets out to change. But the good thing is that we're not setting out to solve really hard problems in the dark, since we have that academic research, we know pretty well what's hard and what should be within reach.

Well, I guess we just asked the opposite question: Is there any reason to keep this sub-surface any longer, and we didn't find any such reason... :-)

So, it is just "release early, release often". So, the code and the spec has been out there for a long time. I mean, some of this stuff is really old. Us geeks have been thinking about decentralized social networking since the dawn of ages, and it seems like the rest of the world is starting to wake up to its necessity too. So, I think the timing is pretty OK now.

Like, Linux didn't come with a well-polished example either... It wasn't even intended to out-do Minix. :-)

I guess you could say that we could say even more clearly that this is a prototype, and we have a roadmap where it will stay a prototype for some time. But we are seeing people finding it interesting that we're actually not trying to engineer something from the ground, we are seeing what kind of impact we can have with pretty well tested Web technologies. I suspect we have a lot less development to do to have a great social impact than you'd have to do if went full P2P.

At the same time, there is a large graveyard out there of failed decentralized social networks, so we are under no illusion that this is going to be easy. It is going to be pretty hard.

Still, I don't see any reason why we should be sub-surface any longer.

So, we're kinda dogfooding that, we're not only building decentralized social networks, the business is also decentralized, so we haven't got any big corporate offices. A lot happens out of Boston, but I'm based near Oslo, Norway, we have people in Belgium, Czechia, France, Costa Rica, etc. Nevertheless, you're right, we're a responsible business, and we should identify with a business address.

And we definitely need a ToS and a privacy policy, etc. The explanation for why we didn't have that is that the code running the sites that we put out there for people to try out is the same code you'd use for your POD on your own box. And most of us are running that code on our own boxes (mine is in a server rack in my basement :-) ), and those installs don't need a ToS. :-) So, you're right, we should have that as an option, so I filed a bug for it: https://github.com/solid/node-solid-server/issues/799