Forming Solid Groups

In Solid personal data is stored in the users personal online datastore (pod). When it comes to social collaboration in groups, it is not always obvious where to store data and who to give control to. 

Groups can be easily expressed with linked data. Within this article, I use the vcard vocabulary, but others like foaf or sioc follow similar patterns.

I want to discuss how social groups could be defined and managed in the distributed Web that Solid is.

The closed group approach

A document defining a group and it's members could look like this:

:group
  a vcard:Group ;
  rdfs:label "A group" ;
  vcard:hasMember alice:me, bob:me, clara:me .

The document contains general data like a label as well as a list of group members.

The document has to be stored on some pod. Whoever controls this document in the means of Web Access Control is the group owner.

Joining a group

Since the group owner has control over the group data, how can people join a group? Solid, unfortunately, does not have a concept to define fine-grained access control on a statement level, therefore it is not possible to allow people to add themselves to vcard:hasMember, while protecting the rest of the document from changes. If the group owner gives public Append permission to the group document, this would also mean, that anybody could add other information about the group, which is probably not desirable.

So the group owner has to lock down the group document for the general public. The group can only be joined, when the owner actively collaborates by adding a WebID to the list. This could happen for example after someone sent a joining request to the group's inbox.

This approach is ok for closed groups, but not for open groups where anyone is allowed to join without permission. That is why I call it the closed group approach.

Leaving a group

But how about leaving the group? Even closed groups should allow anybody to leave without permission. Since the owner is the only one able to remove a WebID from the list, we are facing a problem here.

And further: The group owner could even add people to the group without their consent and they are not able to leave.

In the Web anybody can state anything about anything (and anyone), the question is who to trust. A statement that involves two parties should be taken with a healthy dose of distrust. When Alice states, she is member of a group, the group should be consulted if this is correct. And if a group states, that Bob is a member, Bob should be asked as well, if he agrees to that.

In Solid this could be realised by linking in both directions. A group member's WebID Profile Document could contain a statement like the following to confirm a group membership (let's call it confirmation link):

some:group vcard:hasMember :me .

Leaving a group would mean to remove the confirmation link. A polite group owner would nevertheless remove the membership statement from the group document as well. A notification about the leaving could be sent to the group's inbox.

The members document approach

For open groups we somehow need to allow people to add themselves to the member list, while protecting the rest of the group data from changes. The Solid access control allows to define permissions per document. When we want to set different permissions to the core group data and the membership list, we must separate the respective data into at least two different documents.

The group could refer to the member document (e.g. members.ttl) with a rdf:seeAlso predicate, so that clients are able to follow the link and find the group members:

:group
  a vcard:Group ;
  rdfs:label "A group" ;
  rdf:seeAlso <members.ttl> .

Joining a group

To join an open group, anybody would be allowed to append to members.ttl, while the main group document will kept changable by the group owner only.

:group
  vcard:hasMember alice:me, bob:me, clara:me .

This will not stop people to append arbitrary data to members.ttl, but clients can choose to only trust the main document regarding core group data and consult any linked documents only for membership information and ignore any other triples found there.

Downside of this approach is, that rdf:seeAlso is a very generic link. An explicit predicate to link to a member document would be more explicit, but I am not aware of any.

Leaving a group

Leaving a group can work in the same way as in the closed group approach, by removing the confirmation link from a user's profile. The group owner should still remove the relation from members.ttl after being notified.

Alternatively the group owner could give full write permission to all members, but this would allow anybody to kick out others from the group which might be problematic, especially in groups, that are open to join for anybody.

The members container approach

The members document approach has downsides with regard to group leaving. This brings me to the idea of a members container, with a separate file for each group membership:

.
├── group.ttl
└── members
    ├── alice.ttl
    ├── bob.ttl
    └── clara.ttl

If every member has an own file stating the membership, fine grained access control can be defined, so that all members can delete their own membership document.

Unfortunately Solid does not have a way to automatically give write access to the creator of a file. When someone joins the group, the group owner has to actively assign write access to the respective membership document.

Since the goal was to prevent the need for group owner intervention, it does not bring any benefit, but makes things a lot more complicated.

Conclusions

For Solid being a solution for social networking on the open Web it is surprisingly complicated to form groups. I am hoping to start a discussion on that and the community will come up with ideas and solutions. What do you think of the approaches described? What other approaches are out there? Do we need to extend the Solid specification to tackle the challenges?

Modified
Published
Language
English
License
CC BY 4.0
Document Status
Published