- cross-posted to:
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- cross-posted to:
- [email protected]
- [email protected]
- [email protected]
- [email protected]
Cross-posted to Reddit: https://www.reddit.com/r/rust/comments/162keij/transitioning_rrust_to_the_threadiverse/
(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
,b
andc
wherea
defederatesc
, buta
also 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 botha
andc
, 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 post1
to the community onc
… What happens?Option 1:
funny@c
boosts post1
as message2
.funny@b
is sent2
and boosts post1
as message3
.user2@a
can see1
through message3
because it is posted onb
, which they federate with.Option 2:
funny@c
boosts post1
as message2
.funny@b
is sent2
and boosts post2
as message3
.user2@a
cannot see2
through message3
because2
is onc
which they do not federate with.