FEP-8485: Unbound Actor

Before anything, I want to honestly thank you for the time, dedication and attention you’re putting into this. The discussion threads you’re referring to are long and full of different concepts. And you pointing at various of their aspects while explaining truly helps :slight_smile:

I think I ended involving too many different assumptions and concepts in a single proposal, when what I wanted, and wasn’t fully making that step, was to focus in this one aspect that you have just emphasized.

To fill the gap between otherwise disperse groups and provide an experience equivalent to that of only having one group everywhere that is not bounded to any single server.
And this mode of operation should always be optional. It should be possible to only do that with three groups instead of every group, as well as stop or start doing it when wanted.
While always leaving federated administration and/or moderation be its completely separate and not necessarily related thing.

I had that intention but I was implying that a Group ideally would always maintain a relationships collection with as many collaboratesWith as possible.
And that this wouldn’t be possible for an Organization.

But it’s much better to let any actor hold a relationships collection and this proposal should instead focus on how, and probably while using FEP-400e, can we “unbound” a group or an organisation from a single server, when that is indeed desired.

The http://purl.org/vocab/relationship/collaboratesWith I ended selecting is not ideal, as it can be needed to express other things more accurately. The same is true, for the same reason, towards using http://xmlns.com/foaf/0.1/knows.

Maybe then use https://w3id.org/#AgentRelationship instead and thus have the roles specified in the subjects:

  "@context": "https://www.w3.org/ns/activitystreams",
  "summary": "!lug@social.undefinedhackers.net is linked with !lug@gnusocial.net",
  "type": "Relationship",
  "subject": {
    "type": "Group",
    "id": "https://social.undefinedhackers.net/group/lug",
    "role": "link"
  "relationship": "https://w3id.org/#AgentRelationship",
  "object": {
    "type": "Group",
    "id": "https://gnusocial.net/group/lug",
    "role": "link"

If the relationships collection is going to allow a group to express relationships with other groups (such as part_of), and both let a person follow its feed vs be a member of it, then it may be better to always be
explicit with what relationship is being expressed…

Indeed in the “augumentation mechanism” proposed here, for each new remote group discovered, if they have the gs:unbound attribute set to true, it could:

  • Send a request to be added to their relationships as described in FEP-400e;
  • If authorised, then add the remote !hackers to its own relationships collection.

I think the issue we had with GNU social’s OStatus groups is clear. And, in the Groups implementation discussion, we had vaguely commented about this umbrella method as a possible solution to this issue.

I started a new discussion because I felt that maybe the proposed “Connections augmentation mechanism” was a bit tangent to these discussions. As this is mostly specific to removing the dependency on a single server for a group and not so much about what a Group is and how to interact with it (although both things are necessarily related, as you have just shown).

Anyway, I’m definitely not looking forward to implement an AP extension or convention that only GNU social will understand and, as hopefully is clear, I want to discuss this and end with a good specification (which definitely doesn’t have to be one originally proposed by GS) in hands to implement.

To follow up on this, do you think I should:

  • Move this proposal to one of the ongoing discussions and close this discussion (to avoid duplication);
  • Rename the current discussion to Unbounded Group (to make it more clear and specific);
  • Submit this as a FEP with the corrections you’ve pointed me for further discussion (such as using relationships, and use FEP-400e between groups to update the collections).

Or, if this is not a new concept, or not much different of something already proposed, could you point me to it so we can start implementing it on GNU social? You mentioned that #software:bonfire already has an implementation that uses Vlueflows, is there a spec of how their groups work?

Happy new year! :smiley: