Live data from Hacker News

Drawbacks of P2P and a defense of Signal

changelog.complete.org

141–150 of 215 posts

Re: Drawbacks of P2P and a defense of Signal

#141
post #25

Earlier quoted context omitted.

> Signal would grow immensely in my eyes if they made the server code open source [SEE EDIT], and allowed an easy way to set the centralised server address in the Signal app. The current server would be the default, and perhaps changing the server would be hidden in Advanced Options for now. I feel like this misses the point of what Signal is. It's not just software, it is the network as well . The client is a client…

>What's preventing someone maintaining a client fork where you can do this? We have the code to run a Signal-compatible networks and software that can support this, so why does nobody? This is actively discouraged: https://github.com/libresignal/libresignal/issues/37#issueco...

If you read the link, what's discouraged is using the non official client to connect to the Signal service, or using the "Signal" name on something that isn't produced / run by OWS.

There's nothing there about preventing anyone from running a signal-compatible service/network and shipping a fork of their own client to connect to it, which is my original point.

Re: Drawbacks of P2P and a defense of Signal

#144

Can anyone chime in on their experiences hosting a synapse server? I have close to a dozen people on mine (although we don't federate much with the network as a whole, I set it up initially for a couple of groupchats/DMs with friends) and I'm not even close to hitting the limits of the $5/mo Digitalocean server I put it on. Does federating with the greater Matrix ecosystem cost that much extra processing power, that…

I've been running one on my server for about 4 years. My server is a computer I got for free (some dell optiplex with an i3 in it), it eats 20W of power. It works more or less well depending on available bandwidth (on ADSL attachments were a pain).

These days it's mostly fine. The database is about 15GB (including media), there are scripts around the net to clean it up (rooms you've left, etc). Joining big, federated rooms is ram-expensive with synapse, though you now can specify a maximum complexity on your server to prevent joining those. Other small federated rooms are completely fine to join, and don't cost much more than a local room (IMO, there's little point in hosting a non-federated matrix server).

I use yunohost to simplify deployment, though it has some limitations. I did give access to a few friends, but I feel like I cannot guarantee uptime even though it has been pretty good so far. Once profiles-as-rooms land, that might change, as a user could just hop on another server if mine is down.

Re: Drawbacks of P2P and a defense of Signal

#145
post #54

Earlier quoted context omitted.

I just set up synapse last week. The config file has 93,000 characters in it, which i joked is worse than IRCd. I'm running it on gentoo, pretty bare system, probably equivalent to double an rpi4. I did notice that the database file grows quickly. Currently the entire machine is using 272MB RAM, 0.8% CPU peaks, 0.01 15 minute load average. Every part of setting up a server that will federate/host repeats again and ag…

Which file are you talking about? The homeserver.yaml? Mine only has around 100 lines without comments.

Probably the homeserver.yaml file, as yaml is a standard format where indentation matters, and is always 4 spaces.

    # cat /etc/matrix-synapse/homeserver.yaml|wc -l
    1611
    # cat /etc/matrix-synapse/homeserver.yaml| grep -v '^\s*#\|^$' | wc -l
    101
The config file is just well-commented.

Re: Drawbacks of P2P and a defense of Signal

#146

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…

I'm the guy that wrote the blog article that got posted here. So, I'm dusting off my really old HN account, to step up and say that I am very sorry it felt depressing to you, because that was not my intent.

In fact, as I said in the post, I use Matrix, I love Matrix, I evangelize Matrix (especially to Discord people), it has made a lot of strides lately. I had a previous post on distributed offline-capable IMs at https://changelog.complete.org/archives/10205-roundup-of-sec... and I got so much feedback to "don't let people use Signal, switch to Matrix!" that I specifically was addressing Matrix as a Signal replacement in the post. (I regret it wasn't super clear that's what I was doing.)

I'm going to address your points in a sort of different order, starting with:

#5, encryption. The benefit to Signal here is that encryption is NOT optional. A user just knows everything is going to be encrypted. 1-to-1 chatting, group chats ("rooms" to Matrix), voice and video calling, attachments, EVERYTHING is E2E encryption and user error can't result in things being sent in plaintext.

Now as you say there are reasons that, say, #fx-desktop-community:mozilla.org with its 1100 users shouldn't be using E2EE. However, when talking about Matrix *as a Signal replacement*, the fact that E2E is only default but not mandatory for 1-to-1 chats, and optional but not default for multi-user chats (in Element), this makes it a lot easier for non-tech-savvy end users to goof and send messages in plaintext. A secure replacement for Signal needs to not have that option. Perhaps a "secure everything" mode in Element would help.

2. Fundamentally, there is a deeper issue here: for every Matrix user, there exists at least one, and possibly more, single points of failure. As far as I know, Synapse itself isn't clusterable, so for every Matrix homeserver, the failure of, say, a single CPU will render everyone on that server unable to communicate. I say "possibly more" because many people probably will run a singleton PostgreSQL instance also, though PostgreSQL can be clustered. Or even an upgrade to Synapse there would take people offline, etc.

For me to be able to recommend an IM to people, it must pass the "I can rely on this thing to get help if my car breaks down at night" test. Right now, Matrix doesn't give me that level of comfort. Yes, it's getting better. Yes, various hosting options exist. But still, if the homeserver you're using has a bad CPU or Synapse OOMs it or whatever, your messages aren't going through in a timely manner.

