Live data from Hacker News

We can do better than Signal

icyphox.sh

161–170 of 290 posts

Re: We can do better than Signal

#161

Earlier quoted context omitted.

> synapse is actually quite tiny Hmm, is it really? My server has a SSD so I don't care about writes, I just want it to be low on CPU and memory requirements.

an entire synapse with its python environment is about 150MB of disk space occupied, before any user data starts getting written to the database. chat for a group of about twenty people runs fine on a VM with 512MB of RAM. After boot about 300MB of the system RAM is occupied by the base minimal debian OS and other daemons (snmpd, etc), leaving plenty for python3. this same machine also has a minimal nginx setup as th…

It's worth noting that this sounds to be an unfederated server.

The reason Synapse has a reputation for being resource hungry is on publicly federated servers: if one of the users starts going and joining a bunch of large busy public rooms from their new server, then those rooms get dutifully replicated onto the server, which inevitably consumes resources.

The more users and the more servers in the room, the more changes of gnarly forks and merge resolution problems, and the more the risk of CPU spikes. We're constantly working on the memory footprint and state resolution algorithm (e.g. https://github.com/matrix-org/synapse/blob/develop/docs/auth... landed a few days ago), so the situation is improving, but this is the root cause.

Re: We can do better than Signal

#162
post #97

Earlier quoted context omitted.

My experience with Matrix/Element and the various standard-compliant Matrix chat clients, in an ISP environment, is that it's totally possible to set up a rock solid replacement for Slack within an organization that has a person on staff to spend some cycles setting it up, and periodically maintaining it. We don't have any major technical challenges or problems running our own Synapse daemon server. It's a debian sta…

An "internally-run-Slack" is definitely a great use case for Matrix in its current form. I don't own a business, but if I did, I would almost certainly consider running my own Synapse server, just to have a stronger guarantee that internal chats stay internal.

Yes at my bigco they've set up a whole matrix (rebranded) service. Great. Only thing I miss is some kind of 'ephemeral chatroom' option, where nothing is saved or expires after some time. Some conversations are not worth saving and wading through all the chat logs to find some stuff can be painful.

Also I like the other tools' (cisco jabber and some others) option to save chat logs in exchange folders, so you have local search indexation/capabilities.

On the other side, I'd also like a button to record a whole conf-call, so minutes of meetings can be backed up with the actual conversation. Yes, how 'trusting' of me...

Re: We can do better than Signal

#163
post #57

Earlier quoted context omitted.

I had a similar experience with Matrix/Element. I was using the desktop app to chat with a friend, and while we were able to get some end-to-end encryption working, it was a huge pain the butt, and if two software engineers struggled this much to get the damn thing working, there's no way in hell that I'm convincing my parents to use it. To me, we have to accept the incremental wins where we can get them; getting my…

Speaking as project lead for Matrix (and Element), I'm trying to understand the mixed feedback we've had this week, and somehow channel all the negativity into improving things. While some folks are clearly using it successfully and seem to like it, another bunch of people say "it was a huge pain in the butt to get E2EE working, and if it two software engineers struggled this much..." etc. When did this E2EE failure…

I can share the bugs that happened to me. All of these happened in the last 6 months:

- A message would get "pinned" to the bottom in Element. Basically, you could send new messages but a specific message would always look like it was the most recent message (even though it was not). This was a purely visual bug and the other party wouldn't have the issue.

- Messages send/receive slowly compared to other services. It could also just be the matrix.org homeserver, I'm not sure. You gotta be aware you are competing against the likes of Discord however, who deliver messages nearly instantly.

- Decryption would randomly break for one party and they would be unable to decrypt new messages until they restarted the client. I couldn't identify the trigger for this as it seemed to occur randomly.

Re: We can do better than Signal

#164
post #57

Earlier quoted context omitted.

I had a similar experience with Matrix/Element. I was using the desktop app to chat with a friend, and while we were able to get some end-to-end encryption working, it was a huge pain the butt, and if two software engineers struggled this much to get the damn thing working, there's no way in hell that I'm convincing my parents to use it. To me, we have to accept the incremental wins where we can get them; getting my…

Speaking as project lead for Matrix (and Element), I'm trying to understand the mixed feedback we've had this week, and somehow channel all the negativity into improving things. While some folks are clearly using it successfully and seem to like it, another bunch of people say "it was a huge pain in the butt to get E2EE working, and if it two software engineers struggled this much..." etc. When did this E2EE failure…

