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

Re: Drawbacks of P2P and a defense of Signal

#151

Post by zepto » Sun, Jan 31, 2021, 3:06 PM UTC

Jiejeing wrote: post #110

growse wrote: 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...

It’t not discouraged.

In fact I’d say it’s actively encouraged to fork both the client and the server. What is not encouraged is just forking the client and using Signal’s servers.

“I'm not OK with LibreSignal using our servers, and I'm not OK with LibreSignal using the name "Signal." You're free to use our source code for whatever you would like under the terms of the license, but you're not entitled to use our name or the service that we run.“

Re: Drawbacks of P2P and a defense of Signal

#152

Post by zepto » Sun, Jan 31, 2021, 3:15 PM UTC

feanaro wrote: post #81

canofbars wrote: post #32

Earlier quoted context omitted.

Its a valid comment. I tried to run synapse on a reasonable VM and it was unusably slow. Essentially you either use the main server or you are a large org that can pay for a powerful machine to run it. The average person can not run a matrix server.

> The average person can not run a matrix server. Please don't repeat falsehoods like this. The average person can not run anything because software is black magic to them. If you meant the average knowledgeable computer engineer (or similar, as opposed to a large org), then you are simply wrong. I'm running a Synapse instance for ~25 people (friends and family). We are federated and joined to many large rooms. Synap…

“Please don't repeat falsehoods like this.”

You accuse the parent commenter of making a falsehood, but then you go on to confirm their statement as true.

Re: Drawbacks of P2P and a defense of Signal

#153

Post by inshadows » Sun, Jan 31, 2021, 3:17 PM UTC

Let me just quote n-gate:

Signal is having technical difficulties January 15, 2021 (comments) Signal (business model: "Uber for texting") falls over. Most communications protocols are federated, and would survive one company's servers eating dirt, but Signal's owner/operator has decided this would degrade the user experience, presumably worse than the entire service shitting the bed out loud. Hackernews assumes that Signal is incapable of paying its hosting fees, and comes to the rescue by sending their money to a company that can't spin up cloud nodes fast enough to serve text messages. Other Hackernews bemoan the fact that once again they look like idiots, since they just conned half their friends and family into signing up for this mess.

Re: Drawbacks of P2P and a defense of Signal

#154

Post by Unklejoe » Sun, Jan 31, 2021, 3:19 PM UTC

gorgonzolachz wrote: post #9

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 hosting my own homeserver for a few years on my own personal computer with a residential internet connection. It’s technically a violation of Verizon’s TOS but they don’t seem to care, probably since the traffic isn’t crazy.

I have about 20 users, with 5 of us being really active (but not much federation).

The computer is an Intel Kaby Lake i7 - really nothing special. I’ve never noticed crazy CPU usage.

Re: Drawbacks of P2P and a defense of Signal

#155

Post by zrm » Sun, Jan 31, 2021, 3:45 PM UTC

Daho0n wrote: post #72

catmanjan wrote: post #34

Earlier quoted context omitted.

Yep all it took was some usability products and it was easier... See what I'm saying...

I don't think it is comparable. In my opinion it would be comparable to if e-mail required you to be on the same server as your friends or you couldn't e-mail them OR to have compatible servers that could communicate across different protocols, which is a run to the bottom just as in e-mail where adding new security and removing legacy is near impossible.

> to have compatible servers that could communicate across different protocols, which is a run to the bottom just as in e-mail where adding new security and removing legacy is near impossible.

TLS was not in the original email RFC. Such a high percentage of email servers use it now that some have started refusing to communicate with ones that don't. And long before 100.0% of email servers support TLS, you can still use it whenever it's supported by the servers of the sender and recipient.

The DNS RFCs contain a specification for zone transfers, i.e. requesting all the DNS records in the zone instead of any given one. Some people don't like the idea of anybody being able to download their entire zone, and it was always a silly way to sync zones between DNS servers as opposed to using e.g. rsync, so most DNS servers on the internet refuse to do it and a lot of DNS server software doesn't even implement it. But the people still using it internally for whatever silly reason can carry on doing so indefinitely without hurting anybody else.

