4 ms·
"It is _very_ frustrating that the internet has had messenger fragmentation since the beginning of time" If you ignore IRC... "Signal just works." It also co
by betterunix2 6y ago
"It is _very_ frustrating that the internet has had messenger fragmentation since the beginning of time"
If you ignore IRC...
"Signal just works."
It also contributes to the fragmentation you complained about, because it is closed -- no federation, no third party clients, not even a web client. If you are on a platform the Signal team does not have time to deal with then there is no option for you. If you have a specific need that the Signal team cannot take the time to support, too bad. More problematic than lacking federation is lacking any third party client software.
Whenever I confront developers about this the conversation usually results in someone demanding a specific example of a user need they are not meeting; if I give one, they say, "Oh, we are planning that, but we first need to do $XYZ!" and if I say "there are needs we may not be aware of" they say "Well we are trying to do $this or $that, we can't solve everyone's problems!" As if users who have unusual or overlooked needs deserve to be cut off from everyone else...
- hiq 6y agoSignal is still an improvement over other non-federated messengers in that it's open-source, so you actually can try to improve the situation, although it's notoriously difficult. As an example of more platform support: https://github.com/signalapp/ringrtc/pull/12 https://github.com/signalapp/ringrtc/pull/12 signal-cli is an example of a 3rd party client which is tolerated for now: https://github.com/AsamK/signal-cli https://github.com/AsamK/signal-cli The main problem right now is that they don't have enough developers to take care of everything, but it's not specific to centralized services (no developer == no code). If you care about it, you can develop your own client using their library (à la signal-cli). Regarding your last paragraph: I could probably list 20 features I'd like to see in Signal. That doesn't mean I want somebody implementing them with no guarantee about how securely they are implemented. One of the main goals of Signal is to provide guarantees against dragnet surveillance, and that constraint takes precedence.
- t3chguy 6y agoOpen Source but not actively accepting contributions is not a great place to be. Especially when you can't federate, so you are stuck using the central server which basically doesn't accept code contributions. Take a look at https://merge-chance.info/target?repo=https://github.com/signalapp/Signal-Server https://merge-chance.info/target?repo=https://github.com/sig... Also it is somewhat interesting that this Open Source centralised Signal server, where centralisation means you can move quicker, hasn't seen a commit in 10 months. Compare it to Matrix Synapse https://merge-chance.info/target?repo=https://github.com/matrix-org/synapse https://merge-chance.info/target?repo=https://github.com/mat... The story with the flagship clients in both spaces is very similar.
- hiq 6y agoSure, I was mostly comparing Signal to proprietary centralized messengers here, not to FOSS decentralized messengers. Indeed they could do better.