Me: “After a long consideration, I’ve decided not to defederate Threads from my personal instance, because the benefits of being able to reach out to my friends and relatives using the open tools that I’m contributing to build and run outweigh the risks, but I’ll keep an eye on it, I may reserve the right to block Threads later, and I respect and understand those who prefer to block them instead“.
Easily triggered strangers: “You self-entitled privileged cis tech bro, you are not doing enough to protect vulnerable minorities from the fascist harassers in the world out there, I hope you die from a gut infection“.
So much for “the Fediverse is an open place that embraces diversity and mutual respect where everybody should feel safe”.
I feel like @zuck may achieve his goal of killing the #Fediverse through divide et impera without even needing to kickstart the E-E-E phase.
The simple announcement that #Threads is going to federate has caused such a huge backlash, and so much pressure and retaliatory blocks and defederations towards users and admins guilty of not doing enough to block this perceived “cancer” (including @Gargron), that I feel like the Fediverse is at risk of splintering in two - a subset of instances that decided to deferate Threads, and another subset that decided not to defederate it and wants to cut all the bridges with those who haven’t.
@dg3hda what I care the most is the open protocol. If ActivityPub reaches critical mass, then the whole industry may be pushed into adopting an open standard that will lower entry barriers and benefit everyone. If we shut down any efforts towards external integrations (it’s not only about Threads, I’ve seen very similar arguments made also when Wordpress/Tumblr/Flipboard federated or considered to federate) because we want our open solution to be used only in a safe and controlled environment, then the world outside of the Fediverse is more likely to be stuck in proprietary solutions.
@fabio activitypub has everything to federate. If there are different fediverses with different cultures, ok - you can sign up there if you want. Meta otoh needs to be isolated.
@fabio something with the different cultures I implied should be explained: if one universe deteriorates, you can effectively leave. Hard if it's a big conglomerate. (I left twitter, still using FB but reducing and considering leaving too. Wouldn't like too have it haunt me here.)
@dg3hda I still don’t see the problem. If me, as an admin of an individual instance, wants to federate with Threads, that shouldn’t automatically make me a part of a “Fediverse subset” in mutual exclusion with others. If there are concerns about “second hand smoke” and ways to circumvent defederation, then we can talk about them, but at least AFAIK from a technological point of view most of those loopholes should be either closed, or provide configuration options (like authenticated fetch), if a specific instance admin is actually concerned about them.
If Threads goes haywire fascist or full E-E-E tomorrow, I can always defederate it and keep interacting with the other instances I usually do. I don’t see a whole universe “deteriorating”.
That also partly answers the “why be Meta’s guinea pigs?” problem: we’re not. If we have a solid fabric and good distributed governance, Threads can do whatever they want: the Fediverse will keep existing with or without them.
And the other half of the answer is: the chicken-and-egg problem. We all know what’s the ideal final outcome - all social media solutions use at most 1-2 open protocols with low entry barriers, without sufficient incentives to develop new proprietary protocols. Just like today there’s no incentive to reinvent proprietary versions of TCP or HTTP: you don’t reinvent a functioning wheel that everybody can use unless you have an amazingly brilliant reason to do so.
But that means that also the existing large platforms have to start in some way. For as much as I would love #Meta to implode into itself tomorrow, that’s statistically unlikely to happen. Until then, we have to create the right incentives for them to change, or most of the human population will still be trapped in the same cages even a decade down the line with no viable alternatives.
The #DMA gives a nudge in the right direction, by forcing gatekeepers to make their platforms inter-operable, but it doesn’t suffice by itself. Without sufficient incentives to implement ActivityPub (like being able to potentially interact with a couple of millions of users on existing platforms that already implement it), these companies just won’t have enough incentives to seriously commit themselves to adopt it. In a couple of months they’ll come back to Brussels or Washington and say “well, we’ve tried to adopt an existing open W3C-approved protocol, but we met too much resistance from the existing communities, so instead we’ve decided to build <put-tech-bro-foundation-name-here>, a consortium that includes Meta, Alphabet, X, BlueSky and ByteDance, to build a new “open“ protocol that allows anybody to join - provided that they pay a fee to the foundation, sign a couple of NDAs and accept a couple of custom EULAs, and we allow them to join the club”.
I have no doubt of which outcome is the best for technology and society at large.
The reason that could happen is a consequence of one of the core problems that fedi doesn't solve: servers controlled by admins.
Hence we need even less centralisation of the levers of power, and increased choice and autonomy for users. I'm hopeful #p2p will do this and that 2024 will be the year we see the beginnings of that.
#Fedi was a step in the right direction but never going to solve these issues using traditional servers.
@HedgiePT
There are quite a few p2p projects but most aren't capable enough IMO. The one which ticks most boxes for me is #Autonomi. I'm working on a demo app for it. It is due to launch in October but people are able to play with the early beta.
Are you a developer or interested as a user, or? @fabio
@happyborg@HedgiePT if you have a forge link (I couldn’t find any references by name) I’m happy to take a look when I have some time.
I would love to help either on the protocol side or the coding side, but I’m afraid that I can’t really commit much - I already maintain a dozen active open projects and my time is more stretched than Dali’s clocks. But if I see the potential I may make some time for it.
@fabio
They launched the Autonomi brand only a couple of weeks ago and things are still changing over, so you will find info searching for the previous name #SafeNetwork, and MaidSafe.
The forum at https://forum.autonomi.com is a great resource and the entry to trying out the beta test networks, and the code is at https://github.com/maidsafe/safe_network API documentation is partly on the rep and API detail is on https::/docs.rs as the project is written in Rust.
And I agree, p2p would be the best solution, probably as simple as a stand-alone app that you can start when you want to post something or read something, and it would connect on the fly to neighbouring trusted online nodes to relay the content over a DHT. But I honestly can’t wrap my head around all the problems related to fitting something like ActivityPub on top of something like Bittorrent’s DHTs (content delivery guarantees, distributed trust issues…). It would definitely take a while to design properly, and another big while to implement properly.
The quickest solution IMHO would be to have more alternative ActivityPub implementations that have lower entry barriers for users to run. I think that #Mastodon is actually a big part of the problem. It runs on 73% of all the instances, and it’s a beast to run. I had a mostly personal Mastodon instance before, and I had to run it on a Linode host because my home network couldn’t handle the amount of traffic it generated. It would eat up 5-6GB of RAM at its peak, and required me to permanently store a ~100GB cache on an S3 bucket just for the cached media. Eventually, at its peak, running the whole thing would cost me ~$100/month. Something like this is definitely not within everybody’s reach. You can’t say that you have solved/democratized the problem of distributed social media when the most popular solution available requires to spend $100/month on a cloud node and knowing all the internals of how to maintain a Ruby on Rails server application.
I like Pleroma/Akkoma because they lower that barrier - I can now run an instance in my home network, it takes only a couple of GB of storage and ~1-2GB of RAM. But they’re still relatively immature. And that bar could be even lower.
@fabio You're right that it is a very difficult challenge. I've been following and helping with #Autonomi for ten years, and they had already been working on this for eight years before that!
But at least they have a working autonomous network and are ramping up for an October launch.
It won't be replacing Mastodon right away, but it will be delivering useful, democratising capabilities and the potential to remake the web to serve everyone.
@fabio In all honesty, if they want to defederate from everyone else, I won't complain, they'll just be leaving the Fediverse.
What makes an instance part of the Fediverse is the fact that it federates with the rest of the world, not that it uses software called Mastodon (as it seems that most people "defederating" are on Mastodon, and most don't even seem aware that it's not the only platform here.)
Not federated platforms using Mastodon exist, for example Truth Social. The defederating side belongs perfectly with such places.
Mmm, that’s like saying tolerance requires accepting the intolerant.
My proud Popperist side is horrified by this interpretation of my words.
I firmly believe that it’s our duty to be intolerant towards the intolerant, and proactively kick fascist asses to the hell they belong to.
But when “intolerant” is applied as a label to anyone who doesn’t proactively defederate a platform where the definition of “intolerant” is statistically likely to cover at most 5% of its user, I have a problem.
In short, I don’t think that it’s ok to be intolerant towards those who are on the same side as yours, but just happen to have a different “intolerance tolerance” bar, because nasty fracturing feedback loops may occur from such a transitive law.
And I also don’t believe that voluntary reclusion that excludes that 95% of potentially innocuous users amid fears of encountering that 5% of potential jerks is a scalable solution that empowers vulnerable people to be really part of the society - it instead reminds me a lot of the features of a cult.
@fabio it sounds like we have similar principles and goals but a different idea of what's important to realise them. Which is completely ok, necessary really.
Personally I don't see how people can look past Meta v fediverse and justify helping Meta in order to connect with people who are still there. It's one of the reasons they can exploit and abuse those people, and anyone visiting a website that helps them track even non Meta users.
I don't get abusive but I understand people's anger.
@happyborg well, if we talk from a strictly technical point of view, I don’t see the issue there.
I mean, if an admin of an instance cares that their garden is completely insulated from risks of scraping/forwarding of their user content, then they already have the tools for it:
Encourage user who care about their privacy to make their profiles private / followers-only.
Disable /.well-known/webfinger.
Enable AUTHORIZED_FETCH on their instance configuration (Pleroma’s APIs are authenticated by default, but Mastodon requires that environment variable to be explicitly enabled).
Encourage other federated instances to also enable AUTHORIZED_FETCH.
If all these four conditions are met, I don’t see how Threads, or an instance federated with Threads and also with theirs, could be exploited to extract information about their users.
Meeting all four conditions means that:
The posts of a user aren’t publicly accessible, and they can’t even be crawled by a search engine nor by an under-the-radar bot instance. If some admins complain that my instance not defederating from Threads threatens the safety/privacy of their users, they should probably first make sure that their profiles are actually private and their content isn’t already indexed on a search engine. Because that’d be like asking me to close a small door on the back when they’ve actually let the flood gates open.
AUTHORIZED_FETCH closes the loophole on the “indirect content fetch” side. Consider this case: instance B is federated with both A and C, but A has adopted a strict “no-C” policy, while B has implemented a “wait-and-see” policy. If user Y on instance B boosts/quotes a post from user X on instance A, and both instance A and B have AUTHORIZED_FETCH enabled, then a request from C to download the post from B with the quote from A will have to go through an authorization phase from both A and B. If either fails, then the user on C will either see an empty post or nothing, depending on the implementation.
That’s what I mean when I say that, technologically speaking, we already have the tools to ensure that those who want their content to be shared with a controversial instance, but don’t want to lose the existing connections to other instances on that basis, can already do so without any side doing compromises.
If we want to talk about the ideological side, and whether we want to build a community with a single consistent position on certain issues, or a set of independent islands with different values that can still communicate talk to each other, regardless of who else they also like to talk to, then it’s another thing.
p.s. I think that AUTHORIZED_FETCH helps but it’s not the ideal implementation. For the chain to work, all the instances in a “federated chain of trust” need to enable it, or the risk of exposing unwanted content (especially upon repost/quotes) is non negligible. And the fact that it’s not even enabled by default on Mastodon (the software used by 73% of the servers here), and that many admins don’t even know about it, or didn’t enable it, means that my little Akkoma instance (with authorized fetch) federating with Threads is the least of the problems. IMHO either that option should be enabled by default (even if that means breaking back-compatibility with instances that run Mastodon < 3), or complemented by another feature that doesn’t require strong authentication (like chains of referrals).
@fabio This really is a very good post which explains the various privacy scenarios with 'your' instance on the Fediverse. I run a small Akkoma instance, pretty much for myself.
I have to admit that I only get the gist rather than having a thorough understanding of it all.
I wonder if someone has the skills to make this into an infographic to provide people with understanding and reassurance?
@gruff@happyborg honestly I haven’t found much around. Everybody seems to hysterically yell “we all must defederate Threads, otherwise everybody’s privacy will be diluted!”, which means that few probably have a clearer picture of the settings already available and how cross-instance content forwarding works. I may work on putting together this information in a more articulate stand-alone post.
Disclaimer: this information is based on my understanding both of the protocol and the available settings, which in turn are based on on skimming through the source code myself. I’m not sure if other loopholes are available (for example posts cached on other instances and indexed), so I’d love to get confirmation from someone who has contributed to the Fedi more than me.
@fabio Maybe somebody like @evanprodromou has a take on this? I'm certain that better education (simple to digest infographics) would go a long way quell the hysteria. The reality is that this is not just a convo specific to Threads, it's about interoperability more generally isn't it?
@gruff@fabio my take is that a lot people don't know that they can set their accounts private, or change their servers to allowlist federation. I think sharing that info is a big help.
Add comment