3 ms·

I am not willing to support Signal if they are unwilling to federate the system. Sure, it doesn't allow them the flexibility they'd like to have to move forwar

by m-p-3 8y ago

I am not willing to support Signal if they are unwilling to federate the system. Sure, it doesn't allow them the flexibility they'd like to have to move forward but in a way it won't be their fault if federated servers aren't keeping themselves up to date when there's a major protocol change and they get temporarily splitted from the pool.

Tomte 8y ago
Your „in a way“ is totally opposed to what normal users see. They will blame OWS when their Signal client that hasn‘t been updated in two years won‘t work.
wrs 8y ago
It doesn’t matter whose “fault” it is — the issue is the practical effect that will result. This is exactly his point with the SMTP and GitHub analogy from the “moving ecosystems” post. Why do you think the split would be “temporary”? As long as “email” is a thing, as in “just send me an email”, and it’s a federated set of randomly updated servers, “email” will never have end-to-end encryption, because the first version of SMTP didn’t have it, and the user will still expect to send messages to a server running that version. Similarly, if “Signal” is going to be a thing, as in “contact me on Signal”, the entire network effectively has to operate at the level of the least up-to-date server — otherwise it’s not one network, and the product is therefore unreliable. But there’s no way to enforce that all the federated servers update themselves in any amount of time.
- x0x0 8y ago
  Also, it's not like Moxie hasn't discussed this. At length. GP deliberately ignores Moxie's reasoned responses to exactly this issue.
thecrash 8y ago
Try to look at it from a user perspective, though. It's not a question of whose fault it is when something doesn't work, it simply doesn't work. Signal is successful in large part because it provides complex functionality (secure messaging) in a package that "just works". Federation complicates that significantly.

by m-p-3 8y ago

Tomte 8y ago

Your „in a way“ is totally opposed to what normal users see. They will blame OWS when their Signal client that hasn‘t been updated in two years won‘t work.

wrs 8y ago

It doesn’t matter whose “fault” it is — the issue is the practical effect that will result. This is exactly his point with the SMTP and GitHub analogy from the “moving ecosystems” post. Why do you think the split would be “temporary”? As long as “email” is a thing, as in “just send me an email”, and it’s a federated set of randomly updated servers, “email” will never have end-to-end encryption, because the first version of SMTP didn’t have it, and the user will still expect to send messages to a server running that version. Similarly, if “Signal” is going to be a thing, as in “contact me on Signal”, the entire network effectively has to operate at the level of the least up-to-date server — otherwise it’s not one network, and the product is therefore unreliable. But there’s no way to enforce that all the federated servers update themselves in any amount of time.

x0x0 8y ago
Also, it's not like Moxie hasn't discussed this. At length. GP deliberately ignores Moxie's reasoned responses to exactly this issue.

thecrash 8y ago

Try to look at it from a user perspective, though. It's not a question of whose fault it is when something doesn't work, it simply doesn't work. Signal is successful in large part because it provides complex functionality (secure messaging) in a package that "just works". Federation complicates that significantly.