Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Drawbacks of P2P and a defense of Signal

changelog.complete.org

Post reply on HN
Print view View original

121–130 of 215 posts

Re: Drawbacks of P2P and a defense of Signal

#121

Post by lapinot »

rcxdude wrote: post #111
zaik wrote: post #96

Earlier quoted context omitted.

I never really understood why Matrix invented their own thing instead of building on an already existing IETF Internet Protocol. Surely an "eventually consistent database" can be built on top of XMPP? It's just message passing. When evaluating WhatsApp alternatives, this somewhat made me choose XMPP over Matrix. I recently uninstalled WhatsApp, Telegram and LINE (felt pretty good) and now use Conversations with most…

It's a fundamentally different approach. You could in theory build it on top of XMPP, but it wouldn't actually interoperate sensibly, so what's the point?

> It's a fundamentally different approach.

Is it? (genuinely curious) Can't one see the matrix server-server state synchronization protocol as a transport layer for MAM archives? And pubsub nodes in XMPP are very matrix-room-like. This could be an XMPP extension allowing to multi-home pubsub nodes.

Also, there are recent matrix proposals [*] for representing several things (groups and user profiles) as rooms. Given the analogy room=pubsub, the user-profile-as-room seems to be the same thing as XMPP's PEP (used to share personal data, like public keys or avatar). And the group-as-room would be the MIX proposal.

[*] https://github.com/matrix-org/matrix-doc/blob/matthew/msc177...

[*] https://github.com/matrix-org/matrix-doc/pull/1769*

Re: Drawbacks of P2P and a defense of Signal

#122

Post by erhaxf »

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).

Re: Drawbacks of P2P and a defense of Signal

#123

Post by rapsey »

kiwidrew wrote: post #45
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.

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 .

Python is slow as dirt. If the protocol is heavy, all the more reason a more efficient language should be used.

Re: Drawbacks of P2P and a defense of Signal

#124

Post by lapinot »

nednar wrote: post #115
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…

Email is another decentralized, distributed system that is often ignored. The only real difference between chat and email is that the interface makes it seem like chat is quicker. Nothing stops us from writing such interfaces for email as well, though.

For anyone wondering, there's https://delta.chat/en/. Discussed here days ago https://news.ycombinator.com/item?id=25893626.

Re: Drawbacks of P2P and a defense of Signal

#125

Post by Hjfrf »

nednar wrote: post #115
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…

Email is another decentralized, distributed system that is often ignored. The only real difference between chat and email is that the interface makes it seem like chat is quicker. Nothing stops us from writing such interfaces for email as well, though.

Facebook messages are emails, I believe.

At least an email to the user's @Facebook email address gets picked up in messenger.

Re: Drawbacks of P2P and a defense of Signal

#126

Post by stonesweep »

apichat wrote: post #77
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…

To easily get regular folks onboard you should recommand Quicksy (a Conversations spin off made by the same developper) : https://play.google.com/store/apps/details?id=im.quicksy.cli... It's as easy to use and to automatically recognize contacts as Whatsapp and Signal but it's federated to XMPP. And people who don't use Quicksy host service can register to be easily recognize as a contact : https://quicksy.im/#get-li…

You've commented at least 3 times pushing this service. From their home page:

> We charge a small fee to enter your Jabber ID and phone number into our directory. This cross financing allows us to make Quicksy completely free for its users. If you are a paying customer of the conversations.im hosting service, you can enter your number for free.

As stated on their home page, it's a fork of the Conversations (conversations.im) client with contact discovery which they're selling.

> Quicksy is a spin-off of the popular Jabber/XMPP client Conversations with automatic contact discovery.

So it's just a conversations.im client trying to make a buck with a contacts service based on what I can see. Edit: in context in case you didn't know, Matrix (at least via app.element.io -> vector.im) has a contact discovery service, and it already works with phone numbers and email addresses using a blind one-way lookup for privacy.

Re: Drawbacks of P2P and a defense of Signal

#127

Post by awestroke »

neiman wrote: post #86
oblio wrote: post #85

Earlier quoted context omitted.

Isn't Signal a non profit? Much different incentives.

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/...

Re: Drawbacks of P2P and a defense of Signal

#128

Post by fiatjaf »

Between inefficient and bad for privacy P2P DHTs and completely centralized or federated models from which you can be banned very easily, there exists a solution that takes the best of both worlds: https://github.com/fiatjaf/nostr.

Basically it works like this:

> Everybody runs a client. It can be a native client, a web client, etc. To publish something, you write a post, sign it with your key and send it to multiple relays (servers hosted by someone else, or yourself). To get updates from other people, you ask multiple relays if they know anything about these other people. Anyone can run a relay. A relay is very simple and dumb. It does nothing besides accepting posts from some people and forwarding to others. Relays don't have to be trusted. Signatures are verified on the client side.

Re: Drawbacks of P2P and a defense of Signal

#129

Post by codethief »

nednar wrote: post #115
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…

Email is another decentralized, distributed system that is often ignored. The only real difference between chat and email is that the interface makes it seem like chat is quicker. Nothing stops us from writing such interfaces for email as well, though.

I think some distinction is needed: The email protocol allows decentralization (in the sense of federation) and, theoretically, even full distribution if everyone were running their own mail server. But in practice, none of this is the case and email is one of the most heavily centralized systems humankind has come up with.

Back in 2016 I came across a computer science paper where the author had studied the decentralization vs. centralization phenomenon in various cases (not just in IT but also in real-life social networks, economic dependency graphs etc.) and concluded that every man-made decentralized system will eventually exhibit centralization to some degree as it will develop nodes that have orders of magnitude more edges than the average node. It seems to be a very natural phenomenon. I wish I remembered the author or the title…

Re: Drawbacks of P2P and a defense of Signal

#130

Post by franga2000 »

bschwindHN wrote: post #95
franga2000 wrote: post #33

Earlier quoted context omitted.

Ah yes, all those styrofoam cars such as Instagram, Reddit, Bitbucket, Eventbrite.....

Notice how the load balancers, databases, and caching layers at those places are _not_ written in Python. They then have to run a wasteful amount of instances to keep their Python services afloat. Modern computers can do an amazing amount of work in a given time slice, but it's a shame when so much of that is thrown away because someone decided to implement it in Python.

Yes, because those layers aren't theirs. They are products of other companies that specialise in high-performance and stable software. They can afford to use annoying languages because performance is one of the main things they compete on.

But for something like a social network, performance isn't something they care about. They care about being able to develop and roll out new features as fast as possible. The overhead of working in a language makes things hard and/or has poor tooling is far greater than the increased server cost of working in something like Python (or, as much as I hate to admit it, Node).

(note, that I'm not talking about the client side here. developers should serve their users and a slow fronted is bad for users. a slow backend, however, is not something users care about)

And since we're specifically talking about an open source project here, look at the difference in community contributions between any two equally popular projects where one is written in something ridiculous like C++ and the other in JavaScript.

Even Go and Rust, which are as close to modern as it gets in the world of compiled languages, are still decades behind Java, Python and Node in features, tooling and support. So until those catch up, anything that doesn't need performance above all else is probably going to stick to more friendly languages and not lose sleep about wasted CPU cycles - after all, we built computers specifically to simplify our work and that's exactly what these languages are doing.

Post reply on HN