Solid Webbook - Enabling Social into Solid


#1

Dear all,

Just a few days ago I got the chance to discover the Solid project and I was just blown away. I was aware of the concept of Linked Data and briefly played with it, but I believe that thanks to Solid we will be able to shape a whole new approach to working with data.

What I find the most interesting - besides privacy - is the social aspect. However, by reading some posts regarding how we should tackle this new social network I noticed some concerns: users willing to keep their own private network, how to ensure decentralization and all in all, not becoming Facebook 2.0. While those are completely justified, I do believe that we still need to provide a way for people to gain value out of the network, because it is this added value what make users stick with their current social tools.

Moreover, linked data brings a whole new approach on how to exploit data, make decisions and gain value, but we will need to prepare the environment for new applications to research and showcase these new tools. I am imagining, for example, a small app that would just recommend me some books based on what I’ve read and what other users have read.

The issue here is that right now there is no way to discover Pods, so we don’t have collaborative applications. How could an app recommend me any good reads if it cannot get information based on profiles similar to mine?

This is why I came up with the following idea: Solid Webbook. I think of it as a phone book for the web, but where users can decide if they want to be there or not. Therefore, privacy will be remaining as it is for those who prefer it this way, but we could start building applications that are driven by data, public and willingly shared data. This Webbook is just another Pod with an address.ttl file where users can submit themselves.

For the submission process, I just sketched a dead simple app https://pmbrull.github.io/solid-webbook/ (I am just a complete noob, so all comments are welcome). By using this app, users will appear then in https://webbook.solid.community/webbook/address.ttl, so applications and other users would know where to discover other pods.

To not fall into a centralized flaw, I’d say that we could enable any other Pods to become a replica of this Webbook and prepare data synchronization engines (as with regular databases with replicas).

Please, let’s discuss if this - or any other similar index of pods - would be a possible milestone for the Solid roadmap.

If you are interested, you can submit yourself to the Webbook (https://pmbrull.github.io/solid-webbook/) so we data nerds can start figuring out what we can do!

TL;DR I played around the idea of a tool - the Webbook - to let other users and solid applications to discover pods. This way, the community could be expanded towards data centric applications that would enable the growth of Linked Data algorithms, as we would be creating use cases for those.

EDIT: Based on the comments below, we could use the following architecture

Note that we will be adding a flag file in each user’s Pod to avoid impersonation when submitting entries. Moreover, we will be adding separate files per user, where the filename could be a sanitized webId for each user to ensure uniqueness. Thus, apart from submitting entries users could also call the Webbook to delete their entry.

Finally, ShEx validation ensures that content will be standardized. With this approach all information will be written in the Webbook by its own webId. Therefore, we will avoid security issues where any other third party application could try to modify the data, as we can change access to read only.

I’d say that this implementation could be done with nowadays tooling, so it would just require the resources to manage and monitor the Azure services.


#2

Wow, this is great. I had something similar on my mind as well! Recently this idea evolved into providing an app for Solid Group management. So anyone could host a Group on any Pod, closed or open for anybody to join. There could be a Global group of any Solid user as well, similar to Webbook.

One questions that puzzles me right now is how to organize data & permissions. You managed joining quite fine, by letting anypody append to the file. But how could I leave/unsubscribe if I do not want to be listed anymore?


#3

This is a very good idea, and something that has been suggested before, but I’m very happy to see some implementation of it. Without having reviewed your code, I hope it can be part of some federated solution where a network of providers can become some sort of address book for WebIDs that allows people to connect :slight_smile:


#4

A big problem regarding the acl:Append imho is, that it allows to append any information. Sorry for messing with your pod @pmbrull , but I just added a foaf:name to address.ttl. I could also just add any WebID as a member. That’s a major concern with regard to building “social” apps. How can we solve this?


#5

Please, mess as much as you want (: i also thought about the append flaws into the same file, but I just wanted to have a small demo to open a discussion with the community.

A possible solution could be generating separate files per user, but we’d need to solve how query engines could handle having the info scattered. Moreover, this does not solve the issue of being able to patch any type of data.

Regarding fixing some schemas so that we are always speaking with the same terms i’d say to use some shape expressions validation.

Finally, the only thing I can think about to ensure 100% compliance for users that actually want to submit themselves (instead of random input of webIds) would be some kind of synced validation between the Webbook and the user, like vinculated acl files. I don’t know what is the current status of that, but i’d say it’s worth a thought!


#6

Shapes might help us with this, once we figure out how to standardize it in such a way on Solid servers that it can be used to validate data before being appended to a RDF resource.


#7

Hi @aveltens, just had an idea! The logic flow would be the following:

  1. User adds its WebId to the Webbook as a separate file - named after his webId to ensure uniqueness - to which only the given user has permissions.
  2. The applications also generates a flag file in the user’s pod. This can only be achieved if the user is the one logged into the Webbook.
  3. A function is subscribed to changes on the Webbook directory. It will validate the content of new files based on ShEx and will ensure that the listed WebIds have the flag file in their pods. Otherwise, new entries will be removed.

Point number 3 could be cheaply achieved with FaaS services in any cloud provider as a first approach.

I believe it’s a rather simple way to ensure content and origin validation.


#8

Hey @pmbrull, I came to similar conclusions. Have to wrap them up as I find time and will compare this to your points then


#9

This has been an area I’m investigating as well regarding “solid” architectural design patterns around both service and peer discovery, but it is interesting why the assumption is a central pod that manages it, given that every other situation people negatively react to such, and alternatively offer up a decentralized suggestion .

what do people feel are the unique requirements here of such ?

keep in mind of how IPFS or Mozilla even are handling new evolutions of the architecture of DNS and such .


#10

another area which might offer some enlightenment of the subject is investigating the architectural design patterns of peer to peer gaming, and the subsequent handling of cheating regarding such environments … as being unique from central servers and etc …