- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
cross-posted from: https://lemmy.blahaj.zone/post/7235896
Here’s how Kat Marchá describes caracoles:
"you essentially ask to join concentric federations of instances … with smaller caracoles able to vote to federate with entire other caracoles.
And @ophiocephalic’s “fedifams” are a similar idea:
Communities could align into fedifams based on whatever conditions of identity, philosophy or interest are relevant to them. Instances allied into fedifams could share resources and mutually support each other in many way"
The idea’s a natural match for community-focused, anti-surveillance capitalism free fediverses, fits in well with the Networked Communities model and helps address scalability of consent-based federation.
You must log in or # to comment.
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.
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.
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.
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!
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.
