Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I won't recommend Signal anymore

sandervenema.ch

Post reply on HN
Print view View original

121–130 of 350 posts

Re: Why I won't recommend Signal anymore

#121

Post by Arathorn »

SamWhited wrote: post #119
heavenlyhash wrote: post #90

Earlier quoted context omitted.

Not even remotely. It's quite good at realtime, and especially reliable realtime. Compared with protocols like XMPP, Matrix scores way higher on reliability because it has message IDs and message ordering baked into the protocol, so it can actually converge on a correct state after network flakes. (I consider this a pretty big deal because silent message drops were a pretty regular issue for me in XMPP, and we all kn…

It has to make an HTTP request every single time it wants to check if there are new messages… I wouldn't call that a good realtime protocol (though in fairness, I'm sure it's good for many other things).

Matrix isn't tied to HTTP - it's just the baseline protocol. The idea is for people to propose whatever custom efficient transports they like, maintaining HTTP as the lowest common denominator. For instance https://github.com/matrix-org/matrix-websockets-proxy is such a WebSocket proposal.

Re: Why I won't recommend Signal anymore

#122

Post by lima »

clumsysmurf wrote: post #8

Unfortunately, Google has made it (almost) impossible to wake up the phone via some external event without using its proprietary GCM. Even though GCM is not part of AOSP, it has unique status on the platform that can't easily be replicated (without recompiling the kernel, etc like the article mentions). Before the days of doze mode & other battery optimizations, you could just listen & block on a socket, then let the…

It works quite well for me with the Conversations Jabber client with no discernible battery usage impact.

Did something change in recent Android versions?

Edit: Apparently Nougat's Doze is the issue. Conversations bug report, you can apparently put it on a whitelist:

https://github.com/siacs/Conversations/issues/1624

Re: Why I won't recommend Signal anymore

#123

Post by Arathorn »

qwertyuiop924 wrote: post #9

There are several projects moving toward this. Matrix is probably the most well-known project, but its crypto isn't actually operational yet, AFAIK. Tox works now, but for all their talk of trying to be user-friendly, asking users to exchange long alphanumeric sequences inherently isn't. Psyc, maybe?

E2E Crypto is very nearly operational. It's live (in beta) on the web on https://riot.im/app, and meanwhile the iOS & Android implementation PRs have (almost) landed on the develop branches of matrix-ios-sdk and matrix-android-sdk respectively. Our crypto audit is complete, and we're hoping to unveil it to the world in the next week or two.

Re: Why I won't recommend Signal anymore

#124

Post by Arathorn »

SamWhited wrote: post #21
qwertyuiop924 wrote: post #9

There are several projects moving toward this. Matrix is probably the most well-known project, but its crypto isn't actually operational yet, AFAIK. Tox works now, but for all their talk of trying to be user-friendly, asking users to exchange long alphanumeric sequences inherently isn't. Psyc, maybe?

Matrix's protocol design is terrible for realtime messaging though (I'm sure there are other uses for which it's more adept); it's effectively a giant, inefficient, JSON datastore that syncs data everywhere. It's also pull based so it consumes battery like crazy. If that's what you need, fine, but for realtime messaging I'd argue that it's really unacceptable.

As per elsewhere on this thread, this isn't entirely fair. Matrix uses HTTP+JSON as its lowest common denominator, but the whole idea is for people to use WS+CBOR or capnproto or whatever whenever they need efficiency.

In terms of "syncing data everywhere" being 'terrible for realtime messaging'... i'm not sure that holds water ;)

Re: Why I won't recommend Signal anymore

#125

Post by Arathorn »

qwertyuiop924 wrote: post #75
nickik wrote: post #38

Earlier quoted context omitted.

Matrix actually has e2e crypto working right now. Its in beta but you can active it in the room settings.

Really? Finally. Thank god.

turns out that implementing a new double ratchet implementation from scratch... and then adding in all the additional semantics required for Matrix's history-synced group chats etc... and then getting publicly audited... and getting it running on Web/iOS/Android... not to mention writing a formal spec for everything (both for the crypto, and the Matrix aspects of it), is a significant amount of time & work ;)

Re: Why I won't recommend Signal anymore

#126

Post by qwertyuiop924 »

SamWhited wrote: post #118
heavenlyhash wrote: post #95

Earlier quoted context omitted.

