I started developing an App to create groups in Solid. The main idea is to have something like Facebook groups on the distributed Web. The groups should allow people with common interests to find each other.
But it can’t do anything yet, I am primarily working on being able to set up a group initially. The goal is, that anyone can just click a button to deploy the App on her own Pod or a group Pod and the app will then set up a group on that Pod. So app and data will reside on the same pod and groups can spread arround the Web.
Nice I was just asking myself for followers on Agora https://github.com/scenaristeur/agora if I had to ask for request like Instagram or allow automatic followers as Twitter…
What’s very interesting to me in this discussion is that both Solid and fediverse are investigating how to implement Groups (see Groups implementation on SocialHub) and both based on ActivityStreams for that. This is a great opportunity to combine Solid vs. ActivityPub and, at least, stay as compatible as possible to each other.
How cool would it be if the Solid Groups App would be fediverse-compliant, integrated with the federated web, and showing Solid goodness to the AP audience over there?
The discussion on SocialHub was started by @ngerakines creator of Tavern, a minimalistic Mastodon-compliant AP server implemented in Go. Rather than creating formal descriptions the fediverse recently adopted the practice to have FEDERATION.md documents that describe server-to-server federated communication. Tavern has one too, that describes Group messaging.
@aveltens what I find unintuitive is the Offer{Join} semantics. To me that says “I, Angelo offer to join the group” . I see Offer more in terms of “I offer this Product or Service”. Also the Join in this case refers to an activity that has not happened yet, hence it is not a real activity. Creation of the Join should be left to the group after it happened, hence making it a real activity.
Some highlights of SocialHub discussion and FEDERATION.md (highly recommended reads):
As per ActivityStreams spec a Group is an Actor-type (in ActivityPub this means it has its own ldp:inbox)
As such the Group is the single-source-of-truth of group membership
Joining a Group entails sending a Follow activity to its inbox, which is responded with either Accept or Reject
This can be automatic Accept for public groups, or a pending operation for private groups, manual approval.
A Reject includes the reason for rejection e.g. “Private group, invitation only”.
The Group notifies its members (including the new member) about membership change with a Join{Person} message.
An Undo{Follow} to the Group triggers a Leave membership change message from the group.
An Invite{Person} to both Group and Person from an existing member means that a subsequent Follow to that group from the person is automatically accepted.
Hey @aschrijver, this is very valuable feedback. Thanks for keeping such a close eye to the relation between ActivityPub and Solid.
I am not committed to the Offer{Join} semantics. I did not find a formal specification of group management in the Activity Streams Recommendation, but wanted to start somehow and get a working prototype. Offer is used in a friend-request example, so I thought it might fit in for join requests as well.
If now the AS community is working on that part of the spec as well, this is really great and I will dive deeper into it to get on common grounds.
And thinking further I see that both “Follow a Group” and “Join a Group” activities really make sense in terms of ActivityPub, but they have different meaning:
Join a Group - an intent to receive all activities sent to that Group by members of the Group.
Follow a Group - an intent to receive all activities sent by the Group i.e. by the Group as an Actor. This is similar to following a Server’s admin.
The discussion did not follow up from there. I think if I would implement Groups, I would make this distinction.
Also note the word “activities”. In Tavern FEDERATION.md this is currently limited to discussion messages (toots) with Create{Note} and Announce{Note}. In my implementation this would be a much more broader Create{Object} (with restrictions to what Object can be, of course). After all groups would be involved in all kinds of activities
PS: Thanks for pointing to this section in the spec… the semantics are very much open to interpretation, so choosing common approaches is a valuable undertaking.
How do you define a sub-group? Since the group is an as:Actor just like as:Person it can be part of the members of another group (effectively a nested group). In that case https://www.w3.org/TR/vocab-org/#org:memberOf also applies.
Thxs @aschrijver@aveltens for your response .
The aim is to build a gouvernance tool inspired by Holacracy
With organization ( group) , circles & sub-circles ( groups ) & roles ( also groups? )
All nested groups in fact, where a member can be a group https://www.holacracy.org/constitution
Nice! I might start a side-project based on Sociocracy pattern library, if I find the time.
Is it an open source application?
PS. I’d definitely go for the org ontology in that case. Also I’d make the organization an organization, not a group. In activitystreams there is also an as:Organization as a separate Actor type. For Role there is also org:Role.