Interesting idea. Personally, I would like to see larger groups of admins and server members working together towards common goals and setting common standards - what we have right now is more like a confederacy, not a federation. There is no unifying, governing body made up of representatives from the servers.
this post was submitted on 05 Jan 2024
46 points (87.1% liked)
Fediverse
28395 readers
246 users here now
A community to talk about the Fediverse and all it's related services using ActivityPub (Mastodon, Lemmy, KBin, etc).
If you wanted to get help with moderating your own community then head over to !moderators@lemmy.world!
Rules
- Posts must be on topic.
- Be respectful of others.
- Cite the sources used for graphs and other statistics.
- Follow the general Lemmy.world rules.
Learn more at these websites: Join The Fediverse Wiki, Fediverse.info, Wikipedia Page, The Federation Info (Stats), FediDB (Stats), Sub Rehab (Reddit Migration), Search Lemmy
founded 1 year ago
MODERATORS
Well, there can't really be a governing body, but we admins do cooperate quite a bit. For example, we use Fediseer to coordinate defederations with bad actors.
We also post spammers we discover on our instances for other admins to block as well.
Let's go simpler: what if your instance was allowed to copy the fed/defed lists from other instances, and use them (alongside simple Boolean logic plus if/then statements) to automatically decide who you're going to federate/defederate with? That would enable caracoles and fedifams for admins who so desire, but also enable other organically grown relations.
For example. Let's say that you just joined the federation. And there are three instances that you somewhat trust:
- Alice - it defederates only really problematic instances.
- Bob and Charlie - both are a bit prone to defederate other instances on a whim, but when both defed the same instance it's usually problematic.
Then you could set up your defederation rules like this:
- if Alice defed it, then defed it too.
- else, if (Bob defed it) and (Charlie defed it), then defed it too.
- else, federate with it.
Of course, that would require distinguishing between manual and automatic fed/defed. You'd be able to use the manual fed/defed from other instances to create your automatic rules, to avoid deadlocks like "Alice is blocking it because Bob is blocking it, and Bob is blocking it because Alice is doing it".
We can't even merge similar/identical communities across federated servers and now we have this idea?
The fact that we don't merge them is one of the great benefits of the Fediverse, actually.
No its the greatest weakness of the Fediverse.
By grouping them you could be on multiple similar communities on a topic and ensure you’re not going to be spammed with the same article 10 times.
It would also help alleviate the issue of zero engagement on most niche/focused communities.
The benefit is needless redundancy.
And small niche communities might not be so small once merged and would guarantee the survival of the communities.
No its the greatest weakness of the Fediverse.
By grouping them you could be on multiple
And sure, we can group them, link them, publish them in podcasts, whatever; but you specifically said merging them which involves only letting one of them exist. I've seen a couple good analyses on the issues with trying to artificially merge communities or limit creation of them, such as the points from this.
Can someone ELI5?
Everyone has their friend group and nobody else is allowed in unless we say so.
Reddit's multireddits (a combined feed from multiple reddits) are a small step in this direction on a centralized social network, and there have already been requests for similar Lemmy functionality ("supercommunities")
They are already introduced into /kbin - as Collections
Thanks, I didn't know that -- I'll update the post!
Part of the problem here I think relates to scale.
If I invite a load of friends over to my house for a party, they might be in different rooms having different conversations but they’re all my friends in my house. No one cares who I let in or kick out, certainly not either of the next groups.
Let’s say I’m part of the committee for the local community hall. We let our halls out to clubs. Some of the committee go to some of the clubs. I might not be interested in what it is, but if someone I trust says they are OK, I’m OK.
At the local University they have a lot of spaces, each managed by the respective school. Each school has a slightly different ethos. Some of them might let their space to groups that other schools wouldn’t, but it’s not their call. They share some resources but not decision making.
We’ve got this problem emerging. The decisions made by lemmyworld or other large instances are generally in service to their communities, whereas on smaller or more focused instances the instance level decisions are the same as community level decisions.
Very much agreed that part of the problem relates to scale -- and, great analogy! It's an interesting thought experiment: if each school had an Lemmy instance, how would they work together to host communities and make it easy for people (in all the schools) to find the communities they're interested in? If they each had a Mastodon instance, how would they share blocklists? And so on.
And great point about the different dynamics between large instances and smaller / more focused instances. There's always a question of which communities an instance sees itself as in service to -- and similarly there's always a question of which instances and communities the team developing the software is in service to.
It's an interesting idea, but too complicated to be put into practice IMO.
I'm a fan of the idea. Are their any implementations are in the works or running now?
Not yet, as far as I know, although there are some groups of instances whose admins and mods have a shared chat room and cooperated on blocklists which has some of these aspects.