Nobody cares about the legacy cruft that nobody they care about uses. What having central control gets you is the ability to decree from the tower that something some people are still using shall be removed for everyone everywhere. That can be more of a bug than a feature.

The biggest actual problem with protocol ossification is stupid network middleboxes that manipulate or drop traffic and then break on protocol changes they don't understand. The way to fix this is for future protocols to be encrypted so the middleboxes can't mess with it.

Re: Drawbacks of P2P and a defense of Signal

#156

Post by billyjobob » Sun, Jan 31, 2021, 3:46 PM UTC

zepto wrote: post #147

happybeing wrote: post #98

Earlier quoted context omitted.

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?

Last time it was featured on HN the top comment accused it of being another crypto currency scam. Unfortunately there didn’t seem to be any consensus one way or the other on the technical merit, but clearly some people are not fond of it.

Re: Drawbacks of P2P and a defense of Signal

#157

Post by neiman » Sun, Jan 31, 2021, 3:54 PM UTC

awestroke wrote: post #127

neiman wrote: post #86

Earlier quoted context omitted.

Are all non-profit organizations good? What stops Signal from becoming for-profit in the future?

> "[...] we've structured the project as a non-profit entity, so it can never be bought, has no investors, and isn't "owned" by anyone. We did this because we wanted to be "for" something other than profit, and we wanted to make sure the organization was only incentivized to create something that is in the best interest of the people who depend on it." https://www.reddit.com/r/technology/comments/kt91qk/comment/...

Yes, but I have structured my message so it can never be criticized :-)

Their intention is good, but I fail to see how it ensures that Signal, the project or the management of the app, would never fall into bad hands. Promising such a thing is somewhere between naive and misleading.

Re: Drawbacks of P2P and a defense of Signal

#158

Post by neiman » Sun, Jan 31, 2021, 3:57 PM UTC

erhaxf wrote: post #122

neiman wrote: post #55

A benevolent dictatorship would always be more effective than a democracy, but what happens once it stops being benevolent? Same here. A centralized app (like Signal) is more effective than distributed/decentralized approach. But what would happen if Signal would ever stop being benevolent? Remember the days Google were "do no evil"?

Do you mean more effective for encrypted protocols? Because for unencrypted messages NNTP is very effective. Google killed it with groups 2.0 (1.0 was quite well done).

I meant apps, not protocols, but thanks for the tip. I never looked into the details of NNTP.

Re: Drawbacks of P2P and a defense of Signal

#159

Post by Macha » Sun, Jan 31, 2021, 4:09 PM 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…

Matrix today is more accessible than XMPP today. Matrix today has more communities than XMPP today. It's a pity that XMPP's hopes were dashed by the EEE of Google and Facebook, but I think if we want to make people move towards a decentralised protocol, we need to pick one, and I don't see a reason to spend my energy on reversing the direction of XMPP when Matrix is heading in the right direction.

Re: Drawbacks of P2P and a defense of Signal

#160

Post by px43 » Sun, Jan 31, 2021, 4:12 PM 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…

Can XMPP do encrypted group chat yet?

I ran a medium-small sized XMPP community for many years, and eventually the community abandoned it and went back to IRC because it had better client/bot support. Matrix has a really good solution for end to end encrypted group chat, so I haven't seriously looked back at XMPP since then. They were the first ones with a decent solution to the most important feature I needed in decentralized group messaging, so they won IMO.

I tried a couple times to build out my own clients/bots etc for XMPP, and it just seemed way overly complex. I had to bundle something like 30 megs of jar files for a simple hello world app.

Also some silly things like ejabberd refusing to hash passwords in their user database because they were "already encrypted with SSL". It was all just a frustrating mess, and a security nightmare.

Matrix, with Element, has a pretty web frontend that does encrypted messaging right. If XMPP has anything like that, please do let me know, but every time I've glanced back at it, it seems stuck in the stoneage of messaging apps, still working on getting a committee together to form the standards for even the most basic functionality that everything else had 10 years earlier.