Aim: Making GNU social more welcoming and robust for communities.
SoTA: Federation of groups is being avoided by alternative software and has been proven problematic after the death of big instances like qvitter because one couldn't target groups hosted at qvitter anymore nor contact the whole subscribers list to let them know of the new instance hosting a certain group.
Abstract: The solution we propose here is to have umbrella/meta groups being logically created in every instance that will collapse groups that are meant to be decentralized into an unit.
The structure of these meta/umbrella groups would rely on having a set of known groups with the same name that are meant to be decentralized, e.g.:
In this example set, ldavg would merge the first three entries into one big group named !A. To interact with A@B, one would have to specify this full uri.
What about aliases? They now would be created by each individual actor of type person and have to be suffixed with @alias. Thus solving any potential ambiguity/collision issue.
How are we going to upgrade existing groups from v2 to v3? By default they will be set with should_decentralize=false. An admin can easily change that.
If a user tries to target a non-existent group in a message, it will go without mentioning any group.
If a meant to be decentralized group is found, an umbrella group will be automatically created and the admin will be the first person to take it over by clicking on a button "Become administrator". A local umbrella group can live without an admin.
We can easily have remote actor with moderator permissions in local groups. So moderation of an umbrella group is made by decentralized moderation, moderation permission requests from local admins will be automagically federated.
Sounds good aside from "@aslias __ " if that's what a user has to type. "!__ " was good, why can't we keep that?
Suggestion use "!!__ " instead if aliases need a different command.
Also, I made most of my Groups original names as 2-3 characters
I.e. 1nf with the whole name as "First Nation Freaks" and an alias like "ndns" (how we've taken the silly "Indians" name to be our own).
@thndrbvr I think you misunderstood Diogo, he suggested a suffix, not a prefix, but yes, !!foo as an alias for !bar is a much better solution.
Ohhh I see. Okay.
Now, I'm wondering... What happens if an actor of any type has the same name as a group? Will there be any conflicts?
No, that shouldn't be a problem (because one uses @ and the other !)
On the other hand, we would like to have Application, Organization and Service... We are running out of symbols! :')
@diogo aren't those just actors, hence acting like users (i.e. @)
@someonewithpc groups are actors as well, here: https://www.w3.org/TR/activitystreams-vocabulary/#actor-types . Different actor types requires different handling, but I guess the handling for the other three isn't so special as the one required for Groups, we probably don't need a special symbol for them :)
On terminology regarding the group meant to be under an umbrella attribute, rozzin came up with the following on IRC:
[rozzin] > GNU social may need a property in the group actor indicating whether it is meant to be decentralized or not.
[rozzin] While technically this is an OK-ish application of that the term "decentralized" because the context, at least if the reader is paying attention, significantly narrows the set of possible specific meanings.... But I think the a better term is probably... "replicated"?
[diogo] Actually... we replicate centralized groups, we cache them; I would say that the groups as we have them now are being replicated, while this would somehow decentralize them
[diogo] If I create a group in ldavg, ldavg is the authority for that group
[diogo] the umbrella groups would be sharing the authority among the various involved instances
[diogo] For my account, the authority is ldavg, and my posts are replicated among other instances
[diogo] but maybe I messing terms up tho, this is how I'm interpreting it at the moment.
[rozzin] diogo: "multimastering"? https://en.m.wikipedia.org/wiki/Multi-master_replication
[diogo] Yeah, sounds like a better term, let me add this to the issue...
[rozzin] diogo: "decentralized" really is a pretty generalized term that requires clarification either from context or use of more specific terms; "GNU social (as a whole) is a decentralized social system" is accurate without specifying/clarifying that "GNU social is decentralized specifically via federation"; and there are other systems that are"decentralized" to the same *degree* as GNU social but not in the same *way*....
This issue was shared for implementation-related discussion on https://socialhub.activitypub.rocks/t/groups-implementation/591/55?u=diogo and https://git.pleroma.social/pleroma/pleroma-meta/-/issues/14
Two implementation solutions were considered in IRC, one that tries to mimic exactly what was conceptualized on the opening of this issue, and one that tries to change less proposed by rozzin.
rozzin proposes federating the full subscribers list to every instance, when the authority instance of a group dies, the one with more local subscribers (as suggested by @aab) takes over if the "should_decentralize" flag of that group was set to true. Every other instance would know this criteria and act accordingly. Users don't have to know the @authority_instance as that could be omitted for groups with such new attribute set to true.
a more true implementation to the concept would rely on always addressing all groups instead of an authority, i.e., for the table above, an activity would address @A, @ldavg and @HaP as no-one was more authority than no-one. Also, instead of federating a full subscriber list, we would probably want to federate a list of known hosts holding this group.
We can't be sure of anything when we have no authority (i.e., we don't have a sure way of knowing every instance involved). But with rozzin's solution, the authority will always be "all-knowing" and thus we have a source of trust.
I think rozzin's solution is true to the way these protocols usually work and not hard of implementing.