It's true that it's a big hunk of JSON. And I'll readily concede that when efficiency matters, I'm more partial to binary formats like CBOR. But XMPP is XML, which... isn't exactly lighter. There's another HN thread where I've talked more about XMPP vs Matrix here: https://news.ycombinator.com/item?id=9772968 -- long story short, I tried to write an XMPP client, and I got grey hairs, fast. The story for consistent de…

XMPP only has to turn the radio on full power mode when it gets a new message or creates a new connection (the tower sends the LTE radio a paging message telling it to wake up, then the long-lived TCP connection can receive data). Matrix has to turn the radio on every single time it wants to check for data, regardless of whether there is data to receive or not. This is the problem with HTTP based protocols; you might…

As has been noted upthread, Matrix does allow for alternate transports. So this may not be quite as big an issue.

Re: Why I won't recommend Signal anymore

#127

Post by Arathorn »

SamWhited wrote: post #23
gst wrote: post #7

Earlier quoted context omitted.

Why isn't there an alternative? Signal uses the Axolotl protocol for encryption. There are already several XMPP clients that support the OMEMO protocol which is based on Axolotl ( https://conversations.im/omemo/ ). And for Matrix (a modern alternative to XMPP) there's Olm which is also based on Axolotl.

At the risk of derailing this slightly, I wouldn't call Matrix a "modern alternative" to XMPP. The use cases are almost entirely different; Matrix isn't really suitable for realtime applications like XMPP is (because Matrix is all pull-based, so you have to query the server constantly to try and get messages in a reasonable time; this also means keeping the phone radio in active, high-battery-drain mode [pretty sure…

Agreed that Matrix isn't a "modern alternative" to XMPP, but for different reasons. At its core, Matrix is a decentralised object database for conversation history (like NNTP). XMPP is a message passing protocol (like SMTP, but extensible).

Matrix is not "all pull-based" - that's just the baseline implementation. Folks have already implemented push-based transports for Matrix - e.g. COAP or WS.

edit: [Disclaimer: i work on Matrix]

Re: Why I won't recommend Signal anymore

#128

Post by qwertyuiop924 »

Arathorn wrote: post #123
qwertyuiop924 wrote: post #9

There are several projects moving toward this. Matrix is probably the most well-known project, but its crypto isn't actually operational yet, AFAIK. Tox works now, but for all their talk of trying to be user-friendly, asking users to exchange long alphanumeric sequences inherently isn't. Psyc, maybe?

E2E Crypto is very nearly operational. It's live (in beta) on the web on https://riot.im/app , and meanwhile the iOS & Android implementation PRs have (almost) landed on the develop branches of matrix-ios-sdk and matrix-android-sdk respectively. Our crypto audit is complete, and we're hoping to unveil it to the world in the next week or two.

Good to hear it!

Re: Why I won't recommend Signal anymore

#129

Post by SamWhited »

Arathorn wrote: post #121
SamWhited wrote: post #119

Earlier quoted context omitted.

It has to make an HTTP request every single time it wants to check if there are new messages… I wouldn't call that a good realtime protocol (though in fairness, I'm sure it's good for many other things).

Matrix isn't tied to HTTP - it's just the baseline protocol. The idea is for people to propose whatever custom efficient transports they like, maintaining HTTP as the lowest common denominator. For instance https://github.com/matrix-org/matrix-websockets-proxy is such a WebSocket proposal.

Sure, and that's better, I agree, but XMPP also works the same way, but it's base protocol is much lower layer (a TCP connection instead of a higher layer protocol like HTTP). The point is that the default (which is always what most people will stick with), is too cumbersome and inefficient for realtime applications.

Re: Why I won't recommend Signal anymore

#130

Post by qwertyuiop924 »

SamWhited wrote: post #116
qwertyuiop924 wrote: post #73

Earlier quoted context omitted.

Tox is a fully distributed ( not federated) p2p system. It supports 2-way messaging, multi-way chatrooms, voice and video calling (using Opus and VP8, respectively), file sharing, and desktop streaming, although not all features are supported by all clients. Although any client can implement any feature they like, so long as they can do it atop the actual network system, sticking to the Tox Client Standard is reccome…

> Tox is a fully distributed (not federated) p2p system Ah, see, you lost me there already. I'm sure it's clever and well made and all the rest of it, but fully distributed systems either almost never work, are very difficult to get setup and use properly, or end up just not being fully distributed systems (eg. early Skype and it's "supernodes" or whatever it called them, aka "servers", or Tor [which I love] and it's…

Tox has DHT bootstrap nodes, but they aren't hardcoded.
Post reply on HN