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

Drawbacks of P2P and a defense of Signal

changelog.complete.org

Post reply on HN
Print view View original

111–120 of 215 posts

Re: Drawbacks of P2P and a defense of Signal

#111

Post by rcxdude »

zaik wrote: post #96
kiwidrew wrote: post #29

Yet another "Matrix isn't mature enough so just give up and use a centralized service" post that completely ignores the fact that XMPP is still alive and kicking. With multiple independent implementations (both client and server) that all work together pretty decently. We're never ever going to tear ourselves away from this death by centralization if we keep inventing excuses for why we don't use the federated/distri…

I never really understood why Matrix invented their own thing instead of building on an already existing IETF Internet Protocol. Surely an "eventually consistent database" can be built on top of XMPP? It's just message passing. When evaluating WhatsApp alternatives, this somewhat made me choose XMPP over Matrix. I recently uninstalled WhatsApp, Telegram and LINE (felt pretty good) and now use Conversations with most…

It's a fundamentally different approach. You could in theory build it on top of XMPP, but it wouldn't actually interoperate sensibly, so what's the point?

Re: Drawbacks of P2P and a defense of Signal

#112

Post by hiq »

Arathorn wrote: post #91

This is all a bit depressing, speaking as the project lead for Matrix. 1. It's true that Synapse can use a lot of RAM. - The biggest cause of this is due to spikes in RAM during state resolution (the merge resolution algorithm used to converge your server's view of a room with the other servers in a room), which Python doesn't always recover nicely. We fixed the main cause of this in Synapse 1.26, which was released…

> For instance, dendrite.matrix.org uses a relatively stable 480MB of RAM, despite being in thousands of rooms spanning tens of thousands of users.

That's impressive, congrats!

I hear your frustration, and I think only time can solve this problem, and it does eventually. It's the same with Signal and the initially poor user experience.

> It makes NO sense to end-to-end encrypt a public chatroom which by definition is intended to be indexed and visible and smeared all over the wider world.

Even if you don't want encryption, authentication is still good to have, so quick question: who authenticates messages when you deactivate E2EE in Matrix? In the case of a public room hosted on server S, A sends a message M1, then sends another M2. Assuming that S is not actively MITM until after the first message (so any initial key exchange can happen), can I be sure that the second message will not be tampered with?

IIUC a Signal group where a client would then broadcast all messages to the world would still provide such a guarantee. Is that the case as well for Matrix?

Re: Drawbacks of P2P and a defense of Signal

#113

Post by heldergg »

IshKebab wrote: post #70
atemerev wrote: post #30

OK. How can you guarantee that your favorite three-letter agency does not have an agreement with Signal, so they can MITM you transparently, or deliver a custom-built app to you? Trustless is the only way to fly. I don’t need to trust any central authority to pay someone with Bitcoin or other cryptocurrencies. Why should I trust someone to route my messages?

