This issue is a list of abandoned ideas, for the current one go here: #267
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.:
uri
should_decentralize
unique_name
A@A
true
A
A@ldavg
true
A
A@HaP
true
A
A@B
false
A
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.
This issue is a list of abandoned ideas, for the current one go here: https://notabug.org/diogo/gnu-social/issues/267
**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.:
uri | should_decentralize | unique_name
--------|---------------------|------------
A@A | true | A
A@ldavg | true | A
A@HaP | true | A
A@B | false | A
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).
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).
@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 :)
@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
[rozzin] https://en.m.wikipedia.org/wiki/Multi-master_bus
[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*....
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
[rozzin] https://en.m.wikipedia.org/wiki/Multi-master_bus
[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.
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.
Conversion goal: V2 groups become V3 organisations.
V3 groups (%)
Groups have no authority, no administrator nor moderator.
When federating a group tag it looks like this:
tags: [
[
type: 'group',
name: '%nickname'
]
]
Every server must have a list of AP sharedInbox (an endpoint which can be retrieved via WebFinger) and anything with group tags should be sent to all the known hosts, as only the remote host will know which (and if) of their local users should be notified.
If a full form group mention is done, it is federated either in To or CC, it's page has a "partOf collection" with the members who joined this instance's "group version".
Groups will make use of Follow, Join, and Leave:
Follow will subscribe the whole umbrella;
Join will subscribe only the group of an instance;
Leave will mute a certain instance's group (useful if you're following a group and a certain instance's version is being annoying) - Although federated, since we always federate group-related notes to all known servers' sharedInbox, it is ignored as we will filter it locally.
V3 organisations (!)
Very much like old v2 groups, they have a collection of members, of subscribers, of moderators, and an owner (attributedTo).
The @instance is the authority of the organization.
Respects Follow (add to subscribers) and Join (add to members) logics. Members is subject to moderation while subscribers are not.
Important to have in mind before trying to understand the following aspects: https://notabug.org/diogo/gnu-social/issues/141#issuecomment-29226
First idea came from https://notabug.org/diogo/gnu-social/issues/186
Conversion goal: V2 groups become V3 organisations.
## V3 groups (%)
Groups have no authority, no administrator nor moderator.
When federating a group tag it looks like this:
```php
tags: [
[
type: 'group',
name: '%nickname'
]
]
```
Every server must have a list of AP sharedInbox (an endpoint which can be retrieved via WebFinger) and anything with group tags should be sent to all the known hosts, as only the remote host will know which (and if) of their local users should be notified.
If a full form group mention is done, it is federated either in To or CC, it's page has a "partOf collection" with the members who joined this instance's "group version".
Groups will make use of Follow, Join, and Leave:
* Follow will subscribe the whole umbrella;
* Join will subscribe only the group of an instance;
* Leave will mute a certain instance's group (useful if you're following a group and a certain instance's version is being annoying) - Although federated, since we always federate group-related notes to all known servers' sharedInbox, it is ignored as we will filter it locally.
## V3 organisations (!)
Very much like old v2 groups, they have a collection of members, of subscribers, of moderators, and an owner (attributedTo).
The @instance is the authority of the organization.
Respects Follow (add to subscribers) and Join (add to members) logics. Members is subject to moderation while subscribers are not.
After the death of big instances such as qvitter, 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.
We would like to remove the dependency on an instance. So, whenever someone mentions a group, his server should notify every known server. And the remote servers would notify the appropriate local actors that have subscribed the group.
Every instance's group page should have two feeds, one of posts that have mentioned specifically !group@instance (in case that particular instance has a specific culture) and one of posts that mention !group or !group@*.
# FEP Umbrella Groups
Requires: as:umbrela for actor group, AP 7.1.2(#inbox-forwarding with local members collection)
The collection @#!lug@instance#servers is a collection of known instances.
When synchronizing, with an instance, both should add the items they don't possess (forgetting mechanism explained later). Example:
A: [
- @#!lug@A#servers
- uri @#!lug@C#servers
]
B: [
- @#!lug@B#servers
- @#!lug@D#servers
]
A and B should end with
[
- @#!lug@A#servers
- @#!lug@B#servers
- @#!lug@C#servers
- @#!lug@D#servers
]
## 1. An instance joins an umbrella group
@1@A: Create/Group !lug
@1@A: Create/Note !lug
@2@B: Create/Group !lug with connection to !lug@A (Synchronize/Collection @#!lug@A#servers @#!lug@A#notes#p1)
> B now knows server A; B: [A, B]
> A now knows server B; A: [A, B]
@2@B: Create/Note !lug
!lug@B: Announce/Note @#!lug@*#servers (Synchronize/Collection @#!lug@B#servers)
> instance * will be [A]
> collection knowledge has not changed for anyone
> because their collections had not changed before this Create/Note
## 2. Now a third instance joins an umbrella group
@3@C: Create/Group !lug with connection to !lug@B (Synchronize/Collection @#!lug@B#servers @#!lug@B#notes#p1)
> C now knows servers B, A; C: [A, B, C]
> B now knows server C; B: [A, B, C]
@3@C: Create/Note !lug
!lug@C: Announce/Note @#servers@!lug (Synchronize/Collection @#!lug@C#servers)
> instance * will be [A, B, C]
> A now knows server C; A: [A, B, C]
> C collection knowledge has not changed because A has nothing new in collection
> N.B.: C has re-checked its own collection because digest was different from that in A
A: (Synchronize/Collection @#!lug@C#notes#p1)
## 3. Now a fourth instance creates !lug and now two worlds collapse/collide
@4@D: Create/Group !lug without connections
@3@C: Follows/Person TO @4@D
@4@D: Create/Note !lug (Synchronize/Collection @#!lug@D#servers)
> C now knows server D; C: [A, B, C, D]
> D now knows servers C, A, B; D: [A, B, C, D]
> from now on, D announces !lug targeted stuff from local members to a broader collection of servers.
## 4. Now a fifth instance creates !lug
@5@E: Create/Group !lug without connections
@5@E: Create/Note !lug
@4@D: Create/Note mentioning @*@E
> collection knowledge has not changed for anyone
> Even though E and D have a !lug group, they never exchanged matters
## 5. A sixth instance creates !lug
@6@F: Create/Group !lug with connection to !lug@E (Synchronize/Collection @#!lug@E#servers @#!lug@E#notes#p1)
> F now knows server E; F: [E, F]
> E now knows server F; E: [E, F]
## 6. Now two galaxies merge
@*@E: Follow/Person @4@D
@4@D: Create/Note !lug (Synchronize/Collection @#!lug@D#servers)
> E is targeted because has a local user that is a member of @4@D#followers
> E notices that servers collection received is different from his own
> E now knows servers A, B, C, D (thanks to D); E: [A, B, C, D, E, F]
> E reports to D his new collection:
E: Synchronize/Collection @#!lug@E#servers TO !lug@D
> D notices that servers collection received is different from his own
> D now knows servers E, F (thanks to E); D: [A, B, C, D, E, F]
> D reports to E his new collection:
D: Synchronize/Collection @#!lug@D#servers TO !lug@E
> E collection knowledge has not changed because D has nothing new in collection
## At this point, the collections in the universe are:
B: [A, B, C] (##2)
A: [A, B, C] (##2)
C: [A, B, C, D] (##3)
F: [E, F] (##5)
E: [A, B, C, D, E, F] (##6)
D: [A, B, C, D, E, F] (##6)
## What would we like for V3 groups?
After the death of big instances such as qvitter, 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.
We would like to remove the dependency on an instance. So, whenever someone mentions a group, his server should notify every known server. And the remote servers would notify the appropriate local actors that have subscribed the group.
Every instance's group page should have two feeds, one of posts that have mentioned specifically !group@instance (in case that particular instance has a specific culture) and one of posts that mention !group or !group@*.
The following draft was authored with @someonewithpc:
```markdown
# FEP Umbrella Groups
Requires: as:umbrela for actor group, AP 7.1.2(#inbox-forwarding with local members collection)
The collection @#!lug@instance#servers is a collection of known instances.
When synchronizing, with an instance, both should add the items they don't possess (forgetting mechanism explained later). Example:
A: [
- @#!lug@A#servers
- uri @#!lug@C#servers
]
B: [
- @#!lug@B#servers
- @#!lug@D#servers
]
A and B should end with
[
- @#!lug@A#servers
- @#!lug@B#servers
- @#!lug@C#servers
- @#!lug@D#servers
]
## 1. An instance joins an umbrella group
@1@A: Create/Group !lug
@1@A: Create/Note !lug
@2@B: Create/Group !lug with connection to !lug@A (Synchronize/Collection @#!lug@A#servers @#!lug@A#notes#p1)
> B now knows server A; B: [A, B]
> A now knows server B; A: [A, B]
@2@B: Create/Note !lug
!lug@B: Announce/Note @#!lug@*#servers (Synchronize/Collection @#!lug@B#servers)
> instance * will be [A]
> collection knowledge has not changed for anyone
> because their collections had not changed before this Create/Note
## 2. Now a third instance joins an umbrella group
@3@C: Create/Group !lug with connection to !lug@B (Synchronize/Collection @#!lug@B#servers @#!lug@B#notes#p1)
> C now knows servers B, A; C: [A, B, C]
> B now knows server C; B: [A, B, C]
@3@C: Create/Note !lug
!lug@C: Announce/Note @#servers@!lug (Synchronize/Collection @#!lug@C#servers)
> instance * will be [A, B, C]
> A now knows server C; A: [A, B, C]
> C collection knowledge has not changed because A has nothing new in collection
> N.B.: C has re-checked its own collection because digest was different from that in A
A: (Synchronize/Collection @#!lug@C#notes#p1)
## 3. Now a fourth instance creates !lug and now two worlds collapse/collide
@4@D: Create/Group !lug without connections
@3@C: Follows/Person TO @4@D
@4@D: Create/Note !lug (Synchronize/Collection @#!lug@D#servers)
> C now knows server D; C: [A, B, C, D]
> D now knows servers C, A, B; D: [A, B, C, D]
> from now on, D announces !lug targeted stuff from local members to a broader collection of servers.
## 4. Now a fifth instance creates !lug
@5@E: Create/Group !lug without connections
@5@E: Create/Note !lug
@4@D: Create/Note mentioning @*@E
> collection knowledge has not changed for anyone
> Even though E and D have a !lug group, they never exchanged matters
## 5. A sixth instance creates !lug
@6@F: Create/Group !lug with connection to !lug@E (Synchronize/Collection @#!lug@E#servers @#!lug@E#notes#p1)
> F now knows server E; F: [E, F]
> E now knows server F; E: [E, F]
## 6. Now two galaxies merge
@*@E: Follow/Person @4@D
@4@D: Create/Note !lug (Synchronize/Collection @#!lug@D#servers)
> E is targeted because has a local user that is a member of @4@D#followers
> E notices that servers collection received is different from his own
> E now knows servers A, B, C, D (thanks to D); E: [A, B, C, D, E, F]
> E reports to D his new collection:
E: Synchronize/Collection @#!lug@E#servers TO !lug@D
> D notices that servers collection received is different from his own
> D now knows servers E, F (thanks to E); D: [A, B, C, D, E, F]
> D reports to E his new collection:
D: Synchronize/Collection @#!lug@D#servers TO !lug@E
> E collection knowledge has not changed because D has nothing new in collection
## At this point, the collections in the universe are:
B: [A, B, C] (##2)
A: [A, B, C] (##2)
C: [A, B, C, D] (##3)
F: [E, F] (##5)
E: [A, B, C, D, E, F] (##6)
D: [A, B, C, D, E, F] (##6)
```
This issue is a list of abandoned ideas, for the current one go here: #267
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:
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_instanceas 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,@ldavgand@HaPas 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.
Moving this discussion to a new issue concerning the implementation details: #267
Important to have in mind before trying to understand the following aspects: #141
First idea came from #186
Conversion goal: V2 groups become V3 organisations.
V3 groups (%)
Groups have no authority, no administrator nor moderator.
When federating a group tag it looks like this:
Every server must have a list of AP sharedInbox (an endpoint which can be retrieved via WebFinger) and anything with group tags should be sent to all the known hosts, as only the remote host will know which (and if) of their local users should be notified.
If a full form group mention is done, it is federated either in To or CC, it's page has a "partOf collection" with the members who joined this instance's "group version".
Groups will make use of Follow, Join, and Leave:
V3 organisations (!)
Very much like old v2 groups, they have a collection of members, of subscribers, of moderators, and an owner (attributedTo).
The @instance is the authority of the organization.
Respects Follow (add to subscribers) and Join (add to members) logics. Members is subject to moderation while subscribers are not.
What would we like for V3 groups?
After the death of big instances such as qvitter, 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.
We would like to remove the dependency on an instance. So, whenever someone mentions a group, his server should notify every known server. And the remote servers would notify the appropriate local actors that have subscribed the group.
Every instance's group page should have two feeds, one of posts that have mentioned specifically !group@instance (in case that particular instance has a specific culture) and one of posts that mention !group or !group@*.
The following draft was authored with @someonewithpc: