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