Glorified network janitor. Perpetual blueteam botherer. Friendly neighborhood cyberman. Constantly regressing toward the mean. Slowly regarding silent things.

  • 0 Posts
  • 8 Comments
Joined 9 months ago
cake
Cake day: December 27th, 2023

help-circle



  • Yeah, as a beehaw user, I’m pretty familiar with the situation. I’m not going to re-hash the whole thing here (and I don’t represent the instance), but let’s just say PR’s for features were offered, but not accepted. Discussion was attempted but it resulted in Lemmy devs asking beehaw to fuck off - so that’s the end of that.

    There’s an alternative being tested. I believe we’re going to Sublinks, but there’s still active development going and sizeable migration. So we’re still here. For the time being.



  • Thanks for the context.

    And yeah - a lot of fedi is built on spur of the moment inspiration without much planning on the long term. Sometimes it works out (like pixelfeed and the other related projects) and sometimes the passion of one (or small group) of devs just isn’t enough.

    Lemmy is pretty good example (from the other side of the scale) as well - we’re at version 0.18.4 - and the devs are pretty hostile.



  • “DM me on Twitter” perhaps wasn’t the best way to start a post about fediverse, but OK, I got through it…
    That article was a hot mess.

    First of all, over half of that article was based on misunderstanding of how fedi and ActivityPub works. Meta will not just “push their content” out to the fediverse and drown it - even if they fully adapt and integrate ActivityPub (which was still marked as TBD in the roapmap). ActivityPub is not a broadcast protocol. There is no “global federated feed” that can drown you. Someone actually has to subscribe to users and their posts for them to show up on their instances. Sure, some additional messages will be “discovered” during that (likes and re-posts etc), but it’s not like all of Threads just flows into all fediverse servers automatically.

    My timeline is posts from people who I follow. My local timeline are posts from people on my server. My federated timeline is all public posts from people (from other servers) that users on my server follow. It is trivial for me (as an individual) to domain block *.threads.net in my Mastodon user profile and then I will never see any posts from that server.

    The chapter about content moderation was also a bit misleading. On fediverse side of things, content moderation is done by instance mods. If and perhaps more likely, when it becomes too much work to deal with, they will simply just defederate or limit Threads.

    I’d imagine most smaller server admins and mods will eventually end up doing this, because they simply don’t have resources to moderate the message flow from a server that has hundreds of millions of users - this is already evident with mastodon.social and the other larger servers. Lot of places have defederated them.

    But this is all working as intended. Defederation isn’t controversial, it happens all the time.

    The actual moderation problem is entirely on Meta’s side. The fedi is full of bad stuff. Really bad, like CSAM. They will have to deal with all those kiddyporn .jp instances. Good luck telling that your shareholders Zuck.

    There are some real problems with Threads integration, but none of those were mentioned. I don’t want Threads to monetize my content. If I post something on Mastodon and a person from Threads follows me, I don’t want Threads to show them ads based on what I wrote. But currently there’s no way to prevent that.

    Also, if I should follow someone from Threads, there’s nothing preventing Meta from inserting an ad into that persons “Outbox” and therefore serving it to me on Mastodon. Sure, they’d be impersonating that user, but their whole business model is based on showing ads and datamining the clicks, so would be naive to think they wouldn’t enable ads on Threads later on.

    Of course the last problem is easy to solve by blocking Threads, but you get my drift…