Live data from Hacker News

Drawbacks of P2P and a defense of Signal

changelog.complete.org

41–50 of 215 posts

Re: Drawbacks of P2P and a defense of Signal

#41
post #35

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…

How much of the daily volume of internet chat-type messages do you estimate flow over XMPP versus alternative protocols and proprietary implementations?

Not nearly enough.

Based on some yearly port-scanning surveys [1], the developers of the Prosody XMPP server think there are over 50,000 servers running Prosody (out of a total of over 85,000 XMPP servers). There are a handful of large public servers and then what I imagine would be a very long tail of tiny private servers.

[1] https://blog.prosody.im/2020-retrospective/

Re: Drawbacks of P2P and a defense of Signal

#42
post #36

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.

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?

Re: Drawbacks of P2P and a defense of Signal

#43

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…

As someone who in principle would like decentralized/federated cryptomessengers to win what usually blocks me from using them (over Signal) is that most of the people I would contact via messenger are not tech-savy. To make them switch the messenger has to be easy to setup and feature wise it has to be so promising that they don't feel like I lured them into something half baked.

While being federated is a huge plus for me, it still needs to be a good and usable messenger on all other fronts. If I can't imagine my mother using it, you are doing something wrong.

I am not usually of the "software must be usable by a baby"-front, but for a messenger adoption is key, and unless I only talk to my nerd friends it needs to be both simple and at least up to task with Signal (videocalls, groups, easy to find contacts, ...)

Re: Drawbacks of P2P and a defense of Signal

#44
post #39

Earlier quoted context omitted.

I think it would be better if you made your point rather than asked it rhetorically. To me your argument reads like 'internet chat is currently proprietary so it always will be' but maybe I'm missing a step you'll need to fill in.

And I think part of internet discourse should allow to posit questions without actually having a big point to make. Why is it necessary to pontificate about everything? In any case, if you want a point, whenever technical people bring up the technical superiority of X protocol or tool in a discussion, I like to ask myself this question. How many people actually use the thing that someone is telling me is so much bett…

> In any case, if you want a point, whenever technical people bring up the technical superiority of X protocol or tool in a discussion

They are not talking about "technical superiority" though, but about "alive and kicking" and "work together pretty decently" and you followed up with a question of daily volume as somehow being the indicator of the maturity of the technology itself.

There are multiple reasons for a lack in adoption, of course. Network effects, FOMO and walled gardens, financial might and power of dominating competitors to name a couple besides just the quality of the tech itself. And it doesn't help when many people off-handedly state the technology is not good, because it is not yet as broadly adopted as the centralized giants it is trying to be an alternative too :)

Re: Drawbacks of P2P and a defense of Signal

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

Python shouldn't be blamed here, because the real reason that the Matrix homeserver is so slow is due to fundamental protocol design issues. It doesn't matter what language you write it in, it's going to be a resource hog by design.

Re: Drawbacks of P2P and a defense of Signal

#46

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 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 again that you need a TURN server (and they recommend coturn) - which is another 26,000 character config file - in order to do VOIP. If you've ever run or used a pbx before, STUN is needed 100% of the time for nat traversal between clients. Coturn even says it won't run if it's NAT'd (it will, but that's irrelevant to most people.)

This is the fourth concurrent tech trial of chat daemons, with rocket.chat and mattermost being a couple of the other ones that we're testing. synapse/element/matrix has the benefit of forced e2ee by my configuration. I don't know of any other matrix federated servers, so i haven't tried that yet, but an associate says it works on my configuration - which means it's not as big of a pig as i thought it was based on the outlandishly, comically large config file - where whitespace matters!

Re: Drawbacks of P2P and a defense of Signal

#47
post #35

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…

How much of the daily volume of internet chat-type messages do you estimate flow over XMPP versus alternative protocols and proprietary implementations?

In my experience, IRC is more active than XMPP. I only get XMPP traffic from spammers and during open source conferences, whilst IRC is active daily.

Re: Drawbacks of P2P and a defense of Signal

#48
post #39

Earlier quoted context omitted.

I think it would be better if you made your point rather than asked it rhetorically. To me your argument reads like 'internet chat is currently proprietary so it always will be' but maybe I'm missing a step you'll need to fill in.

And I think part of internet discourse should allow to posit questions without actually having a big point to make. Why is it necessary to pontificate about everything? In any case, if you want a point, whenever technical people bring up the technical superiority of X protocol or tool in a discussion, I like to ask myself this question. How many people actually use the thing that someone is telling me is so much bett…

Its not really a question though when everyone already knows the answer.

The 'why' you have here is a more open question and there's a lot in there. Companies trying to make money from it, users not having seen many real privacy implications on a wide scale, police presence being up and down etc. etc.

Re: Drawbacks of P2P and a defense of Signal

#49
post #43

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…

As someone who in principle would like decentralized/federated cryptomessengers to win what usually blocks me from using them (over Signal) is that most of the people I would contact via messenger are not tech-savy. To make them switch the messenger has to be easy to setup and feature wise it has to be so promising that they don't feel like I lured them into something half baked. While being federated is a huge plus…

Exactly. When network effect is in play, the bar for adoption must be set incredibly low. There is no way any of my non-tech friends is going to spend even 5 minutes investigating “XMPP” or whatever.

If it’s anything more than open app >> fill in phone number or create account >> see list of people to chat with, it’s already dead in the water.

Re: Drawbacks of P2P and a defense of Signal

#50
post #43

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…

As someone who in principle would like decentralized/federated cryptomessengers to win what usually blocks me from using them (over Signal) is that most of the people I would contact via messenger are not tech-savy. To make them switch the messenger has to be easy to setup and feature wise it has to be so promising that they don't feel like I lured them into something half baked. While being federated is a huge plus…

People who make these sort of comments strike me as the same sort of people who box tick features in software development without ever giving consideration to UX. There’s always an open or decentralized alternative to whatever big bad closed/proprietary thing is being complained about. You can usually contrive together an argument for how it almost has feature parity. But only if stick your fingers in your ears and wilfully ignore the fact that the user experience is almost never up to scratch.
Post reply on HN