Live data from Hacker News

Drawbacks of P2P and a defense of Signal

changelog.complete.org

21–30 of 215 posts

Re: Drawbacks of P2P and a defense of Signal

#21
post #10

Earlier quoted context omitted.

This response has been written a thousand times, but here goes again... Using a VPN or Tor is not a viable option for the average person.

Why? You download a single program, run it, it unlocks forbidden content. There is nothing in this flow that people way below average already can't do.

[deleted]

Re: Drawbacks of P2P and a defense of Signal

#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 clients while being dead simple to use well. A decentralized protocol could achieve these things, but none have yet. Still I hope someday soon we can have everything be decentralized, but like the blog post says, we can't let the perfect be the enemy of the good.

Re: Drawbacks of P2P and a defense of Signal

#23

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…

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.

Re: Drawbacks of P2P and a defense of Signal

#24
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.

I assure you that whether or not the reference Matrix server runs well on a raspberry pi did not factor into the decision making process that these organizations used when they picked Matrix.

Re: Drawbacks of P2P and a defense of Signal

#25

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…

> 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 that lets you communicate on the Signal network, which is operated centrally. A client that lets you choose a server endpoint is no longer a "Signal client", it's a Signal-compatible network client.

People seem to have an expectation that Signal server API is public, and that it should allow any compatible client to connect, or that a given client to connect to any compatible endpoint (in the spirit of public client/server internetty stuff). From what I can see, part of the whole point of the centralisation is to take that client/server API private so that the 'official' signal server only ever has to support a single client that they also control (hence allowing rapid iteration, avoiding legacy support etc).

> Unfortunately, you cannot change the server address in the app as downloaded from any app store, so my criticism remains.

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?

Re: Drawbacks of P2P and a defense of Signal

#26
post #2

Most of these criticisms are solvable problems. If you make a direct connection to other users, they see your IP address. So use Tor or a VPN. Many P2P lookup systems assign identifiers for routing etc. So assign ephemeral ones for anything that doesn't need a persistent one, and make sure persistent ones aren't suitable for correlation, either by not using the same identifier for multiple services by the same person…

The article never claimed they are impossible to solve.

It even mentions Tor.

You seem to trying to argue something different than what the article is actually about.

Re: Drawbacks of P2P and a defense of Signal

#27

Why compare the privacy implications of IPFS and Signal? They are intended for entirely different purposes.

The Article compares p2p vs centralized and uses IPFS as an example and signal as the other example. Both distribute information. True this is a high level perspective...

Re: Drawbacks of P2P and a defense of Signal

#28
Agree. Googles in bed with the Government and they make sure to make near impossible to have any normal search experience while using Tor.

Wasn’t it Google that wanted to make all information available on the web through their site? This is almost as bad as censorship.

Re: Drawbacks of P2P and a defense of Signal

#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/distributed systems that we already have!

Edit: for those who are interested in using XMPP in 2021, there is a good list of public servers available at https://list.jabber.at/ and a list of clients that support modern OMEMO end-to-end encryption at https://omemo.top/

Re: Drawbacks of P2P and a defense of Signal

#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?
Post reply on HN