Skip Navigation

Transitioning /r/rust to the Threadiverse

blog.erlend.sh Transitioning /r/rust to the Threadiverse

Three months ago I submitted a post to the Rust sub-reddit called 'Building a better /r/rust together'. It quickly rose to the top and ga...

Transitioning /r/rust to the Threadiverse
11
11 comments
  • I tried using Lemmy, but it's unusable. Every thread has <5 comments. It's a ghost town.

    I've seen this type of comment multiple times on reddit and I still don't understand this sentiment. It just shows that the OP has not once sorted by active and "nobody is using it so I'm not using it" is a pretty weak argument if you claim to "really like the idea".

  • "I don't like this centrally managed, corporate controlled social network. I'm going to move to this other centrally managed, corporate controlled network. It'll be different this time."

    At some point, we have to stop blaming Reddit/Facebook/Google/etc and start accepting that some people really don't learn from past experience.

    Lemmy sucks in a lot of ways, but it's something we control and can improve according to our needs rather than the profits of some amoral megacorp. I'll take that over yet another round of surprised Pikachu in a few years.

  • Oh my that comments section is a tad toxic, and not just because it’s critical of lemmy, that’s fine, but forceful and presumptuous.

  • So, the main blocking problem for transitioning to the Threadiverse is that there are too many alternatives?

    I know that the Rust project doesn't often make things "official", but in this case this would be a very easy way to solve a very real problem.

    1. Hold a vote, which server we use. Within all the community, with everyone who has push access on GitHub, within the Leadership Council, on URLO, whatever. It doesn't matter that much and, honestly, it's bikeshedding.
    2. Advertise it on the website and TWIR, and make the mods part of the Rust Moderation hierarchy.

    Later, when we have some way to collect communities together, we can diversify again to have a bit more resiliency against one server going down.

    I know the Leadership Council is probably busy, but I would really love if they would do this (though I'm not very deep in the Rust Project myself, so I can't kick this off).

  • (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:

    Image

    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.
11 comments