Drawbacks of P2P and a defense of Signal • Hacker News Board

Re: Drawbacks of P2P and a defense of Signal

#61

Post by johnchristopher » Sun, Jan 31, 2021, 9:26 AM UTC

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…

> if we keep inventing excuses

The article brings valid points that are not invented.

Re: Drawbacks of P2P and a defense of Signal

#62

Post by reagent_finder » Sun, Jan 31, 2021, 9:26 AM UTC

Thorentis wrote: post #19

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 any future messages, not history. Not to mention I'd be inclined to believe they'd get the word out.

Signal's research and protocol is already used in, well, basically each and every discussion/video platform. WhatsApp, Telegram, Skype, Facebook Messenger, Google Messages, Duo... so it's hard to see Signal becoming more ubiquitous. Seeing the app more will probably happen naturally when events happen (like the WhatsApp privacy change) to drive people towards more secure platforms, but honestly I don't really see a major shift anytime soon.

Re: Drawbacks of P2P and a defense of Signal

#63

Post by staltz » Sun, Jan 31, 2021, 9:29 AM UTC

> 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, SSB's primary mode of updating content is via servers such as pubs and rooms, the DHT in SSB is optional and not the most common mode of updating content. In SSB you can and should choose the servers which you're connecting to, so in that sense it's closer to the federated model.

It's not entirely fair that the article equates "P2P" to "DHT", there are many ways you can do P2P connections, a DHT is only used for discovery. IP leakage is a problem in all these models (centralized, P2P, federated, etc): some computer somewhere will see your IP address, and you have to trust them not to do bad stuff with it.

For a comprehensive overview of privacy in DHTs and P2P, watch this talk: https://www.youtube.com/watch?v=nCCkwU4JPcY

Re: Drawbacks of P2P and a defense of Signal

#64

Post by jdc » Sun, Jan 31, 2021, 9:33 AM UTC

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…

The only value add of the "Connect with Facebook" button is identity provision.

I mean, surely there's a decent XMPP web client out there you could use with OAuth.

Re: Drawbacks of P2P and a defense of Signal

#65

Post by Teever » Sun, Jan 31, 2021, 9:33 AM UTC

omnimus wrote: post #42

Teever wrote: post #36

Earlier quoted context omitted.

This has not been my experience. I run three servers in separate VMs on a Lenovo T420 laptop. These laptops run for about $200USD on Ebay though you'll need to upgrade the ram and the HDD to an SSD, so the cost is about $300USD.

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 due to the limited ram that is provisioned to the VMs running the instances of synapse as there are many other VMs running on that same laptop.

If the instances of Synapse were the only things running on the laptop and they had 12gb of ram each (1/3 the total 32gb limit of the laptop) I would imagine that this issue would go away.

Re: Drawbacks of P2P and a defense of Signal

#66

Post by apichat » Sun, Jan 31, 2021, 9:34 AM UTC

> "Signal brings encryption and privacy to meet people where they’re at, not the other way around. People don’t have to choose a server, it can automatically recognize contacts that use Signal, it has emojis, attachments, secure voice and video calling, and (aside from the Musk incident), it all just works. It feels like, and is, a polished, modern experience with the bells and whistles people are used to."

Quicksy offer EXACTLY the same functionalities but it's federated and standardized, based on XMPP : you can discuss with people that are not using Quicksy and its services, people outside Quicksy even can link their address to their phone to make it automatically recognize as contacts using quicksy/XMPP : https://quicksy.im/#get-listed

And instead of Matrix, Quicksy IT IS THERE YET :

https://play.google.com/store/apps/details?id=im.quicksy.cli...

Re: Drawbacks of P2P and a defense of Signal

#67

Post by kitkat_new » Sun, Jan 31, 2021, 9:36 AM UTC

natchy wrote: post #31

ece wrote: post #22

Element/Matrix/Gitter is a great IRC-replacement and public chat, Mastodon is great as a decentralized Twitter alternative, IPFS is great for decentralized public file sharing. Default-public services like this probably have an easier time being decentralized. It'd actually be nice to see thoughtful integrations between these three IMO. The greatest advantage Signal has is probably doing same-day updates for all clie…

> Mastodon is great as a decentralized Twitter Federated, not decentralized. Decentralized is peer2peer like torrents. Federated is like email where there are little fiefdoms like Gmail, yahoo, or self-hosted.

that definition seems like a bit of a stretch: decentralized does not mean anything more than not being centralized. Federation implies decentralization.

Re: Drawbacks of P2P and a defense of Signal

#68

Post by dudus » Sun, Jan 31, 2021, 9:37 AM UTC

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…

That's is so not what he says though. He says Matrix is not there yet, nowhere he says to give up.

Re: Drawbacks of P2P and a defense of Signal

#69

Post by FriedrichN » Sun, Jan 31, 2021, 9:40 AM UTC

Teever wrote: post #24

rapsey wrote: post #5

A bit annoying how servers meant to be run by people themselves are written in awfully slow languages. Python for matrix server is a terrible choice. Even worse for home assistant. If it can't fit on raspberry pi it's useless.

I see this bike-shedding comment about the language choice for the reference Matrix server implementation in every single post about Matrix on Hackernews. Every. Single One. Millions of people use Matrix. It has been adopted by the French civil service, several German states, and the German armed forces. In a previous post I saw someone saying that American Airlines was looking at adopting Matrix for their employees.…

Don't you know Python isn't Web Scale™?

Re: Drawbacks of P2P and a defense of Signal

#70

Post by IshKebab » Sun, Jan 31, 2021, 9:42 AM UTC

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.