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

71–80 of 103 posts

Re: Decentralize Messaging

#71

Post by Andrew_nenakhov »

pmlnr wrote: post #65
Andrew_nenakhov wrote: post #62

Earlier quoted context omitted.

Well, not really fine. You should trust me in this, because our Android xmpp app is closing on 2 million installations on Google Play. There are a lot of problems maintaining a persistent connection, and Google makes it harder with each new version of Android. And if we go for push notifications, without persistent connection, the problems are the same as with iOS. To counter this and make XMPP work well on mobile an…

I believe there are problems, and a million thanks for maintaining clients. Real question: for email, I use K9, which supports IMAP Push, which, as far as I know, needs a live connection as well. Do you know if they are struggling as well, or is the xmpp push and imap push significantly different in some way?

Mobile OS pushes on both iOS (APNS) and Android (FCM) work the same: push can only be initiated by the developers of an application. So, no third-party server can push an app without intermediation by the application developers. Scheme is this:

Service -> Push service -> APNS / FCM -> Applications

With XMPP, servers act as 'service' from the scheme above, then relay a push initiation to 'Push service', maintained by a client app developers, Push service relays information to a respective service by Apple / Google, who deliver push to an Application, which connects to Service (or does not, pushes can contain all necessary information for displaying in notification, but that's a story for another time).

With email, I'm not really familiar with how IMAP Push works, but the scheme must be the same: an email server must relay info to a push service maintained by app developers, in your case, K9 guys.

From what I was able to gather after reading wikipedia for 5 min, an IMAP server upon receiving an email sends info to some 'mail user agent'. From wikipedia it's not really clear, but it appears that is is supposed to work on end devices. In this case, it won't really work as 'push'.

Google (or any other email provider, like Protonmail, who have their own app) get around this because they control both email server and push server, so it's trivial for them to initiate a push when an email is received.

Re: Decentralize Messaging

#72

Post by Reventlov »

ajconway wrote: post #70
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 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

Re: Decentralize Messaging

#73

Post by Andrew_nenakhov »

arendtio wrote: post #17
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…

How about Quicksy.im? https://play.google.com/store/apps/details?id=im.quicksy.cli...

Conversations is a relatively nice simple app for just one platform. Imagine you convince your company to use XMPP. What would iPhone users use? That's why i'm talking about this:

> a product, which can be easily deployed and will work consistently on every platform.

Re: Decentralize Messaging

#74

Post by Andrew_nenakhov »

rzzzt wrote: post #69
Andrew_nenakhov wrote: post #63

Earlier quoted context omitted.

Yes, exactly. And while currently there are ways to maintain a connection to a server on Android, it is clear that the platform is going to restrict this capability even further. Even now, if you run a background process, and start doing some memory-intensive operation, like taking a picture, your app is unceremoniously offloaded from memory, making you unable to receive messages, until the service permits a restart.

But one could open and close a desktop XMPP app as well at arbitrary times. What is the difference?

The difference is control. A person knows that if he disables a desktop client, he won't be receiving any messages.

A phone user expects that messages would be displayed to him in notifications when received. One does not expect to be cut off communications because he had pressed a 'home' button, but it's what happens, and a user does not have any control to prevent it from happening.

Re: Decentralize Messaging

#75

Post by rolleiflex »

dchyrdvh wrote: post #58
rolleiflex wrote: post #50

Earlier quoted context omitted.

You’re correct. Besides, proof of work in Aether is user adjustable, everyone can choose their own threshold. No need to turn it up unless you see spam. As you turn it up it becomes harder for other computers to pass your filters, which will cut down on spam (or anyone who’s trying to create too many posts for any reason).

While reading this, an idea popped up in my head about monetization. Sending a message needs spending a PoW token that can be mined or bought. The price is set by the recipient and can be different for different senders. Zero for friends, a high number for potential spammers. The author, however, has a private key that can produce PoW tokens cheaply, but still in a limited amount to retain trust and prevent diluting…

I thought about monetisation and it’s also in the talk linked but ultimately I’ve decided to not monetise it. Instead, to make it sustainable, I’ve created a separate app called Aether Pro at https://aether.app. It’s a much better version of Google Groups. You would use it if you wanted the modern features of Slack like channels, guests and integrations, but you also want to keep email discussions as your main work tool, and not move to chat.

By having them separate, I can make sure that the the P2P version isn’t influenced by money-making concerns, since we have a product explicitly made for that.

Re: Decentralize Messaging

#76

Post by Andrew_nenakhov »

ajconway wrote: post #27
pmlnr wrote: post #11

Earlier quoted context omitted.

1 can be queried. 2 is BS with capital letters. See Converations and it's forks.

Could you please expand on push notifications? So far I've only found https://xmpp.org/extensions/xep-0357.html and it does not look great.

Why, it works quite well. In short, the scheme is this:

XMPP server -> Push service -> APNS / FCM -> XMPP client.

Push service here is a service maintained by an XMPP client developers, cause you need a client app certificate to be able to send messages to it via APNS/FCM, and no sane devs will be handing out their certificates to third parties.

It should be noted, that the recent changes to how Apple push notifications work in iOS 13 (MORE restrictions on VoIP and 'silent' background notifications) require some updates to it, but so far, XEP-0357 does not look like something terrible.

Re: Decentralize Messaging

#77

Post by ppjet6 »

Arathorn wrote: post #22
ralls_ebfe wrote: post #9

Earlier quoted context omitted.

I moved to xmpp only for instant messaging over a year ago. At first it was met with great resistance by my contacts, but by now my family and almost every relevant friend installed conversations on their smartphone. I helped with the setup and provide them with access to my personal server. The growing public knowledge about privacy violations of the big services has made it very easy for others to grasp the reasoni…

Yes, Synapse is resource hungry - but it also does a lot more than a typical XMPP server. Meanwhile, we're finally making progress with small footprint homeservers for Matrix. shrug

> a lot more

Than allowing for messaging or "social network"-like features?

From the user in practice, Matrix and XMPP (IM) are the same. These protocols might have made different technical choices but the user still only wants to send message and do various other things that both these protocol support. So not replicating all that data is actually a feature IMO.

Re: Decentralize Messaging

#78

Post by VvR-Ox »

egypturnash wrote: post #53

I miss the days when one chat app could easily connect to multiple protocols. I didn’t care if my friends had AIM or Yahoo or ICQ or whatever, they all showed up as a tab in Adium’s window and a name on its floating buddy list.

Matrix has bridges to solve this: https://matrix.org/bridges/

Re: Decentralize Messaging

#79

Post by ppjet6 »

sagichmal wrote: post #42

It is astonishing to me that, after skimming the spec, anyone believes Matrix is the future. Or ActivityPub. Or XMPP. The future of messaging, decentralized or not, is certainly something with a tractable protocol.

I agree, and this is one of the reasons I use (and contribute to) XMPP. For the Extensibility part.

Re: Decentralize Messaging

#80

Post by miohtama »

skyfaller wrote: post #47
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…

"In Aether, spam prevention is accomplished by requiring proofs of work". Now, I recognize that regular e-mail uses proof of work as a spam prevention measure these days, so I don't want to be too harsh on a decentralized alternative. That said, I've watched the energy expenditures of Bitcoin etc. with alarm, and I've become very concerned about the sustainability of anything using proof of work if it should become p…

Spam is tradegy of commons, because spammers get infinite free messages. Make message gateways or users themselves to pay the cost, similar to SMS delivery, and the problem is greatly reduced. The cost of low quality marketing becomes unbearable to the spammers, as generally nobody buys their shit.

It does not need to be proof-of-work payment, or even a cryptocurrency payment. Gateways can have peering agreement with each other paid in dollar.

Post reply on HN