Solid Webbook - Enabling Social into Solid

[pmbrull]

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

[aveltens]

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?

[megoth]

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

[aveltens]

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?

[pmbrull]

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!

[megoth]

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.

[pmbrull]

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.

[aveltens]

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

[markjspivey]

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 .

[markjspivey]

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 …

[aveltens]

Hi, I finally published my thoughts on forming social groups in Solid

https://angelo.veltens.org/articles/2020/solid-groups

What do you think?

Regarding your points @pmbrull:

@pmbrull

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.

This matches my “members container approach” and comes with the problem, that there is currently no way to give the user the permission to his/her own file by default. To assign those permissions one need to have Control permission on the container.

@pmbrull

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.

I called this a “confirmation link”

@pmbrull

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.

I tried to find a solution that does not need server side logic. For a single application like “Webbook” it might be feasible, but in general in Solid we try to build a distributed Web. I want to enable people to host groups on their own pods and I do not expect them to deploy a Cloud function or similar in addition.

[anon36056958]

Thanks for starting this dialog. I hope a lot of people participate. I think forming groups online or being a member of groups online will be (maybe even should be) just as complicated as that in real life.

[pmbrull]

Hi @aveltens!

I am really glad to hear back from you (: Moreover, I am happy that we are sharing the approach on most of the points too. It’s great reading them in an ordered way, so thanks for the doc.

To wrap up your comments, we’d now have 2 main aspects to solve:

• I do believe that the most tidy and easy to manage approach would be the “members container”, so we first would need to figure out how to assign the permissions on the membership files.
• I am not sure how we could use a solution only on the client. Because we not only need to ensure that the protocol logic is followed correctly - add user to goup, create confirmation link, manage permissions - but also check the consistency of the groups’ state at any given point in time. Here it comes the tradeoff you discuss in the article about trust, right? Giving more power to the end user also means that we should trust them, but we still would need to keep a critical point on view on all content, which in some uses that might not be enough.

All in all, I am not sure how we could achieve a correct and consistent logic flow + consistency checks only as client-side. If we follow the nowadays approach on groups, I’ll try to imagine the easy Facebook example: There is centralized information + all the processes involve separate databases and server side computations. Now we are discussing that we do not only want to decentralize all the available group features, which adds another layer of complexity, but we also want to adapt our solution to not involve any kind of extra computing power.

This, wow, will be hard. I am not saying that it is impossible, but then maybe we should start by describing how the protocol of interaction between pods should be enhanced to achieve all the points above:

1. Could we allow the permission tuning when creating a file by a third party pod? Maybe this just means adding a new RDF logic in the directory management.
2. Could we generalize the creation of confirmation links? Maybe this can be controlled by letting the user create “allowed shapes” in its pod, so that would be like a green semaphore stating that OK, I am allowing to be included in a type X of group, and any confirmation link that any third party application tries to create there also has to pass the sanity check of that given shape (brainstorming here).

My final thoughts on this are that we are maybe focusing on the wrong approach. Instead of trying to make our social solution fit into the current Solid state, we may need to think how to enhance the pods protocols in the first place.

[anon36056958]

Sorry, I don’t want to intrude on this process but I can’t help it

The foaf ontology forces a choice, foaf:member or not. There are a lot of cases where this applies but there are a lot of cases where its more complicated.

Everyone has in their minds a map of groups they belong to, and the map sometimes determines precedence of membership or even membership itself on a temporary basis. So the group owner may have the list of members, but they also may sometimes need information about those individuals’ maps, and that may vary. All that is too much to model exactly, but maybe some approximation is necessary.

Membership needs to be more than binary and those ‘allowed shapes’ need to be checked more than just once. It may help mitigate conflict and prevent stereotyping. I know it may not be possible to do with things as they are now, but I’m just sayin’…

[aveltens]

@pmbrull

I do believe that the most tidy and easy to manage approach would be the “members container”, so we first would need to figure out how to assign the permissions on the membership files.

I think there is nothing to figure out. This involves a change in the Solid Spec.

@pmbrull

I am not sure how we could use a solution only on the client. Because we not only need to ensure that the protocol logic is followed correctly

That’s true, but also for the server side. We need a specification for that in the end and apps need to follow it, whether they are client or server-side apps. I am not saying we will never need server-side apps. I just want to go without as far as possible. Also for server-to-pod communication we are still missing important pieces as well regarding authentication, since at least NSS relies completely on browser cookies currently

@pmbrull

any kind of extra computing power.

Why do you think computing power is a constraint here?

@pmbrull

My final thoughts on this are that we are maybe focusing on the wrong approach. Instead of trying to make our social solution fit into the current Solid state, we may need to think how to enhance the pods protocols in the first place.

I deliberatly tried to use Solid “as is” to explore it’s limits. I am sure we need to enhance the Spec and protocols to realize everyhing in the end.

[aveltens]

@anon36056958

Sorry, I don’t want to intrude on this process but I can’t help it

No need to be sorry! Glad you join the discussion

@anon36056958

I think forming groups online or being a member of groups online will be (maybe even should be) just as complicated as that in real life.

I think this is a key point! Nevertheless it should be possible to have simple constucts like we are used from centralized social networks. Following Alan Kay in “Simple things should be simple, complex things should be possible.”

@anon36056958

So the group owner may have the list of members, but they also may sometimes need information about those individuals’ maps, and that may vary. All that is too much to model exactly, but maybe some approximation is necessary.

Perhaps we just need to get more used to the open world assumption and that there is neither a single source of truth nor all facts are consistent or even true.