3. I am glad to hear that voice and video calling are getting so close. However, I want to still add that having two different VOIP systems -- one that can handle precisely 2 participants and another that can handle more -- is jarring for end users and admins alike. People are used to being able to tap "add participant" to their calls and this is a UX issue for people coming from other IM systems.

1. I'm glad to hear these RAM issues are getting better. I've spent a fair bit of time tuning that cache parameter, from its default of 0.5 down to 0.2 (which resulted in drastically unacceptable performance) up to the other recommendation of 2.0 (which still resulted in OOMs). I am in some large Debian, Firefox, and Matrix rooms, with over a thousand participants each -- though some of those, at least, are gated from IRC where such a scale is a non-issue.

I've been following Dendrite's "are we Synapse yet?" page with interest and excitement. I am looking forward to it being ready to use! But as I stated in my post, and as you are surely aware, it's not there yet, at least based on the "are we Synapse yet?" page.

4. It's not actually that simple. A person is most likely going to want at LEAST Synapse and Element Web. Most are probably also going to need coturn, Dimension, Jitsi, synapse-admin, and maybe an identity/directory server. The downloading of the software is the easy bit. The hard bit is getting all the bits talking to each other properly, with various JSON config files, keys, DNS entries, SSL certs, well-known files, ports, etc.

I set up my own Matrix server due to difficulties with the integrations at t2bot, some limitations in the IRC bridge I had to work around, etc.

Also to those wondering why Matrix and not XMPP: I used to run ejabberd and an XMPP service. XMPP has (or at least, HAD) a real issue when being used with multiple clients - delivering messages to the wrong place, not syncing history, etc. Matrix is far better with those things. Also Jingle in XMPP land barely ever worked, last I checked.

An aside: I try not to comment on non-federated corporate-control sites (of which HN is an example), but hopefully if you reply I'll get an email or something. You are also welcome to engage me on my blog or on Mastodon, where I first surfaced many of these ideas (and did tag the Matrix Mastodon account). Or email me.

Once again, thanks for what you do. Matrix is great for many use cases and will be great for more in the future. But I want to be clear-eyed about how it compares to Signal for the secure IM use case, today.

Re: Drawbacks of P2P and a defense of Signal

#147
post #63

> Similar can be said from everything like Scuttlebutt to GNU Jami; any service that operates on a P2P basis will likely reveal your IP, and tie your identity to it (and your IP address history). In some cases, as with Jami, this would be limited to friends you add; in others, as with Scuttlebutt and IPFS, it could be revealed to anyone. Regarding Scuttlebutt (SSB), this isn't quite true. While IPFS requires a DHT, S…

https://SafeNetwork.tech is thoroughly p2p and doesn't reveal IP addresses because it's designed from the ground up to be decentralised, anonymous and censorship resistant.

Is there a reason this comment has been downvoted?

I know this is usually not a good question to ask, but since this comment looks reasonable to me in context, I am wondering if there is something about safenetwork.tech that makes it a bad example or even a scam?

Re: Drawbacks of P2P and a defense of Signal

#148

Earlier quoted context omitted.

Server is open source too. https://github.com/signalapp/Signal-Server

Only one branch: master Last updated: 9 months ago Unless I am missing something obvious in GitHub UI.

They don't actually develop on github, but code goes there every now and then. Not ideal, but better than nothing imo

Re: Drawbacks of P2P and a defense of Signal

#149

All apps that require a phone number are a scam, privacy-wise. Use Matrix.

> All apps that require a phone number are a scam, privacy-wise. Use Matrix. …and leak my message content, IP address and social network to everyone who cares to look? You're making a very broad claim here and implicitly assume a very specific threat model. I can come up with dozens of other threat models that are more relevant to me and everyone I know and that completely invalidate your statement.

> …and leak my message content, IP address and social network to everyone who cares to look

Would you care detailing this?

- Private conversations are E2EE by default now, group chats can be E2EE.

- IP addresses are not leaked except when videoconferencing. This is also the case on Signal, mind you, unless you opt-in to use their proxy in the settings.

- Social networks? Care to explain that?

- Who is everyone? Your server admin? Your ISP? Someone MITMing your HTTPS connections?

I do not doubt the rest of your post, but the above criticism is just unfair, given what I know of the Matrix protocol. Of course, I could be mistaken.

Re: Drawbacks of P2P and a defense of Signal

#150

I think a half-way point is needed for something to be truely durable. I agree with the criticisms of P2P in that you need to make some privacy tradeoffs. But durability is another concern (as we've seen recently with the takedown of Element from the Play Store). Is it possible for somebody else to spin-up a new centralised Signal server? Why isn't the server code-base open source? Signal would grow immensely in my e…

I feel that's pretty disingenuous. Like you noticed the server-side code is active, and changing server address would be a niche-of-a-niche activity. Also, what would be the point of going after Signal's servers? Even if a/the government got a hold of all the data in there, it's encrypted with client keys. I mean sure, if they took over secretly and became a malicious MITM that's different, but it's still only for an…

Telegram does not use Signal's protocol, Telegram's protocol is designed from scratch.

https://www.cryptofails.com/post/70546720222/telegrams-crypt...

Post reply on HN