(Reposting my comment here from the lemmy crosspost)
Just pointing out that the pawb.social people are/were also planning on forking Lemmy for similar reasons: https://pawb.social/post/147036 . Not entirely sure how much work has gone into it, but might be worth syncing up with them. Although I’m not sure if it’s the “right” thing to do to fork just for ideological reasons, especially since the main lemmy.ml instance seems to be fairly neutral.
I’ve been thinking about how a single “community” could exist across multiple instances, especially given that the landscape right now is that communities are basically:
Undiscoverable.
Hosted on lemmy.world, which is a problem in case something happens to it.
Hosted on lemmy.ml, which is a problem given that the community can be a bit trigger happy with defederation.
Communities following others seems an elegant solution, honestly. Although, I would say that moderators should be able to remove posts of communities they follow, just in case.
However, something stuck out to me when reading the design discussion:
Users who post to a community that follows other communities are offered the choice of whether to post directly to the community they’re following, or to one of the communities that are followed by that community. They need not post multiple times, because posting to a more ‘upstream’ community would cause it to be seen by users of that community as well.
Why not? The lemmy web client at least does a good job at de-duplicating crossposts, and the client used for posting could give you a bullet list of communities you want to send it to. Imagine instances a, b and c where a defederates c, but a also has the largest community for bespoke hatwear or whatever. If you (who is on none of those instances) send your post to just a (because it’s the largest), then your content will be unavailable to c. But if you post to both a and c, you reach both communities.
Another thing that confused me while trying to wrap my head around things is this diagram, which I don’t think covers a common case:
If a user on b makes a post 1 to the community on c… What happens?
Option 1:
funny@c boosts post 1 as message 2.
funny@b is sent 2 and boosts post 1 as message 3.
user2@a can see 1 through message 3 because it is posted on b, which they federate with.
Option 2:
funny@c boosts post 1 as message 2.
funny@b is sent 2 and boosts post 2 as message 3.
user2@a cannot see 2 through message 3 because 2 is on c which they do not federate with.
(Reposting my comment here from the lemmy crosspost)
Just pointing out that the pawb.social people are/were also planning on forking Lemmy for similar reasons: https://pawb.social/post/147036 . Not entirely sure how much work has gone into it, but might be worth syncing up with them. Although I’m not sure if it’s the “right” thing to do to fork just for ideological reasons, especially since the main lemmy.ml instance seems to be fairly neutral.
I’ve been thinking about how a single “community” could exist across multiple instances, especially given that the landscape right now is that communities are basically:
Communities following others seems an elegant solution, honestly. Although, I would say that moderators should be able to remove posts of communities they follow, just in case.
However, something stuck out to me when reading the design discussion:
Why not? The lemmy web client at least does a good job at de-duplicating crossposts, and the client used for posting could give you a bullet list of communities you want to send it to. Imagine instances
a,bandcwhereadefederatesc, butaalso has the largest community for bespoke hatwear or whatever. If you (who is on none of those instances) send your post to justa(because it’s the largest), then your content will be unavailable toc. But if you post to bothaandc, you reach both communities.Another thing that confused me while trying to wrap my head around things is this diagram, which I don’t think covers a common case:
If a user on
bmakes a post1to the community onc… What happens?Option 1:
funny@cboosts post1as message2.funny@bis sent2and boosts post1as message3.user2@acan see1through message3because it is posted onb, which they federate with.Option 2:
funny@cboosts post1as message2.funny@bis sent2and boosts post2as message3.user2@acannot see2through message3because2is oncwhich they do not federate with.