Decenteralization and Server Upgrade Reguards [Solved]

Since Disroot is Federated and Decentralized then there should not be any downtime at all? Because decenteralization is the distribution of servers contributing to a single/multi network (ensuring no downtime).

This is simply a question, I understand that the main staff is located in Amsterdam. This simply puzzles me.


This isn’t to bring doubt, confusion, or be malicious. This isn’t compliant: as a previous web developer (once) I have an idea of the struggle. Above just a question.

Decentralization and distribution is meant in the context of network of services and service providers, not disroot only. Let me explain a little.

The best example of decentralized and federated service is email. Email is decentralized (anyone can deploy their own, its not own nor belongs to one entity), and is federated (you can send emails between servers that are owned and run by independent service providers). So in that sense its disroot as a whole being just a node in the network of federated service providers. This means that although such network (email) will not be offline for the duration of maintenance, the service on our side (people with mailboxes all over the world will still be able to send emails), disroot users will be unable to as the server will be offline.

Similarly all other federated services we host like Jabber/XMPP, diaspora, hubzilla, nextcloud, email, matrix will operate with no issues even when disroot is offline, or even stops to exist. This however does not mean it will work for disroot users (exception is hubzilla that implements genius nomadic Identity enabling you to have multiple clones of your account spread around other servers in the network). Federated nature of services is not providing no failure point and redundancy for disroot, but network as a whole. For example, diaspora network cannot be shutdown nor it can be sold, etc as anyone is free to setup their own servers and federate content between creating network of independent servers.

To achieve scenario you have in mind it means we would have to setup internal redundant infrastructure where putting one server down does not put down the service. This however means we would need twice as much money and hardware to be able to support it. It’s a very good concept and I hope we will get there one day, but at this moment it’s far beyond the reach. That means downtimes in current setup are inevitable.

Does this explains a bit more the concepts? Let me know because I continuously look for better ways to explain concepts of federated services.

1 Like

I wholly understand the situation and concept now. Thanks :slight_smile: :+1: