FEP-8485: Unbound Actor

[diogo]

@aschrijver

Just going to give a bunch of feedback and hopefully something of value to ya

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

@aschrijver

In this it is the ‘space between’ otherwise fragmented and dispersed Groups that is of most interest. The ability to tie those together in meaningful ways and thus “weave a Social Fabric”.

@aschrijver

Dunno such terms now, other than “Unbound Groups” or something like that. The way to set them free from their instance in this proposal constitutes a workaround for a broader limitation of ActivityPub to be addressed: ID’s tied to the domain via an URL.

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.

@aschrijver

I am just mentioning this. Think you are already keeping things separate. We should just avoid that a Group means that by definition it should have this_and_that moderation features and admin_mod_member privileges, or something like that, in order to be interoperable.

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.

@aschrijver

In another thread on a Community AP extension, particularly this post by @lynnfoster shows that Valueflows (which has been implemented in a #software:bonfire module), defines the relationships at the Actor level. And that may be a more appropriate design after all, giving largest amount of flexibility.

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"
  }
}

@aschrijver

(I was also pondering whether relationships might contain Actor objects directly, besides only allow for Relationships. That may ease implementations where groups have just members, no other ‘organization’ to them than that, and seeing an Actor in the collection would then default to a member_of relationship)

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…

@aschrijver

Also wanted to point to a related FEP in process, by @grishka namely: FEP-400e: Publicly-appendable ActivityPub collections .

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.

@aschrijver

Then, when just talking about Group … there’s 2 parallel discussions ongoing about the same topic of standardizing their design, and formalizing that in (one or more) Fediverse Enhancement Proposals

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!