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

Decentralize Messaging

rodarmor.com

Post reply on HN
Print view View original

81–90 of 103 posts

Re: Decentralize Messaging

#81

Post by Andrew_nenakhov »

comboy wrote: post #33
Andrew_nenakhov wrote: post #12

Earlier quoted context omitted.

As a person involved in XMPP development for over a decade, I can tell you why. To date, no one ever developed XMPP chat applications as a product, which can be easily deployed and will work consistently on every platform. Client and server developers were always disjointed, working separately from each other. This lead to great inconsistencies in implementations of even such basic functions like adding a contact. Al…

Any comment on the implementation Google did for hangouts/google talk? It seemed like that should have been enough of a push.

GTalk was a rather nice XMPP implementation, it lacked some features like message archive, storing chat logs right in gmail instead (but then again, at the time there wasn't a good XEP for message archive).

When they have dropped Gtalk and went with Hangouts (likely, because of a WhatsApp envy), crippling XMPP compatibility one step at a time, they have claimed the reason for it is that it is 'impossible' to achieve great chat performance with XMPP. Of course, that was a lie. It is quite possible, and we're doing just that.

Re: Decentralize Messaging

#82

Post by sneak »

jacob019 wrote: post #5

I don't know why everyone hates XMPP. There are multiple solid open source server and client applications for just about every platform. It is decentralized and works well but without google, apple, and facebook making it practical for grandma to use, it doesn't catch on. Well the big players have no incentive to cede control to decentralization.

Google made it practical and offered widespread federation.

It was not used by many people to talk outside of Google servers (federation ability went almost entirely unused), and it suffered from tons of inbound spam problems, so they shut it off.

To answer your question directly though, XMPP doesn’t seem to be that great of a protocol. I’ve heard repeatedly that implementing it is a big mess, and that XML was a poor choice. I’m not sure that this is the reason that users don’t use it, though. It could be that these days, the client-server model is mostly obsolete, as due to battery constraints, phone users mostly rely on Apple or Google push messages to notify.

Re: Decentralize Messaging

#83

Post by upofadown »

Andrew_nenakhov wrote: post #12
jacob019 wrote: post #5

I don't know why everyone hates XMPP. There are multiple solid open source server and client applications for just about every platform. It is decentralized and works well but without google, apple, and facebook making it practical for grandma to use, it doesn't catch on. Well the big players have no incentive to cede control to decentralization.

As a person involved in XMPP development for over a decade, I can tell you why. To date, no one ever developed XMPP chat applications as a product, which can be easily deployed and will work consistently on every platform. Client and server developers were always disjointed, working separately from each other. This lead to great inconsistencies in implementations of even such basic functions like adding a contact. Al…

>This lead to great inconsistencies in implementations of even such basic functions like adding a contact.

How could anything an XMPP server do affect how a client adds a contact?

Re: Decentralize Messaging

#84

Post by upofadown »

Andrew_nenakhov wrote: post #12
jacob019 wrote: post #5

I don't know why everyone hates XMPP. There are multiple solid open source server and client applications for just about every platform. It is decentralized and works well but without google, apple, and facebook making it practical for grandma to use, it doesn't catch on. Well the big players have no incentive to cede control to decentralization.

As a person involved in XMPP development for over a decade, I can tell you why. To date, no one ever developed XMPP chat applications as a product, which can be easily deployed and will work consistently on every platform. Client and server developers were always disjointed, working separately from each other. This lead to great inconsistencies in implementations of even such basic functions like adding a contact. Al…

>...following a set of self-imposed rules instead of developing a set of working standards that would allow XMPP apps to compete with the best messaging apps out there.

That is no excuse for doing embrace, extend and extinguish as your Xabber seems to be attempting with the XMPP standard. I can't help but note that the Xabber project has outright rejected OMEMO capability.

If you are extending XMPP in incompatible ways (as Whatsapp did) it is only ethical to clearly state that to potential users.

Re: Decentralize Messaging

#85

Post by 1wd »

edhelas wrote: post #66

> These extensions could include: delivery receipts => XEP-0184: Message Delivery Receipts optional read receipts => same as above user presence information => XMPP RFC binary serialization for efficiency and extensibility => XEP-0231: Bits of Binary end-to-end encryption => XEP-0373: OpenPGP for XMPP, XEP-0384: OMEMO Encryption, XEP-0378: OTR Discovery WebRTC signalling for negotiating VOIP and video chat => XEP-034…

For XMPP to compete with Matrix there should maybe be a website that defines something like "XMPP Profile 2020" as an exact set of extensions that are required to be considered. Then list only clients and servers that fully meet all of that profile, and compare only the capabilities in the profile with competing protocols like Matrix. Without something like this evaluating XMPP as a user is tiresome, and it comes across as outdated, inferior and messy.

To compete with things like Slack, the website should be even simpler: A single choice of client / server that are known to work together perfectly, a big download button to an all-in-one installer that requires little configuration out of the box, and nice big screenshots of all the included features.

Same for IRC.

Re: Decentralize Messaging

#86

Post by neiljohnson »

edhelas wrote: post #66

> These extensions could include: delivery receipts => XEP-0184: Message Delivery Receipts optional read receipts => same as above user presence information => XMPP RFC binary serialization for efficiency and extensibility => XEP-0231: Bits of Binary end-to-end encryption => XEP-0373: OpenPGP for XMPP, XEP-0384: OMEMO Encryption, XEP-0378: OTR Discovery WebRTC signalling for negotiating VOIP and video chat => XEP-034…

> How many Matrix servers are out there ? One, that is still in beta (Synapse). Worth noting that Matrix as a protocol and Synapse as a server implementation left beta in June 2019 (https://matrix.org/blog/2019/06/11/introducing-matrix-1-0-an...). Matrix is deployed by governments and civic institutions the world over including emergency services. It is literally trusted in life or death situations.

While Synapse is the most mature server implementation there are others under active development listed here - https://matrix.org/docs/projects/try-matrix-now.

Re: Decentralize Messaging

#87

Post by Krasnol »

rolleiflex wrote: post #39

This is what I’m working on with Aether ( https://getaether.net ). A mass-communication method owned by no one, like email is owned by no one. It’s a modern, decentralised Usenet. I used to call it ‘email for mass communication’ but it confused people, since it’s not based on email, so I stopped calling it that. That’s the goal though. I also gave a talk on it at the Internet Archive last week, if you want a quick in…

I try to find out where the front and backend config files are for quite some time now. They are mentioned in the guide, on your forums, they are not in the program folder or in the app data folder and googling it proved to be quite useless as the name is not unique enough...

Re: Decentralize Messaging

#88

Post by bergstromm466 »

ElFitz wrote: post #31
bergstromm466 wrote: post #21

Completely agree. For anyone who hasn’t come across it, check out the exciting work being done by developers of the Secure Scuttlebutt protocol: “Secure Scuttlebutt (SSB) is a peer-to peer communication protocol, mesh network, and self-hosted social media ecosystem. Each user hosts their own content and the content of the peers they follow, which provides fault tolerance and eventual consistency.[5] Messages are digi…

I'm really worried about the total amount of data each user will end up lugging around though. Also, append only => no deletes, correct?

Yes, no deletes. Since there is no company in the middle, the GDPR rules don't apply to this P2P network, so it isn't an issue legally (in Europe).

This is something that will probably take some puzzling to get to a sustainable mechanism. The strategy I've heard talked about most often is to append metadata that marks it as 'deleted', so when things populate or 'gossip' further, it won't show up in the user interface. Instead it's labeled as 'archived' or 'deleted', or has a link to it's replacement.

Re: Decentralize Messaging

#89

Post by lostmsu »

Reventlov wrote: post #72
ajconway wrote: post #70

Earlier quoted context omitted.

How do you handle push notifications with XMPP? > How many Matrix servers are out there On a side note, that's not fair. Every project has to start somewhere and it might be difficult to gain traction. It doesn't mean that it has no chance of evolving into the greatest thing possible in its market, dwarfing once popular competition, simply because it didn't come first.

> How do you handle push notifications with XMPP? XEP 0357, implemented in servers ( https://modules.prosody.im/mod_cloud_notify.html for prosody, for example), and implemented by clients ( https://github.com/siacs/Conversations/issues/1171 , for conversations for example). Conversations also uses XEP 0198 and XEP 0352 for battery optimization: https://conversations.im/#optimizations

That feature is "not recommend for production".

Re: Decentralize Messaging

#90

Post by zzo38computer »

KaiserPro wrote: post #68
zzo38computer wrote: post #24

Earlier quoted context omitted.

XMPP uses XML. IRC is simpler and can be used without any specialized software, and was designed like that, so that you can use without specialized software (I have used IRC on computers before installing a IRC client)

typing PONG every ten minutes isn't entirely practicable

I am aware, and is why I normally install a IRC client soon, but when I want to ask something first before installing a IRC client, it helps anyways.
Post reply on HN