#Medium link; don't be surprised if it does weird things before showing you the article.
"Mastodon brought a protocol to a product fight"
> Yes, yes, the network is under immense strain as people flee the Elon strain infecting Twitter. But come on, there are folks who really believe this is going to replace, or even stand alongside Twitter, as a massively scaled social network? I call bullshit. While it’s impressive that millions of users have apparently given Mastodon a try, the product is far too slapdash and clunky to keep folks engaged. A lump of coal.
No, it isn't meant to be a #Twitter replacement. Keep your Twitter account until you no longer want it--or the company closes and the site shuts down--you can use Mastodon alongside Twitter.
And the #Fediverse networks are much more than just #Mastodon. Don't think you have experienced the network and all it has to offer if all you've done is briefly tried to use Mastodon, because you haven't experienced it.
> I’ve somehow avoided signing up for the service up until now. Largely because signing up was and is so comically obtuse — pick your server everyone, hope you choose wisely!
Have you not used e-mail? It works the same way. You pick a server, such as Gmail or Outlook dot com, and sign up. Please tell me you realize that the people you communicate with are not all on the same e-mail service that you use.
> But, but, it’s not a product, it’s a protocol. Yeah, that’s a nice thing to say. And to believe in. But I truly believe the ship has sadly sailed for such idealism in this space. Jack Dorsey can talk about how this should have been what Twitter was from the get go until he’s bluesky in the face. It’s just not going to happen. And he’s more to blame for that than most everyone else. As is he for the Elon element of this current equation. But that’s a different story.
Okay, so how about this story: Twitter has only been profitable two or three years of its entire history. Since it started, it has existed by burning through investors' funds. Eventually, with or without Elon Musk's ownership, that runs out. Without such funding, their corporate-centralized ( #corpocentric ) model cannot exist very long. And same for their centralized competitors, such as Post.news, Gab, Parler, and so on. What is left is either #federated or #peer-to-peer approaches, where no single entity is responsible for funding and managing the entire network. So whether it is the #Fediverse ( with #ActivityPub and #OStatus and their successors ) & the Federation ( with #Diaspora ) or #Bluesky, or #Twister, or #NOSTR, the eventual future of #socnets is #decentralized, if not entirely peer-to-peer unless a national government takes over Facebook and Twitter in order to provide effectively unlimited resources. It is the protocol that makes it possible for thousands or millions of instances to displace and replace one big centralized instance.
♲ @denschub@pod.geraspora.de: Okay, here's a fun little story about a rabbithole I just fell into. It's about running the #diaspora project web infrastucture, and probably a glance behind the scenes.
Last week, I got an alert about unusually high load on the diaspora* project webserver. I was traveling for work, and the alert resolved itself after a couple of minutes -- so I ignored it. However, earlier today, I once again got alerted, this time about the wiki responding somewhat slow.
This was unusual. Some of our web assets, like the project's website or Discourse, do get quite a bit of traffic, sometimes holding a steady load of 5+ requests per second. The wiki, however, is not that. It generally only sees 5 requests or so per minute, so it was weird to see the wiki causing trouble. After some initial stop-gap measure, I had a closer look at the node, and noticed that the CPU load was on a significantly elevated, but stable, level. This, again, was unusual - because I designed the system in a way that allows it to handle quite large traffic spikes, and it shouldn't be under significant load on regular days.
Luckily, I have way more than enough metrics to investigate here. Looking at the traffic chart for the wiki only, it became very obvious that there was some sort of... deviation from the norm:
Again, traffic to the wiki is usually best measured in requests per minute - not requests per second. One could argue that diaspora* somehow just got very popular, but I have quite a bit of experience running services, and this chart didn't look natural to me.
The slow on-ramp of traffic over five days, and the occasional double traffic bursts, all of that looks like it's a bot (or a bot-farm) trying to see how far they can go before running into rate limits or load limits. So that's... odd - especially on the wiki.
Now, I have a few signals I can use to correlate requests with each other. In this case, I used the source IP and the User-Agent string provided. And it became quite obvious what was happening: A couple of crawlers, with the Amazon Web Crawler https://developer.amazon.com/support/amazonbot leading the list, followed by some .. shady and undocumented web crawlers, had a lot of fun crawling the entire diaspora* wiki in an endless loop - including images in various thumbnail sizes, all previous versions of all pages, etcetc. Not nice. But also easy to workaround.
I noticed a couple of other interesting things, though. A lot of people run their own webservice monitoring applications, and for some reason, people find it fun to add other people's web properties to the list. I guess that's fine if it's only one or two cases, but if a lot of servers request a page once a minute, .. well you're eventually getting to quite an accumulation of traffic. Anyway, that's annoying, but not on a level where it's causing pain. But some of you really really should update your application versions.
Another, and much much more intersting pattern I saw, was that... apparently, some diaspora* pods .. wanted to federate stuff to the wiki?!
All of those traffic sources are actual diaspora* pods. On rank 1, there's @Fla's diaspora-fr.org, and on rank 2, there's my very own Geraspora. So that was... odd. There's a couple of very odd things in here from the point of view of a diaspora* developer. In theory, diaspora* should not try to federate to... a wiki. Also, all those requests were GET requests, not POST requests like you'd imagine. In fact, the only case where diaspora* should send a GET request is when it's trying to fetch a public entity from another pod. Every single one of those request was a GET /Choosing_a_pod, and while I think that's a pretty important page on our wiki, ... y'know, it's not a diaspora* entity.
So what's going on here? After @Benjamin Neff and I spent a bit of time banging our head against a wall, we eventually found out what happened there.
A recently closed down pod, probably in order to help their existing users, set up a redirect to the wiki's Choosing a pod https://wiki.diasporafoundation.org/Choosing_a_pod page. But they didn't only do that for specific URLs, they just send all requests with a 301 status code to that wiki page. And well, that includes the HTTP routes used for federation. So every time those diaspora* pods wanted to send something to the closed down pod, they ended up requesting that wiki page. Fun times. But wait, didn't I say those requests were all GET requests? Well yes, they were! Even though diaspora* itself started out with a POST, that got lost somewhere.
I'm a webbrowser nerd, so I knew what was happening here, but I appreciate that that's not universally the case. So, to explain, what we're seeing here is a bit of an HTTP edge-case. The relevant specification says https://www.rfc-editor.org/rfc/rfc2616#section-10.3.2 (and yes, I know that that's an older version - but if you check the new versions, you will know why I quote RFC 2616 and not RFC 9110)
If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
Note: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request.
and well, yes, that's exactly what's happening here. diaspora* sees the redirect (and actually marks the pod as "down", so it will stop receiving federation packets in two weeks), but the library we're using then switches to a GET requests, and just... queries the wiki.
That's obviously a bug, and diaspora* should not follow redirects. Anyway. In the end, the requests caused by that bug were not responsible for any significant load on the server. But it was fun to dig into that. 😀
@simsa04 It's good to see that #Loomio is still around. #Diaspora used to use Loomio many years ago. (They also used either #GetSatisfaction or #UserVoice ... which are more like user-to-user support communities, and I think they used #Convore until it closed also.)
I wish I'd had the time and focus to document everything I've seen in the #federated #socnet space. I could probably write a book by now.
A #VPN provider that I used shut down without much notice (in fact, the only way I found out was that I visited their site months later, trying to figure out why I hadn't been able to connect).
The #hotel I was using had a local provider that blocked #Fediverse instances (including Mastodon.Social), #Diaspora, #XMPP, #IRC, and a certain mail provider that I still use. They did not block: #Facebook, #Twitter, #GMail, or Outlook / #Hotmail
Because I couldn't connect to the VPN, I discovered how many perfectly normal sites were blocked because they weren't on the top 100 list. I went downstairs and informed the front desk that I would be leaving their establishment because of their blocking.
I received a phone call from their networking vendor, who logged into their router and proxy and turned off filtering on a list of about 25 sites they'd blocked.
But the point is, the hotel and its provider cannot be trusted not to fsck with your data. Always use a VPN.
#Pleroma (and I assume #Mastodon) have ‘relays’ built in, where an instance can join other instances’ relays, so that their outgoing traffic is shared with all the other instances that are members of that relay.
The advantage of a relay is that all of an instance’s public posts are automatically shared with other participating instances, where a followbot follows each user individually.
(Another thing that #Diaspora did a long time ago to improve federation.)
Hat Thieves (formerly at hatthiev.es/ but that appears to be gone now) was a group from Spain that was exploring independent and federated services. They operated GS, Mastodon, and Pleroma instances, plus lots of other FOSS but not federated things.
Whenever they opened a new federated instance, they’d immediately start following a bunch of people, to get posts into their network feed. The Masto and Pleroma instances would get angry and mass-block the instance.
Looked at the #Linux tag on #Diaspora again. @linux has posted 13 posts in about 2.5 hours (12 article links + a daily round-up link). Of course you know it is Tuxmachines, part of Roy's kingdom of article factories.
This is why I rarely ever log in there anymore. Very few actual people, zillions of linkbots churning out article links in popular hashtags.
(There was one guy that had at least three linkbots that each posted the same links within minutes of each other. I guess he could have done manual copy-pasting, but that would be boring, repetitive, and error-prone. I finally blocked him. I guess I need to do the same for Tuxmachines and similar linkbots.)
@moon@shitposter.club Is releasing a series of "Masters of the Fediverse" #NFTs and the first one will be @schestowitz ... which is why I asked if he was even still here.
His volume of posts on #Diaspora was so high that I finally had to unsubscribe from the #Linux hashtag. If I recall correctly, he posts a link, then one of his sites posts the link, then another site posts the link ... all camped out on the Linux hashtag.
I haven't logged onto #Diaspora in a while. Most of my contacts don't post anymore and the tags I follow are full of obnoxious botposters.
Although I'm thinking of spinning up an experimental (e.g., non-backed up and likely temporary) D* instance for us.
Can you describe what you experienced? Could it have been related to the recent series of updates (kernel, systemd, glibc, etc) that have required reboots every 2-3 days for the last couple of weeks?
So far, each time, everything seems to have come back okay, except that I'm still starting the #queuedaemons manually when they really should be automated.
I think the #blockwars folks may have indirectly caused this. There are people who file complaints against client apps that don’t build in blocklists against specific servers whose moderation policies they dislike.
I think that #Matrix / #Element competes with one or more Google-owned chat-type services. Since they gatekeep the overwhelming majority of Android users’ software installation, a good antitrust lawyer would be helpful. I’ll bet that faxing a bunch of documents to #USDOJ and various states would suddenly cause Google to decide that Element doesn’t violate their policies anyway.
(Someone said it was “Boomers at Google that don’t understand federation”, but first of all, I’m certain that most GOOG employees are far younger than you and I, and secondly, I’m sure someone at Google understands federation, though they obviously dislike not being in control. Google Talk was federated with #XMPP, while Google Plus was basically #Diaspora with federation stripped out.)
(1) #Twitter has millions of users. There is no #ActivityPub nor #OStatus implementation in which an instance hosted on a $5/mo #DigitalOcean / #Linode / #Vultr #VPS could handle the volume of a seamless connection with #Twitter. If they adopted AP OStatus, #Diaspora, or any other current open federation protocol, instances that didn't use firewall blocking would topple once the two userbases had sufficient interconnections (within a few hours or a few days after they started federating).
(2) Twitter's business model is to push ads disguised as tweets. If their users could escape those and still interact with all the same contacts, they would. I'm certain that Twitter's management know this. They also turn all links into tracking links, and sell access to media (images, video, audio) uploads of important news events to news organizations.
(3) Most Fediverse instances are financed out of the admin's pocket. Some have financial contributors, but nothing like Twitter's revenue. As the largest and best-financed instance, they would immediately have to start implementing modifications to make AP or other existing federation protocols useful to them, and those modifications would (as Mastodon's currently do) become unofficially mandatory in order to be compatible.
(4) This isn't the first time that Twitter has considered federation, though this may be the first time they openly discussed it. Back when Identica was still a happening place (during Twitter's fail-whale days), Twitter considered federating. They didn't do it then, and I honestly do not believe they will do it now.
(5) I'd say that Twitter's #BlueSky initiative is more meant to try to get bidirectional connections across #Facebook's moat and wall than it is to surround Twitter with a cloud of #Fediverse instances.
I know this because JoinDiaspora sent me a bunch of notification e-mails about people’s birthdays. (I think it just assigned YYYY-JAN-01 for anyone that didn’t fill out a birthday; as far as I remember, giving that information wasn’t even an option when I joined #Diaspora. I truly think it is betraying the “we’re privacy focused” approach they promised all those years ago. #JD, this should be something that accounts opt into.)
@vegos I agree. To most organizations, their primary concern is reach. So they congregate on big #corpocentric #socnets, even when the central corporation running things is actively hostile to their point of view.
Then they're butthurt when their accounts are shadowbanned.
Years ago, I tried to persuade some local Black churches and ethic-focused organizations to join !GNUsocial and #Diaspora, but was unsuccessful. I think they all joined #Facebook, where their posts are hidden by the algorithms.
♲ @AlexVoss@fosstodon.org: Student of mine is conducting a survey on the barriers to uptake of alternative social media platforms. Your input would be much appreciated. Please boost.
I am conducting an anonymous survey for my MSc dissertation on the barriers to uptake of alternative social media platforms. If you're interested, please click the link below. Your input would be much appreciated!
The #SARS-CoV-2 virus, the #coronavirus that causes #COVID-19, blocks one arm of the body's anti-virus defenses, while stimulating the other. This unique behavior allows unhindered replication while causing inflamation.