Threads, Facebook, Instagram and Whatsapp all went down today, because they are centralised services owned and run by Meta.
-
Threads, Facebook, Instagram and Whatsapp all went down today, because they are centralised services owned and run by Meta. When Meta breaks, Meta's services break too.
This doesn't happen on the Fediverse because it is thousands of totally independent servers owned and run by thousands of different people. If one server goes down, the other servers keep running.
This is one of the reasons why decentralisation is so important: it makes networks more resilient through diverse ownership.
-
@FediTips In fact I'm enjoying my contacts in panic: "what can I do, Facebook / whatsapp / instagram don't work" - I said "fastest solution is" [giving them some Fediverse-related sites]. Start from there. ...Seriously, that's why I refuse buying Meta Rayban smartglasses as an aid for my blindness. If BUG techs decide to go down, they blind me again ๐งโ๐ฆฏ
-
David Chisnall (*Now with 50% more sarcasm!*)replied to Fedi.Tips ๐ last edited by
@FediTips If the instance that Iโm using goes down, it doesnโt really matter to me that only the bit of the Fediverse that I use is down and not the rest. The surprising thing is that small instances run by volunteers seem to have less downtime than centralised systems run by teams of well-paid SREs.
-
mkjreplied to David Chisnall (*Now with 50% more sarcasm!*) last edited by
@david_chisnall Indeed, it doesn't really help *you* if the one part that's affected is the one that you use. But then again, that's the case with pretty much everything else, too.
It doesn't help me if others' banks still work if mine's having problems.
It doesn't help me that the next town over has electricity if where I am doesn't.
And so on.
That there can still be problems (you're 100% right: there can) doesn't mean creating a situation where one affects everyone is better.
-
David Chisnall (*Now with 50% more sarcasm!*)replied to mkj last edited by
That there can still be problems (you're 100% right: there can) doesn't mean creating a situation where one affects everyone is better.
It isnโt better or worse. For most users, the thing that matters is the amount of downtime. If power goes out in each town in a country for a different week, is that better or worse than if the power goes out in the entire country for ten minutes and then comes back? Aside from the impossibility of doing a cold start of most electricity grids, I would expect most people to be happier in latter case.
The case with federation is more complex because two people canโt communicate if either of their endpoints is broken, so the failure modes are difficult to reason about individually.
Even though the aggregate network may never go down, in the same way that email is never down for everyone, that doesnโt really matter to most users. The thing that matters is how much there is downtime that affects them.
Being able to use a backup instance is not really a solution, because most Fediverse software doesnโt allow you to synchronise feeds across instances, so you canโt just fail over. Email is slightly better in that you can often send emails from an alternative server if your primary is down but you generally canโt receive them.
It is possible to build replication, transparent fail-over, and so on in a federated system, but ActivityPub doesnโt try to do any of this.
Psychologically thereโs also a difference. When something is down for everyone, thereโs shared commiseration, when itโs down for you that can be harder, especially when youโre the one using the unusual thing. When a thing that โeveryoneโ uses is working and the weird thing you use is down, people are less sympathetic than when the thing both of you use is down.
-
Stefano Marinellireplied to David Chisnall (*Now with 50% more sarcasm!*) last edited by
@david_chisnall @mkj @FediTips Exactly, the backup account unfortunately does not solve the problem. I'm always amazed at how certain issues have been solved decades ago with other technologies and yet are still not addressed by more recent ones. For example, I have two email servers on two different providers and two different countries. Two autonomous MX records and Dovecot keeps the maildirs in sync. In case one goes down, the SMTP servers will automatically fall back to the other SMTP, and my DNS will automatically point to the remaining server for IMAP connections. It's not perfect, but it's certainly more resilient than the current implementation of ActivityPub
-
Fedi.Tips ๐replied to Stefano Marinelli last edited by
ActivityPub isn't perfect, but it's certainly better than centralisation.
That's all I'm trying to say with the original post, I'm trying to get across to a mostly non-technical audience why a network being on many servers is preferable to putting all your eggs in one basket.
Most people are unaware of what is even being aimed for with decentralisation, even though they benefit from decentralised networks all the time (such as on email).
-
David Chisnall (*Now with 50% more sarcasm!*)replied to Fedi.Tips ๐ last edited by
That's all I'm trying to say with the original post, I'm trying to get across to a mostly non-technical audience why a network being on many servers is preferable to putting all your eggs in one basket.
But that's my point. To a non-technical audience, it doesn't matter. To a non-technical audience, their instance going down for a federated service, or their availability zone going down for a centralised service are indistinguishable. And 'Twitter is down' is an easier thing to explain than 'your bit of the Fediverse is down, but the rest of it is fine'.
There are a lot of benefits from federation. Being able to have a second source if one provider has terms you don't like, for example (though the fact that ActivityPub requires cooperation from the original instance to transfer your followers is a potential problem).
Federation and fault tolerance are orthogonal problems. You can build a fault-tolerant distributed system. You can build a federated system with a load of single points of failure. There are enough good reasons to prefer a federated system without claiming this one, which is a real stretch.
-
1a1nCreplied to David Chisnall (*Now with 50% more sarcasm!*) last edited by
@david_chisnall @FediTips @stefano @mkj Question - in the fediverse, is there a way to backup and be able to recover/ move an account if my host server goes boom? (like - no notice, crashes, ISP goes bust, maintainer gives up and pulls the plug one night etc.) - if not then this is a feature that needs to happen
-
Yes and no, it's a bit complicated
Try to join a reputable long-running server that has promised to give warning if it intends to shut down, takes daily backups and has more than one person with admin access. (You can find lists of these at https://fedi.garden and https://joinmastodon.org/servers)
You can use Mastodon's "export and import" feature to back up follows, bookmarks, lists, mutes, block, domain blocks and posts. However, there's no way for users to import posts at the moment.
-
@[email protected] @[email protected] Just to add on to this, any instance within the mastodon covenant by definition has to give at least a 90 day notice before shutdown. https://joinmastodon.org/covenant
-
@[email protected] @[email protected] Of course, this is more of a promise that can be broken. There's not really a way of 100% knowing whether an instance is going to give advanced notice. I mean, you can say that you are but I don't see the incentive to stay on the mastodon covenant once you're shutting down other than just to do a clean exit. Personally though I haven't seen a case of someone just lying about it. Instances that I thought might have had an explosive ending such as https://emacs.ch/ gave the 90 day minimal notice.
-
Yeah, most of the shutdowns of long-running servers I've seen have been graceful. Mastodon.technology for example went out of its way to warn people in good time, they even set up special CSS code warnings when people logged in. Botsin.space which is about to shut down has been similarly proactive.
I've also listed covenant-compliant servers by founding year so people can see which ones have the longest track record:
-
@[email protected] @[email protected] oo i like the "compliant" part because I was just about to say transfem.social doesn't run mastodon but I like to think that we're compliant in spirit.
-
@[email protected] @[email protected] speaking of i need to revise our rules because most of them are redundant and i don't like the wording but i digress.