Hacker News Reader

Comment by shafyy | Hacker News Reader

I'm a bit worried that the CEO is so vehemently against federation [0]:

> It is unlikely that we will ever federate with any servers outside of our control again, it makes changes really difficult.

I think as long as there is no federation there will always be the "benevolent dictator" situation, which often doesn't end up well in the long run.

At the same time, I'm sure that I couldn't convince my non-tech friends to switch over to a federated protocol like Matrix. The clients have been getting better, but they still lack a lot of mainstream UX. So, while Signal is better than WhatsApp for now, I think the only sensible solution is a federated protocol.

0: https://github.com/LibreSignal/LibreSignal/issues/37#issueco...

View on HN

One reason which I chose Matrix over Signal, other than being forced fo tie my identify to a phone number and depend on a smartphone for receiving mesaages.

Same. There's also the fact that Signal never really convinced me that it's better than Matrix.

Though if I compare Matrix and Keybase, there's a clear winner in terms of UX and depth of features. I will be missing that but there's no indication Matrix or Signal will reach feature parity before it's replaced. (A new messaging protocol and no isolated subservers with their own chat rooms? Really? This is why people are switching to Discord in increasing numbers)

Also the reason I have 80+ contacts in Signal, but 1 (one) in Matrix. Federation just doesn't work for the average person in practice. Email being the large exception because it's been around for so long.

why does federation not work for the average person? how would they know the difference?

what does cause friction is if clients expect the users to enter their own server details beyond their email address.

i find that very annoying in irc clients for example, where i have to know the details for the network to connect to. jabber/xmpp clients generally did a bit better. and i don't know how well matrix is doing it. but making this easy for the user is a matter of interface design.

there is nothing inherent in federation that makes this hard for users. the only thing is having to choose a server. but for my family for example i would choose the same server as myself, and i'd want to send them a link to sign up. that link could then provide a way to open the messaging client with proper settings in place.

if it is more complicated now, then that's a problem, but one that can be fixed

Aside from network effects, UI/UX is really king when it comes to getting people to switch messengers. It's why Telegram has managed to stake as large of a following as it has, despite its glaring flaws when compared to Signal, Matrix, etc.

I understand wanting to focus on security and privacy at the cost of all else, but if the goal is to get as many people on a reasonably safe messenger app as possible, UI/UX is unavoidably going to be a focal point — it can't just be made an afterthought, or as is the case with many FOSS projects disregarded almost entirely.

I would argue that Element on android is really good in terms of UI/UX. But I think the desktop experience is definitely behind others, and I have no idea how the iOS client is like.

I haven't used Element on iOS extensively, but in my limited experience it's "ok" but not stellar. It has a number of papercuts like the registration and login screens not hooking the password manager API and thus not offering password generation services, ability to save/restore from password manager, etc. On that front I think the iOS version of Signal is probably better.

It is good, but not good enough for the mainstream user. With Signal, you can just install it and all your contacts who also have signal are instantly there. The UX is similar to WhatsApp.

With Element, you first need to create a username that in the format <username>:<server>. This is a new notion and non-tech users don't know what this is about. I usually need to explain "it's like email, but instead of the @ there's the :".

Furthermore, there is this new concept of "Rooms" that people are not used to.

Also, there are some UX flaws like that you need to include the @ when adding use (it won't find the user if I try to add "joe:matrix.org", I need to enter @joe:matrix.org). This even threw me off for a minute or so in the beginning.

There are some clients that look and feel more like WhatsApp (like Nio), but they are still in early development. So, I'm hopeful.

See the clients here: https://matrix.org/clients/

Honest question, I'm not a distributed person. Why can't someone turn Signal federated? Wouldn't the centralized server just be a different server? Sure, you'd need to roll a custom app but plenty of people do that. I constantly see people here complaining about it not being federated, but the server is open sourced, so what's the issue?

Side note: isn't it good to be centralized while the app is quickly rolling out new features? Then a switch to federation would be better when all the features are enabled?

> Why can't someone turn Signal federated? Wouldn't the centralized server just be a different server?

The source code is all public and freely licensed, client and server. Anyone could pick it up, turn it federated, and run it. But it’s unlikely Signal would choose to federate with any other servers.

> Side note: isn't it good to be centralized while the app is quickly rolling out new features? Then a switch to federation

It’s pretty clear from Moxie’s words on the topic that he has no desire to federate Signal in the future. He’s solidly convinced that the agility necessary to build a userbase on top of a secure messenger will be lost if he has to spend resources bringing the rest of the ecosystem in line with new developments.

> But it’s unlikely Signal would choose to federate with any other servers.

Could you communicate with both the federated version and the centralized version? If so, I don't see the issue. If not, why?

How would you start a chat with someone on the central server if the central server refuses any communication with the federation you're on?

I guess there's something I'm missing here. I understand it is phone -> Signal server -> other phone. So don't you only need to know how to talk to the Signal server? Which should be in the OS app? So your app would just need to know which server to communicate with the right person. People that are on the Signal server get contacted through the Signal server. People on a federated server get communications passed through there.

I'm sorry if this is a dumb question. I'm really curious but I don't know much about this space. What is Signal doing that restricts you from talking to it?

Not allowing incoming connections from anything besides their signed app.

Signal probably ties message encryption to client authentication. You could give the 'federated' server your plaintext and encryption keys which acts like a client app on your behalf, but that obliterates the purpose of Signal and E2E messaging entirely. And still, they can ban your server IP at any time at their discretion. Maybe you can try to create a federated server that acts as one user but publishes an authenticated encrypted message on behalf of a different user, but there's no api for that... exactly the api that is being asked for in these requests to add a federation api.

Reply on news.ycombinator.com