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