For me, this was a month or two ago. I don't remember exactly now, but my friend and I tried to verify each other, but one of us quit the device verification (with the five emojis) half-way through and uninstalled the app, so now there is a half-verified device that we can never remove. My icon with him always shows up red because of this device, and there's nothing we can do.

UPDATE: I just checked now, there's a "manually verify by text" option, I clicked "verify" and that device finally turned green, so at least now there's a way to fix this.

One major source of confusion for me is that one-on-one chats and multi-user rooms are different, but one-on-one chats seem to be multi-user rooms with just two people in them? That is confusing to me, because I see "people" and I see "rooms" but apparently people are rooms too.

All that having been said, I am very pleasantly surprised by the overall experience, and especially the pace at which it seems to improve. I use Element semi-regularly with a friend and it's been working okay. Hopefully all these kinks will be ironed out, because I really really want a better IRC, and Gitter has become infinitely better now that I can just use Element to access it.

> At the moment the vast majority of negative feedback on HN has been "it sucked" without giving a hint of what actually went wrong.

Also, I don't think that's what the majority of users are saying (and I certainly never said and don't think Matrix sucks). I'm saying "this is not good enough yet that my parents could use it", which is an extremely high bar, and I think that's the way you should take the feedback.

Re: We can do better than Signal

#165

My main complaint about Signal is its reliance on SS7/PSTN and ordinary phone numbers to identify a user. In an era of SS7 hijacks and social-engineering of mobile phone network customer service reps into SIM-hijacking a target's phone service, by no means should we ever rely upon a phone number as a guaranteed method of identifying an end point device's identity. These are basically the same reasons why other servic…

There's a "registration lock" feature for exactly this problem. Turn it on and you need your pin to re-register. (It expires after 7 days).

Not perfect by any means, but it seems like a well balanced compromise, given the decision to use phone numbers in the first place.

Re: We can do better than Signal

#167

Earlier quoted context omitted.

an entire synapse with its python environment is about 150MB of disk space occupied, before any user data starts getting written to the database. chat for a group of about twenty people runs fine on a VM with 512MB of RAM. After boot about 300MB of the system RAM is occupied by the base minimal debian OS and other daemons (snmpd, etc), leaving plenty for python3. this same machine also has a minimal nginx setup as th…

It's worth noting that this sounds to be an unfederated server. The reason Synapse has a reputation for being resource hungry is on publicly federated servers: if one of the users starts going and joining a bunch of large busy public rooms from their new server, then those rooms get dutifully replicated onto the server, which inevitably consumes resources. The more users and the more servers in the room, the more cha…

Yes, absolutely, this is for company internal use only. I imagine the resources for a server that talks to the outside world are much greater.

Re: We can do better than Signal

#168
post #137

Earlier quoted context omitted.

Nobody thinks about it but the most professionally used communication medium is the email, and part if not all of its success if not all its success is that is decentralized. A company cannot afford to use a service that can be closed and loose all the communications. Centralized services are single point of failure, and in that regard Signal is no better than WhatsApp, because yes, in theory you can run your own ser…

On the other hand, email is the single largest causes of cyber attacks. The communication is not E2E encrypted (apart from a few GPG/SMIME users), no forward secrecy and barely any signature checks. Even if outlook, thunderbird maybe supports it, goodluck getting all the mobile versions to support it too. The clients used to view emails suffer from the same problem with browsers so are subject to all the HTML/JS/CSS…

A Lets Encrypt for email certs is badly needed.

Re: We can do better than Signal

#169
post #123
post #57

Earlier quoted context omitted.

I had a similar experience with Matrix/Element. I was using the desktop app to chat with a friend, and while we were able to get some end-to-end encryption working, it was a huge pain the butt, and if two software engineers struggled this much to get the damn thing working, there's no way in hell that I'm convincing my parents to use it. To me, we have to accept the incremental wins where we can get them; getting my…

It doesn't seem like these problems are fundamental to Matrix, though. I agree that Element is not that good, but if you were to replace Signal's backend with Matrix, your experience would (could?) be nearly identical as Signal is now and we wouldn't have the issues of a closed ecosystem anymore.

Ehhh, Matrix is more than a transport protocol though, it lives a lot higher up the stack. It would be akin to trying to make Signal into a Slack client. So you’re basically saying “if you paper over all the weirdness of Matrix with a better UI” which is easier said than done.
Post reply on HN