All of this user’s content is licensed under CC BY 4.0.
That’s just open source, not decentralized.
Depending on exactly how said open source development is occuring, I could argue that open source development is an example of decentralization. It may even be an example of federation (all depending on licensing and development medium imo).
it’s decentralized
No it’s not. From literally your own comment:
Signal relies on centralized servers
I was using “decentralized” to mean that there isn’t centralized control over ownership of the service in general — eg anyone can spin up their own server (impractical, imo, pushing it more towards being centralized) and people can use it (making it decentralized, imo (Please correct me if I am wrong, but I do think my usage of the term is appropriate in this way.)), but people who use that server can only communicate with that server (making it not federated). But yes it could still be said to be centralized in that it operates on a client-server model [1].
This is more an argument of definitions, though. I’m not trying to claim anything in bad faith.
My comment wasn’t protesting the use of Signal; it was rather clarifying the misinformation in OP’s post — ie misinformation that Signal is a federated service.
Signal isn’t federated [1][2][3.1]; it’s decentralized [1][2][3.2]. Though, for all practical purposes, I would generally argue that it’s centralized.
Signal relies on centralized servers that are maintained by Signal Messenger. In addition to routing Signal’s messages, the servers also facilitate the discovery of contacts who are also registered Signal users and the automatic exchange of users’ public keys. […]
One of the controversial things we did with Signal early on was to build it as an unfederated service. Nothing about any of the protocols we’ve developed requires centralization; it’s entirely possible to build a federated Signal Protocol-based messenger, but I no longer believe that it is possible to build a competitive federated messenger at all. […] [interoperable protocols] [have] taken us pretty far, but it’s undeniable that once you federate your protocol, it becomes very difficult to make changes. And right now, at the application level, things that stand still don’t fare very well in a world where the ecosystem is moving. […] Early on, I thought we’d federate Signal once its velocity had subsided. Now I realize that things will probably never slow down, and if anything the velocity of the entire landscape seems to be steadily increasing.
An open source infrastructure for a centralized network now provides almost the same level of control as federated protocols, without giving up the ability to adapt. If a centralized provider with an open source infrastructure ever makes horrible changes, those that disagree have the software they need to run their own alternative instead. It may not be as beautiful as federation, but at this point it seems that it will have to do.
Well dang, I have Nextcloud installed as a snap (which has been perfectly stable for me when running on Ubuntu Server), but I was thinking of switching over to a docker installation; this thread doesn’t exactly fill me with enthusiasm for that idea…
Imo this fits my usage of the term — Signal can be broken up into many isolated servers all offering the same service.