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-0343: Signaling WebRTC datachannels in Jingle
signed introduction tokens to reduce spam => ?
a standard extension mechanism => https://xmpp.org/extensions/
Can we just stop prettending that XMPP is not ready and/or outdated, all those things are there, used and implemented in more clients than Matrix has.
Doing decentralized social media, on XMPP, is possible. Take XEP-0060: Publish-Subscribe, add Atom 1.0 (yes it's the power of XML, you can put a standard in another) and boom you have a social network with feeds, comments, subscriptions and everything, fully ready.
I'm doing that for years with Movim https://movim.eu/. The several major XMPP servers are handling that perfectly as well. How many Matrix servers are out there ? One, that is still in beta (Synapse).
XMPP is standard (IETF wise), is already massively deployed, is used by universities, governments, companies…, is exensible, is stable and is maintained by a big and motivated community.
Don't reinvent the wheel once more, just implement the standards.
> 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.
Thanks Neil. It's difficult to find alternative servers on that page so I will help by linking to The Construct which is the only other federating server. Though it is not yet stable, it is the only functioning third-party server and has more progress than your own reference implementation's rewrite!
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.
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.
Protocols and privacy and chat features are all great, but let's not lose sight of the two absolutely killer essential features of every successful chat app / system:
(1) The address book.
(2) The easiest possible signup and setup.
More generally for #1, whatever method(s) you use to find people's contact information and connect with them.
Without that, you could have created the perfect chat experience in every way, but people still won't use it. Because their friends aren't on it and/or they can't find their friends.
A ton of chat apps fail because engineers sit around talking about how to architect things, when the truth is that once you've gotten past the almost-insurmountable hurdle of getting two users onto the system and starting a conversation, the actual mechanism for actually sending messages back and forth is not much more than an implementation detail.
Not that those things aren't important, but they are like 10% of the formula for success, and the other 90% is getting to the point where they can start a chat session.
People's primary need is to communicate. With the people they want or need to communicate with. And via the contact information they have available. (Exchanging contact info for a new service offline is a huge hurdle.) A better experience is better, but at the end of the day, these other concerns will nearly always win out. So you don't get very far trying to use a superior experience as leverage to get people using it. You need to attack that problem more directly.
So true. One of my most active channels of communication is actually Instagram's chat despite it lacking many features I prefer in a messaging service like a desktop/browser interface and search functionality. But it's what my friends use, more actively than Facebook even, and so it's what I use. If you have Instagram then you already have this messenger, so it becomes a no-brainer.
1 - this is a good point, but I'd like to expand on it - it does not have to be address book.
I have helped thousands of people exchange contact info after meeting in various niche chat rooms first, but you can flip that and have your irl friends meet you in decn-chat dot org click the 808game room, we can meet in there and pm/dm a code word or something and make each other contacts in various ways.
Your point is something to keep in mind though, ultimately I think we also need apps that can display a qr code like a one time pad to give someone contact details or any chat rooms to meetup in, Other methods of exchanging info about contact and chat room / chat app options should be added to whatever is going to be really good.
2 - I really agree with this, I spent some money and time on rocketchat development to give an optional 'open lobby' to anyone who enters, just pick a name and you are in.. then if you want extra abilities you can add an email or verify or whatever.
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 intro in video from. https://archive.org/details/12120iadweb (My part starts at 1:13:30). If you have any questions, happy to answer.
"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 popular. Fundamentally proof of work makes people waste energy in order to accomplish tasks such as sending messages, at a time where we need to use as little energy as possible to reduce emissions.
Have you considered sustainability at all with Aether? Have you considered any alternatives to proof of work for dealing with spam?
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 everyone's share to nothing. Some companies may want to send spam and will be happy to buy PoW tokens. Users that suddenly start getting spam, raise the bar, as it costs them nothing. Those companies now need more tokens and they come to you. This is inflation. As long as SEC understands what's going on, it shouldn't have problems with this sandbox economics.
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.
I presume it should also be possible to reduce the threshold for my contacts/friends... so that strangers emailing me for the first time need proofs, but frequent contacts don’t.
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.
Thanks for your presentation at that meetup! It's definitely one of the most radically-decentralized & technically-principled projects, so it was good to see it alongside other presenters there, like Matrix (definitely headed in the right direction) & Planetary (built on similarly-principled Secure Scuttlebutt).
Totally, always a pleasure to talk at the Archive — not only just because of the like-minded people but also because I get to keep these recordings and pass around, and that's super useful in quickly explaining what it is.
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...
If you go to Preferences in the app, it will tell you where exactly your specific config files are. You can then copy and paste that path to access the files. Make sure you edit only after app is fully closed, or it will write over your changes from the copy in memory on exit and your changes will be reverted.
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 digitally signed and added to an append-only list of messages published by an author.[6] SSB is primarily used for implementing distributed social networks, and utilizes cryptography to assure that content remains unforged as it is propagated through the network.”
... that said, it has some enormous problems around multi-device, rather costly replication (start at the beginning, catch up to now, otherwise you can't verify anything), and it's fairly normal to miss part of a conversation and not have any real way to get it filled in. There are a number of branching concepts with semi-compatible protocols that strike me as a lot more promising, but odds seem pretty good that the community will shift if necessary (which is a good thing).
Worth a shot for anyone to explore if they're curious though, there's even a largely-functional mobile app: https://www.manyver.se/
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.
It should be noted that while you can't delete / edit messages you _can_ delete blobs (binary attachments). They'll come back if you load a post that references them, but that's where the majority of size comes from and it is manageable.
Also, how much you download is related to how many people you follow, and text doesn't take up a ton of space.
Sure. But where do the blobs "come from" when they "come back". Since it's fully P2P, someone has to keep them around.
As for text not taking up a ton of space. Sure. Except it's text with it's metadata, and possibly text generated by a few hundred people.
A friend and I managed to exchange ~24k messages on Slack over the last 3 years (~4k each / year); using it like some kind of "private twitter" where we would just post anything that might be of interest to the other.
What would it be like if I follow 300 or 1000 people doing the same, over Secure Scuttlebutt?
- At 1 byte per character (from what I've gathered, Unicode characters actually take up 1 to 4 bytes)
- 140 characters / message (because Twitter proved it's usually enough)
- messages' metadata (50 bytes?)
- 4.000 messages / user / year
- following 300 people
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.
I’ve been using Franz for a while for this purpose. While it’s not exactly the same (it launches a process per application), it is very convenient to have all of them in a single place.
I'm working on a sort of ancillary project which may help with this at Valyrio [https://valyr.io]
Counter-intuitively, the current goal is to centralize the messaging interface, providing a common platform for users who are willing to pay for a consolidated system that saves time and confusion, and to reduce the waste of niche use cases (e.g. having the entire [name here] messaging app on your phone because one weird family member or friend insists on using it)
Bringing email, text, and (aspirationally) all other messaging systems into one.
In doing this, we cannot possibly hope to uniquely integrate each of the countless hundreds of services with their weird quirks and formats, so I aim to establish a standardized language for async messages equipped with the basic common features and extensions for prevalent (but not universal) features like read receipts, "liking/reacting" to messages, etc
It would be really cool to open up that standard to the world if we do a good job of designing it, or collaborate with anyone else who wants to participate in this goal. Our core service will be a niche, paid, closed system, but the underlying language I would like to be open source and interoperable with whatever else turns out to develop (Twitter's new endeavor and Matrix are the two efforts I am most aware of)
After all, Valyrio means Language
I've also been working on an adjacent concept with [https://jwmza.com/polymath], which is a new comprehensive markup language meant to define long-term compatible, human readable documents and websites/document structures which intermix existing standards like (La)TeX, HTML, CSS, Markdown etc.
Perhaps the underlying language and concepts here will mix with the effort to decentralize messaging as well, as messaging is fundamentally the asynchronous bidirectional transfer of documents of mostly text and sometimes other media or information.
Isn't this, at least in part, the goal of OStatus/Mastodon? It's a great idea but I find it humorous and ironic that many mastodon admins circulate block lists specifically meant to cut off nodes. I would prefer that users just use the block features available (and adding the ability for a user to block nodes or apply blocklists if they want to, but not for admins to make that decision for them).
> messaging apps are all the same, making them easy targets for standardization and interoperability.
This is patently false. Look no further than the other comments in this thread. Nobody can agree on what they want out of the messaging experience. Some want a rich experience like telegram and others want a minimal one like IRC. Should this protocol's features maintain parity with the proprietary and centralized services? Better develop them rapidly to keep up. Should they stagnate to maintain interoperability across an ecosystem? Good luck being competitive. We haven't even gotten to the features themselves and I promise you there will be irreconcilable differences. Does the protocol maintain message history or is it ephemeral? What is the privacy model? Can we delete messages on other servers due to GDPR? When you spend time at the business end of the messaging space, these dichotomies flow endlessly, without consensus, and they cover the entire horizon of the space.
If you think you know the answers to these questions, you don't, because you're solving the wrong problem. If you want to decentralize messaging you have to solve the problem of how to agree to disagree while maintaining interoperability for a shared experience. Let me just make that last point clear: you cannot design a messaging protocol where one party sees emojis and the other doesn't. That doesn't work because you can't lose social information.
Matrix has failed to solve this problem. We need a new approach. What will emerge to finally conquer this space?
I feel like you're overestimating the differentiation and not accounting for the fact that 99% of the population basically just uses the minimal subset of features (sending plain text and images)
Two services don't need to have identical feature sets to interoperate, because you don't need perfect, full interoperability, if you can send most of your messages across platforms, that's still pretty good.
> Let me just make that last point clear: you cannot design a messaging protocol where one party sees emojis and the other doesn't.
Which service doesn't show emojis? Literally every mainstream mobile operating system and desktop browser supports emojis as regular text.
> the fact that 99% of the population basically just uses the minimal subset of features
The tendency is for people to invoke features situationally. If you are communicating with someone who is using rich-replies there is a tendency to also invoke that feature yourself. If people are using emojicons there is a tendency for others to play along rather than use plaintext characters. Feature invocation is situational and relative.
> Two services don't need to have identical feature sets to interoperate, because you don't need perfect, full interoperability, if you can send most of your messages across platforms, that's still pretty good.
This has proven to result in an unacceptable user experience throughout the history of messaging. When a system loses social information from the environment it is no longer an effective communication tool. Worse, it is dangerous. If you send me a message and I respond to your message with some thumbs-up emoji, and your platform doesn't support it (e.g. a text-based IRC client) that information gets lost. You believe I have disregarded your message. You may assume I have been rude when the opposite is true. This is absolutely unacceptable UX.
> This has proven to result in an unacceptable user experience... Worse, it is dangerous. If you send me a message and I respond to your message with some thumbs-up emoji, and your platform doesn't support it ... that information gets lost. You believe I have disregarded your message. You may assume I have been rude when the opposite is true. This is absolutely unacceptable UX.
This is an assumption that bad implementation is the only possible implementation, and it is wrong.
Obviously omitting content from missing features is bad UX - but it's absolutely not necessary to interoperate. It's easy (and should be expected) to avoid this by simply telling the user something from a missing feature has been sent - they can then inquire and get back the lost information / clear up the confusion.
Furthermore if interoperability is implemented on both ends, the sender's client should know to alert the sender before they attempt to use features missing on the receiver's end.
> I see two promising and complementary paths to decentralized messaging: building on the new and shiny Matrix protocol, and gradually extending email.
COI is chat over IMAP[0], I think it's one of the best solutions I've seen in the sapace.
It feels like we are saturated by messengers and social networks. Twitter, fb, slack, discord, matrix, signal, whatsapp, wechat, telegram... I am not sure what decentralization could bring there.
He said the move is to specifically reduce fragmentation in public conversation.
I'm in the decentralized (dWeb) community (we have 10M+ users monthly, in-production, running thru GUN) and admittedly, I think we all get distracted with the war cry of privacy, p2p-for-sake-of-p2p, etc. but is not many other people's end goals.
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)
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. Also, it often happens that when a client developers need some feature that honestly should be done by a server, a developer still does this on a client, because it's all he has, with subpar results.
Absent leadership from XSF also plays a role. This club now mostly cares about bureaucracy and 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's why it is unlikely for any great product to appear under such guidance.
We're trying a different approach, maybe we'll even succeed. If so, you'll hear about it on HN.
>...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.
1. We don't do embrace, extend and extinguish. All we do is open-source, with products available to download, and docs fully available.
2. We don't 'outright reject OMEMO capability'. I reject OMEMOdiots who moan excessively because their wishes aren't satisfied on the spot.
Why are not they satisfied? Because XMPP does not have a reliable control of message delivery, no way to remove messages from message archive, no good group chats, no client sync protocol, no way to revoke session tokens, no way to know which messages in archive were read, no way to add reactions to messages, no way to do threaded conversations, and while we're building all that we're constantly attacked by individuals who demand us drop everything we do and urgently add OMEMO so they can feel safe (and do it at our own expense, of course).
We'll provide some E2EE capability, but only after we are finished with everything else that we consider more important than this.
3. Extending XMPP in incompatible ways, I'll cover this a bit.
Do you even remotely imagine an amount of shit an XMPP client (say, a web client with no stored history) built on 'compatible' XEPs must do to display a telegram-like interface, with all the recent chats? How much time does it take? Best result we could achieve in our web version with 'compatible' server and 200 contacts is like 5 minutes. With our custom XEPs, it's currently down to 15-20 seconds, and our goal is to trim it to 3 seconds. Does it break anything with s2s? No. It only adds methods of how a client interacts with a server, that's it. Does it break legacy clients? No, they still can do it the old way, if someone is willing to wait 5 minutes.
Next, we have our group chats. They are powerful: archive search, moderation, anonymous mode, public mode, pinned messages, replies, mentions, extremely agile restriction/rights management. They are very easy to implement (on a client) and provide a nice fallback compatibility for any XMPP client even without support for them. You don't need support on participant server to use it (not as in MIX, to say). You can chat using multiple devices, with legacy clients alongside supporting clients, all working nicely with simple Carbons.
Documentation for all improvements is open, (it's not in english yet, but we're getting there), implementations are open-source and distributed under GNU licenses. No, I don't think your point about extending in incompatible ways is valid.
Probably, the more correct way to call it is that we are forking XMPP. Like, in git. We'll be sending XSF pull requests on every XEP we create - hopefully, one day XSF will come to their senses and see that their platform is fading into obscurity and irrelevance, and that to prevent it from happening they should do something differently.
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.
Hehe, you are correct. I wondered if you would come back to that point when I posted the Quicksy link ;-)
Actually, I don't know why the ChatSecure guys don't get their software to work reliably. It got a lot better over the past two years, but sometimes I still wonder why a ChatSecure user doesn't read my message. In addition, it is not as easy to use as Quicksy/Whatsapp.
One of my friends uses Monal, but in essence, it is the same story as ChatSecure: It kinda works most of the time and got better over the past two years, but I am still not confident it works reliably.
So for iOS, I have no solution and neither do I know of any _high quality_ XMPP client that supports video calls. But in fact, those issues don't stop me from using it :-)
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.
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 reasoning behind my preference for decentralized services.
I actually thought about using matrix, but it apparently "modern" means "resource hungry".
My xmpp instance server runs on a small server with 2GiB Ram, with more than 1.5GiB being unused.
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
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.
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.
Servers most certainly do signal capabilities and extension support to clients, I do not have enough experience to comment on server-server signaling.
With message archive management and message carbons there are no weird deliverability issues. I have not noticed battery issues with conversations running on several devices for the past couple years.
2 is not BS, but not for the given reasons (heavy battery use/weird deliverability issues). 'Not handling mobile clients well' is true.
Did you ever wonder why there are no (to date) XMPP clients on iOS that are not complete and utter shit?
As a person who has first-hand knowledge of the matter, managing a team member tasked with the development of an iOS XMPP app (which is supposed to be NOT complete and utter shit), I tell you that creation of such app is impossible without reinvention of half of XMPP stack (basically every part that touches client-server interaction). Thankfully, s2s works rather fine in XMPP.
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 and in browsers, we had to develop our own server and a bunch of new protocol extensions.
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.
My understanding is it's because XMPP expects the client to be able to maintain a connection to the server, which is typically not possible on iOS. Apps on iOS are generally not permitted to run in the background, with a few limited exceptions.
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.
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.
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.
Because then devs would need to follow rigorous standars with xml instead of "just building it".
Yes, I'm full of anger. We had xmpp, pidgin, miranda, trillian. Now we have gazillion mobile only (no, a web gw through a server to your phone is NOT a desktop client) messaging, so let's throw matrix in to solve it, instead of building an xmpp client with up to date xep support. Xkcd 927 on steriods.
We could decentralize things more, but then people will point to decentralized communication and claim it's dangerous because it helps drug dealers and pedophiles.
thats why its best to extend email . it's already decentralized and people don't claim it helps drug dealers. i think the worst part of centralized services is they made police and states complacent and depend on constant spying
hm not really, thanks to corporate / institutional email silos . sure there is gmail, yahoo , outlook ... but also a huge long tail that is not going away
Unfortunately, it's probably too late. Email caught on because it was the first option, and it's become ingrained in spite of itself.
At this point the closest thing to a standard for person to person messaging is SMS... which like the old guard of ICQ, uses a number rather than a screen name.
That said, I would love to see a good standard for person to person chat, especially one that doesn't rely on magic numbers.
Doing decentralized social media, on XMPP, is possible. Take XEP-0060: Publish-Subscribe, add Atom 1.0 (yes it's the power of XML, you can put a standard in another) and boom you have a social network with feeds, comments, subscriptions and everything, fully ready.
I'm doing that for years with Movim https://movim.eu/. The several major XMPP servers are handling that perfectly as well. How many Matrix servers are out there ? One, that is still in beta (Synapse).
XMPP is standard (IETF wise), is already massively deployed, is used by universities, governments, companies…, is exensible, is stable and is maintained by a big and motivated community.
Don't reinvent the wheel once more, just implement the standards.