• 1 Post
  • 11 Comments
Joined 1 year ago
cake
Cake day: June 15th, 2023

help-circle

  • They’re insufferable commies who keep attacking other parts of the Fediverse by… uh… commenting on posts and… ehm… responding aggressively to bigoted content. They’ve got all these sick ass stickers that we don’t and they keep flexing them in our replies which drives me crazy.

    Their instance is an authoritarian distopia where queer people feel safe and they don’t waste time debating the same wrong liberal talking points every time. Also you can just call someone a dumbass if you disagree with them: a totalitarian nightmare.

    Worst of all they go around straight up bullying other Fediverse users: right now I’m locked in a bathroom stall that a Hexbear user shoved me into. I’ve been here for an hour missing my maths class, and I’ve had to drink the toilet water. My tummy is starting to hurt. Stay away from Hexbear users…



  • I had high hopes when I tried it out but frankly it’s been almost unusable for me. Terrible performance, laggy UI, plenty of bugs, long loading times for songs…

    I don’t know if something in my mobile environment was messing with it but I use quite a few indie FOSS apps still in beta and none of them worked as badly as Spotube did. I’d love to go back to it if it improves, but for now it’s just not worth the UX pain.

    Edit: forgot to mention. The idea of sourcing tracks from YouTube is cool but causes loads od trouble in practice. I’ve found remixed versions streamed as the original, tracks with the intro from the music video, tracks with sound effects from the music video, and tracks that just cannot be streamed cause they aren’t on YouTube. I know there’s a feature to pick which version to stream, but it’s quite a bit of UX friction and it didn’t work often enough to be a showstopper.






  • Eh, it’s a bit naive IMO. It’s nice to focus on your small, close-knit community, but it does not live in a vacuum. At some point the world (read: capital) will come knocking at it’s door, and if you’ve been sticking your head in the sand until now you will not be prepared for what happens.

    Also, what if I don’t want my community to be small and close-knit? Lemmy is way more interesting now that it was a month ago, after growing by an order of magnitude. Ask anyone who’s grown up in a rural town and they’ll confirm this: tiny communities are fucking boring.



  • I understand the logic, and you’re right to think about how improve Lemmy’s scalability. But I’m not sure if this is the way to go.

    If you build a dedicated federation proxy for an instance, you’ve really just slightly moved the problem. The federation proxy is going to have the same scalability issues, and if anything the total load goes up.

    If you build multi-instance hubs, you suddenly introduce a lot of new issues.

    • Security: I think Lemmy checks the source of an update to verify that it comes from the legitimate host. You would have to introduce some kind of signatures to verify that the activity originated from the legitimate host.
    • Privacy: now your users have to trust the hub owners with their data, not just the instance.
    • Motive: who would be running the hubs, and why? They would have to be even bigger that the instances, and there would be much less incentive to do it.

  • Other people in the thread have already made this point: even with a full mesh network, the number of remote calls made for a single activity is equal to the number of instances subscribing to that activity (plus one if the activity originates from an instance that’s not the host of the activity).

    A hub/spoke model doesn’t change this, it just moves the load from the host instance to the hub. The number of connections is still the same: if N instances need to receive the activity, N calls will have to be made. If anything this adds 1 more call from the host instance to the hub.

    Even peer-to-peer distribution of activities, mentioned by @[email protected], wouldn’t actually change the amount of calls being made. You still have N servers that have to receive the activity, so you need at least N calls overall. What this would do is redistribute the load better over instances, so the host doesn’t have to make all N calls. It would definitely be an improvement, but it would not be easy to implement successfully, and it would almost surely break ActivityPub compatibility.

    The only thing I can think of that would actually reduce the overall network load, though, is batching: sending multiple activities/updates together in a single message. AFAIK this is not supported by ActivityPub, though, so implementing it would mean breaking compatibility, and also implementing an entirely updated version of the protocol (which is a massive undertaking).