It is actually possible because Signal is 1. Open source. 2. Has verifiable builds (just being open source isn't enough). 3. Uses end to end encryption. You need all three of those to get what you want. Also you need to spend a ton of time building Signal from source and auditing it, which I doubt you're going to bother with but at least in theory it is possible.

What's running server side?

Re: Drawbacks of P2P and a defense of Signal

#114

Post by johnchristopher »

upofadown wrote: post #108

This is mostly about anonymity. Signal is not really intended to provide anonymity. Most encrypted messaging is not intended to provide anonymity. That is because anonymity is harder to do than privacy and privacy is hard. Fortunately, most people do not need anonymity in their day to day lives. They just need to live in a country with good privacy laws to prevent the commercial exploitation of their data. So if you…

On the topic of anonymity I do like this stance:

> Just for the hell of it: Anonymity is fundamentally about removing context. You can't provide anonymity you can only provide protocols that endeavour to remove context. Attacks on anonymity system always come down to injecting or deriving context.

> In an adversarial environment (just so we are all on the same page, life is an adversarial environment), there are few limitations on the kinds of context attackers are allowed to inject or derive context from.

> No anonymity system is absolute because there is always context. The majority of my research in this space centers around the context that people add on top of robust protocols that ultimately undermine them. I'm interested in practical failures, not theoretical restrictions.

> Privacy will always been an active choice, not a passive tool. That doesn't make it impossible or out of reach or "dead", it makes it a fight worth fighting.

https://twitter.com/SarahJamieLewis/status/12737436308013711...

https://twitter.com/SarahJamieLewis Sarah Jamie Lewis @SarahJamieLewis Executive Director @OpenPriv

Anonymity hasn't the same requirements as secrecy does.

Re: Drawbacks of P2P and a defense of Signal

#115

Post by nednar »

kiwidrew wrote: post #29

Yet another "Matrix isn't mature enough so just give up and use a centralized service" post that completely ignores the fact that XMPP is still alive and kicking. With multiple independent implementations (both client and server) that all work together pretty decently. We're never ever going to tear ourselves away from this death by centralization if we keep inventing excuses for why we don't use the federated/distri…

Email is another decentralized, distributed system that is often ignored. The only real difference between chat and email is that the interface makes it seem like chat is quicker. Nothing stops us from writing such interfaces for email as well, though.

Re: Drawbacks of P2P and a defense of Signal

#116

Post by tylermenezes »

Dumbdo wrote: post #106
Jkvngt wrote: post #74

Signal needs your phone number and is run by a "former" Twitter person. It just smells funny.

On the other hand Signal is encouraged by people like Edward Snowden (who I assume is paranoid enough about American big corps). The clients are open source and feature a strong E2EE, which is called the Signal protocol and is used by many other clients nowadays because it has such a good reputation. There are lot of efforts to reduce metadata further. Just dismissing it as "smells funny" is not a valid criticism.

> The clients are open source

But you can't verify that the open-source matches what's on the Play Store, you can't link to the official server with your own build, and you can't run your own because the server is no longer open source. (Last released a year ago)

Re: Drawbacks of P2P and a defense of Signal

#117

Post by lapinot »

zaik wrote: post #96
kiwidrew wrote: post #29

Yet another "Matrix isn't mature enough so just give up and use a centralized service" post that completely ignores the fact that XMPP is still alive and kicking. With multiple independent implementations (both client and server) that all work together pretty decently. We're never ever going to tear ourselves away from this death by centralization if we keep inventing excuses for why we don't use the federated/distri…

I never really understood why Matrix invented their own thing instead of building on an already existing IETF Internet Protocol. Surely an "eventually consistent database" can be built on top of XMPP? It's just message passing. When evaluating WhatsApp alternatives, this somewhat made me choose XMPP over Matrix. I recently uninstalled WhatsApp, Telegram and LINE (felt pretty good) and now use Conversations with most…

> I never really understood why Matrix invented their own thing instead of building on an already existing IETF Internet Protocol.

Indeed. For sure XMPP has ugly corners (disclaimer I never implemented anything, mostly read some XEPs). I believe parts which are quite clean are the pub/sub part and the message archive (MAM). Afaik the current group chat extension (MUC) isn't so great (once you try to add history multi-device) and some people are trying to refactor it on top of pubsub (MIX) but it's not very active.

The matrix team clearly had precise ideas about the right way to do federated group chat and in fact (again afaik, my matrix knowledge is dated) their "rooms" seem to be quite flexible by not being completely tied to a particular server (several servers participate in hosting a room). Imho matrix has an edge in designing this from scratch and already knowing what the hard parts are from the beginning and i hope the good ideas will come over to XMPP. Perhaps some day an XMPP server will support matrix, making more clients available to the network (well integrated clients on every plateform is the real hard part for every distributed network).

Re: Drawbacks of P2P and a defense of Signal

#118

Post by Arathorn »

hiq wrote: post #112
Arathorn wrote: post #91

This is all a bit depressing, speaking as the project lead for Matrix. 1. It's true that Synapse can use a lot of RAM. - The biggest cause of this is due to spikes in RAM during state resolution (the merge resolution algorithm used to converge your server's view of a room with the other servers in a room), which Python doesn't always recover nicely. We fixed the main cause of this in Synapse 1.26, which was released…

> For instance, dendrite.matrix.org uses a relatively stable 480MB of RAM, despite being in thousands of rooms spanning tens of thousands of users. That's impressive, congrats! I hear your frustration, and I think only time can solve this problem, and it does eventually. It's the same with Signal and the initially poor user experience. > It makes NO sense to end-to-end encrypt a public chatroom which by definition is…

So you’re right that (a subset of) E2EE in a public room could be used to provide sender authentication; atm you trust the sending server not to be spoofing it. Full E2EE would be overkill.

Re: Drawbacks of P2P and a defense of Signal

#119

Post by Youden »

Phenix88be wrote: post #51
kiwidrew wrote: post #29

Yet another "Matrix isn't mature enough so just give up and use a centralized service" post that completely ignores the fact that XMPP is still alive and kicking. With multiple independent implementations (both client and server) that all work together pretty decently. We're never ever going to tear ourselves away from this death by centralization if we keep inventing excuses for why we don't use the federated/distri…

XMPP is nice, but I have never see regular folks use it. Only tech peoples. The fact that you can't "install and go" is killing decentralized solution because when you ask regular folks the "server url" (or even to choose on a server list), they give up because it's too complicated already. It's already HARD enough to get them on Signal because they can't just click on the "Connect with Facebook" button. I got my mom…

A few years ago, many regular folks were probably using it without even realizing it: Google Talk and AIM both had XMPP support and thanks to that, communication between the two platforms was possible.

Re: Drawbacks of P2P and a defense of Signal

#120

Post by omnimus »

Teever wrote: post #65
omnimus wrote: post #42

Earlier quoted context omitted.

Do you federate or these are silos for few users?

The three servers are federated with each other and the one of them is federated to the broader matrix.org network. I've found that loading the larger rooms from the matrix.org network can cause a bit of lag for the few dozen or so users on my servers but once the rooms have synced up that issue goes away. I don't administer the servers personally so I don't know exactly what the issue is but I have a feeling it's du…

Is seems that this just helps the argument of how inefficient Synapse is. 12GB ram is quite beefy server. the issue is that when you want to federate your server needs to be able to handle similar loads as the server you are federating with....

So not like email where you can have tiny server and still be part if the network.

Post reply on HN