I'm looking to wearables and low-power IoT devices, and for those we may need a new federated identity/discovery scheme. The DNS is practically ancient now, but has served email, web and XMPP and many other protocols besides surprisingly well for decades. I doubt it is sophisticated enough for global-scale wearables and ubiquitous sensors. We could never have built anything so sophisticated on phone numbers.
Most of your remarks seem to align with the preferences of chat app developers. But actually there's no group I'd trust less, today, to determine the future trajectory of communication. Interoperability, federation and end-to-end behaviour is the open architecture of the Internet, and I believe anything that undermines that triad should be met with contempt and resistance.
Re sharing contacts by replacing User@Domain with numbers:
Yes, this solves some of it because everyone agreed to use phone numbers, but phone numbers are a thing of the past and you don't always want to share your phone number just for messaging.
Re notification overhead:
If you have a system-wide notification display system, then of course the resources it requires are limited but you still have to have it running in the background in some form. Granted, it's probably easier to optimize it with everyone using the same notification system. This is just consolidation of a popular feature into system-provided functionality.
Re lockin:
But lockin still exists because you are the whim of centrally managed for-profit messaging backends, operated by entities whose intentions may not necessarily align with yours.
I'm not aware of cross-app synchronization of messages and even less so a common message format (feature) set supported by all that provides a rich experience.
I don't disagree with the cited shortcomings of XMPP, though you can always find a flaw in something which wasn't explicitly designed for the current use case, so ignoring that, the basic premise of XMPP is still sound and needed. Implementation details are something else, and honestly I don't agree that replacing XML with JSON (as in some of the proposals) gains anything in terms of efficiency, which it probably wasn't intended to anyway.
My impression is that building a messaging system is simple enough that many variants pop pup, but almost all of them get interoperability, synchronization, mobility, and security wrong. It's unsurprising because the simplicity attracts implementers of all domain experience levels.
lockin still exists because you are the whim of centrally managed for-profit messaging backends
Given that 99.99% of people will never run their own servers, this is irrelevant: someone will be managing the infrastructure and those people will be motivated by profit. Welcome to capitalism: it works better than the alternatives despite its flaws.
Things like WhatsApp or GChat do not simply replace XML with JSON. They tend to use binary protocols designed for low power consumption and ease of parsing. Arguably, if any protocol gets it wrong, it's XMPP ... I used to like it back when it was called Jabber, heck, I even hung out with a few Jabber developers back in the day. But Jabber's design goal was instant messaging and it's no longer useful for that. It just couldn't adapt to even quite small changes in circumstances.
I didn't say there has to be. What I said is there's a single notification service which is reused by everyone. If you're saying that there's no daemon of sorts for notifications, then I'm curious where it's implemented.
> Given 99.99% of people will never run their own servers, this is irrelevant
It doesn't matter that someone won't run their own server. What matters is that you can, which means someone you know or trust can and give you access. These days it's much, much easier to run simple services like messaging if you consider the proliferation of remote accessible NAS boxes and such in households. Adding a messaging service to that is easy. Other than that you can use Sandstorm too if you don't want to operate a server.
> Things like WhatsApp or GChat do not simply replace XML with JSON
I'm sorry you thought I said WhatsApp or GChat use JSON. I mentioned it in reference to other messaging services.
If I want to chat with person X, I either have to use the same client as them, or I can’t do it.
I can’t write my own, better client, either.
That’s the big issue.
But then again in Europe iPhone market share is much lower.
If you want to make a better WhatsApp, all you have to do is ... build a better app. The traditional obstacles are largely gone in the mobile world:
• You can access the same social graph just by requesting the contacts permission on your mobile phone: it's not like Facebook where the social network is locked away.
• You don't have to go through some slow moving standards process which takes years to get the features into the most widely used clients like you would if trying to improve XMPP.
• There's no cost to the user having multiple messaging apps installed thanks to Google/Apple's push networks: it's not like Windows/MacOS/Linux where having an app running in the background uses resources and requires permanent on-screen reminders of the resource wastage. So it's easy to get the user to set up your app.
• Notifications will appear in the same place the user is looking for them no matter what.
• You can (on Android) register for the right intents and whenever a friends phone number is invoked, your app will be offered as an option, so there's no lockin there either.
These things together mean the traditional reasons for pursuing federated networks for chat (the avoidance of lockin) are largely irrelevant.