"Messaging isn't complicated. We solved this more than a decade ago."
@hinterwaeldler I think an important point against the article was left out: jingle and video chat. That was a big one with the growth of high bandwidth connections. XMPP just did not work well, and to this day there is not a single XMPP client on Android with good Jingle support. The only one that ever came close was Jitsi. Why mess with Jabber when I can use Skype? People like open standards whether they know it or not, but they like things that work seamlessly even more.
@mister_monster You have a point here, I don't even have a proper opinion on jitsi/jingle, because it never was on my radar.
@hinterwaeldler though, IMHO; security (and especially metadata leakage!) is a very important difference and special there. Some apps do it very good – but even these have differences – some do not.
We see that this is a hard and not really solved (no PGP is not usable for the !) problem with mail e.g.
@hinterwaeldler Unfortunatey, we "solved" it just the way a lot of the FLOSS and standardization crowd "solves" things: "Here's a basic standard, it's a protocol, it's extensible, so you got all you need". We didn't really "solve" it as in: Providing client applications for end-users on a WhatsApp/Telegram level (actually early WhatsApp *was* an XMPP client, basically). We didn't really focus on end user use cases but mainly on technical and engineering stuff (extensibility, ...
@z428 True, I don't recall the FLOSS apps being as appealing and easy to use as ICQ / MSN / early Skype.
@hinterwaeldler ... decentralization, ...). We didn't fix keeping up with changing requirements (transferring files and digital media, contact discovery, ...). We *could* have solved it. We had all the tools around. We just never finished building and shipping it.
@m4lvin @hinterwaeldler Yes he does great jobs in many aspects, but that still require a way much larger momentum to really change things. Right now, #xmpp still desperately tries to catch up with the other proprietary messengers in terms of features, acceptance, adoption (maybe in this particular order).
That's not really true. #WhatsApp is by far the most popular messenger app. It ran on an #XMPP server for most of its existence. XMPP has a standards body and a protocol for proposing standard extensions. So WhatsApp should have proposed extensions for all the features they found were missing from the protocol. They should have enabled federation while other providers catched up on implementing the new protocol extensions.
Instead, they decided to build a #silo.
@stevenroose I think extensibility per se is good but causes a problem almost impossible to handle, as current #XMPP network proves rather "well": You can never be sure how up-to-date your federating servers or third-party clients are or which extensions they support. You'll never be able to provide a reliable behavior for many features because of that, and you won't even have a way to fix this. In the end, the only thing that works for sure are plain text messages.
@z428 @stevenroose @hinterwaeldler actually this is also beauty and curse of XMPP - it's flexible and could be tailored to particular needs. And you, as a user have choice - maybe you are privacy oriented and don't want contact discovery then use server x, maybe you do, then user server y. #XMPP has also built-in mechanism of discovering features and it can be used to gracefully adjust the service.
@tigase I agree, but it also adds a tremendous complexity and is possibly rarely done right. Just as an example: Sending pictures, a fairly common use case, so far in #XMPP only worked here with the same client (Conversations) on both ends and both users on the same server. Across clients or servers, results were in between arcane error messages, sending quietly failing or sending apparently successful but file never received. That's rather strong, in 2019. 😐
@z428 @stevenroose @hinterwaeldler problem being - there were usually a couple of ideas how to solve particular problem (file sending being one example) but it seems that community is starting to converge on particular solutions (and there are compat suites for each year). For file transfer HTTP Upload seems to be the most popular one, working with the majority of clients (and even groupchat). If you experienced problem then that's weird - even if recipient uses older client it would get just a http link…
@tigase The latter part, actually, is even worse, also seen in case of server-sided message archives and trying to make sure all clients have access to their full message history. Different approaches, different XEPs (at least as of 2017 when we internally started giving up on #XMPP), and different devs convinced their understanding is the only "right" one. That's why I easily would prefer a versioned protocol rather then loads of extensions.
@tigase So maybe extensibility has become an antipattern altogether and we should rather strive for a versioned protocol that gets regularly updated - and some mechanism similar to Signal that warns client or server users if their protocol implementation is outdated, eventually locking them out at some point. This also would help to get things like OMEMO rolled out much faster.
I really think you overstate the issue of extensibility.
The reason why it hasn't happened is that no company has tried to do it because they don't want to.
There are ample ways to provide a decent experience in the #XMPP landscape. And it's perfectly fine that if two people have different clients and servers that they are only able to benefit from the features their services have in common. A simple "can't do this because contact doesn't support it" should do.
@z428 @tigase @hinterwaeldler
Companies with budgets like Google's, Facebook's or Apple's are perfectly capable of creating apps that match their current user experience on top of an open #XMPP.
And exactly the fact that some clients might adopt new features first will be an incentive for other clients to become compatible.
@stevenroose But in the meantime, functionality for some of the users of these services would be limited or even disrupted while talking to other people using "older" technology. It opens way for a wide range of communication problems that very likely will hit *your* support team even while they are completely out of your control because you can't do anything about making sure, in example, that other client dev gets his stuff fixed. Plus: Would the open community ...
If a service provider is so worried about bad user experience, they can always disallow you to chat with contacts that don't fulfill a certain minimum requirement of feature extensions.
"Not able to connect to this contact because they are using old software that is incompatible."
I agree it's not ideal, but it's way better than the current silo ecosystem.
Have they really? It's true that they sponsored some open-source work here and there. And they tried doing Hangouts over Jingle.
They could have perfectly have decided that Hangouts over Jingle was too hard and only support Hangouts as a proprietary thing while keeping the rest of the chat app federated. But Google Talk never federated.
@z428 @tigase @hinterwaeldler
@stevenroose Yes you could possibly do that, but that will get pretty complex pretty fast. Just going with the image sending example, imagine users with different capabilities connected to a group chat. Or users connecting with different clients, in worst case at the same time (desktop, mobile). Implementing a client with a sane usability for cases like these seems more than just challenging. And so far, not even the FLOSS clients bothered doing so it seems.
> not even the floss clients bothered doing so
That's the wrong way to look at it, IMO. FOSS devs usually don't have resources, so they have to make way bigger compromises. I believe if any FOSS #XMPP client had 5 devs working on it full time, they could provide a perfect user experience.
@stevenroose I'm unsure and feeling a bit guilty here for blaming people. Then again, in FLOSS XMPP clients, I see one of the usual FLOSS problems in the late 2010s: A plethora of different tools, all, like, 60% feature-complete (rather than having two that are close to 95% feature-complete). FLOSS development, in this regards, doesn't seem very sustainable. That's one of the reasons. And, here we're talking extensibility again, I thoroughly wonder ...
Few acknowledge how commercial interests undercut slow-and-steady, sustainable FOSS development by pushing hothouse all-the-features-now-if-you-use-us approach: It sacrifices interoperability, but also sets high (albeit shallow) expectations. If everyone just uses *our* service, there's 100% compatibility & it's harder to notice what features are missing.
@deejoe About to read through the article later, thanks, just for now: My only issue with sustainability in FLOSS these days is that, apparently, people cooperate way less than in the late 1990s and are much more focussed on starting greenfield projects for various reasons, not all of them necessarily honest or for the best of the community. Sometimes fixing something in existence would be a better but more difficult thing.😉
@stevenroose @tigase @hinterwaeldler
@stevenroose ... whether it wouldn't make sense to focus on protocols and standards that are more lightweight, easier to implement for FLOSS developers as well, more focussed on a particular use case rather than trying to be the glove that fits all hands. In a lot of cases, extensibility seems to end up in over-engineering things to meet requirements that aren't there at all.
@stevenroose Difficult at the current state. Some things I'd consider important steps: (a) Make Matrix and XMPP work with each other. We don't at all have to argue about why silos such as WhatsApp aren't federating while at the same time there are open messaging protocols that can't directly federate but just bridge into each other (and most important here, give up on the idea of blaming each other, like, "it was *their* decision to roll their own"). Next ...
@stevenroose ... (b) try to get rid of that extensibility, or at least make it much more strict. That sounds ab bit harsh and maybe I don't know enough of particular XMPP implementations to know whether that's feasible, but I really think it would be a good thing to go through use cases for extensibility and check whether they are required or not and whether they couldn't be handled as part of the core protocol. (c) Establish a strict proces of core protocol ...
@stevenroose ... versioning, with, maybe, one new version every 6 months and a contract that clients and servers who are more than two versions "behind" will automatically be warned or disconnected. Make sure the whole network remains reasonably up-to-date to avoid wasting resources on providing backward compatibility 20-year-old software. Finally, idea (d): Establish some sort of "organization" (foundation? ...?) that takes care of coordinating "marketing" and ...
@stevenroose ... development. Someone should look at where WhatsApp, Telegram, Threema are today, where XMPP based messaging is today, evaluate what's missing to make it more interesting and make people to move here and give up on WhatsApp and all these silos, and make sure in some way this "happens". The biggest issues I still see with XMPP: It's capable of doing "everything". But at the same time, in example, I fail to provide Windows desktop users with a ...
@stevenroose ... meaningful client, I fail to quickly create "chat groups" like in WhatsApp or multi-user "ad-hoc" chats by mentioning other users like done in Slack or Mattermost. Maybe indeed XMPP *can* do all this. Then, all we're talking about is a lack of use-case- and user-centric clients that actually make these features usable and available. Not idea. 😉
@z428 @tigase @hinterwaeldler
I'm not really convinced by your argumentation at all.
(a) this is not a priority, could be helpful but is counterproductive
(b) there are XEPs that define the extensions you need to qualify as "modern #XMPP", so called compatibility suites; they work fine and implementing them as an extension or as a part of the core protocol isn't any different
(c) sie (b) + you can already deny contact with clients that don't support certain features, no version needed ...
@z428 @tigase @hinterwaeldler
I think the main point you fail to realize is that #XMPP never had a company with money develop a federating chat solution with it. Even #Google just half-baked used the c2s protocol without #federation.
#XMPP is not a chat app, it's a protocol. It relies on parties that have the means to develop chat apps to use it and implement it.
We're very lucky that ProcessOne has resources to develop #ejabberd and that Daniel found a way to do Conversations full-time.
@stevenroose Agree with most of your points. I'm fully aware of this, too, and actually I see this to be *the* main problem. XMPP is a good *protocol*. But not more. And that's not enough to compete with WhatsApp and other commercial offerings at the moment. That's why I am suggesting some sort of organization (maybe like Wikimedia, GNOME Foundation, ...) that takes care of actually building a "shippable product" on top of it. 😉
@z428 @tigase @hinterwaeldler
Well aren't we all suggesting that? :D
I wouldn't even mind if a closed solution would be provided (like a client that only works with a central federating server). As long as there is something that is user-friendly that I can point people to and say: this chat app is better than the others because it's doing the right thing because it allows to chat with people without requiring them to use their service.
#Wire might be doing that:
@stevenroose Ok we're on the same page here again then, I guess. I'm not really intending to rant here, just pretty much disappointed with how many of these things work in FLOSS. Too little collaboration. Too many situations of "reinvent-the-wheel". Too little interoperability, like mastodon vs. Diaspora vs. XMPP-PubSub. We could have been replacing WhatsApp, Signal, Slack, Twitter easily if we just were able to focus and cooperate. 😟
@z428 @tigase @hinterwaeldler
That's very true, 100% agree. The sheer amount of half-baked clients is incredible.
It's something that defines FLOSS, though. And it has its good sides. It empowers people to make the things the way they want them; and they very much should do that. It's something that is being forgotten too easy by non-geeks and even by geeks.
Open-source is amazing and people don't realize its power. I'm sad to say that from my broad social circles, I don't know anyone in FLOSS
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!