"Messaging isn't complicated. We solved this more than a decade ago."

@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.

@z428 @hinterwaeldler
That's not really true. is by far the most popular messenger app. It ran on an 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 .

@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.
@hinterwaeldler

@stevenroose (And I'm not even talking about client or server devs that consciously refuse to implement features they consider "bloat", or ongoing disputes about requirement vs. privacy in case of contact discovery ...) @hinterwaeldler

@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. 😐
@stevenroose @hinterwaeldler

@z428
I have different experiences. I use two clients consistently and sending pictures is stable across servers, both in 121 chats and group chats.
@tigase @hinterwaeldler

@stevenroose What clients and servers are involved? My core issue here is that these features seem to just depend upon more variables than actually helpful...
@tigase @hinterwaeldler

@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.
@stevenroose @hinterwaeldler

@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.
@stevenroose @hinterwaeldler

@z428
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 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.
@tigase @hinterwaeldler

@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 .
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 ...
@tigase @hinterwaeldler

@z428
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.
@tigase @hinterwaeldler

@stevenroose ... behind #XMPP really enjoy a large company massively pushing the whole standard where it wants it to be? 😉

@tigase @hinterwaeldler

@z428 @stevenroose @tigase @hinterwaeldler I would assume that Google is a large company and they have tried...

@krille
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.

@tigase @hinterwaeldler

@z428
> 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 client had 5 devs working on it full time, they could provide a perfect user experience.
@tigase @hinterwaeldler

@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 ...

@tigase @hinterwaeldler

@z428

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.

@stevenroose @tigase @hinterwaeldler

@z428 @stevenroose @tigase @hinterwaeldler

that link is crucial to me in illustrating some differences in how big companies & small non-profits have spent money on FOSS

@z428 @stevenroose @tigase @hinterwaeldler

and not to point fingers at anyone in this thread as doing this deliberately, but I've begun to wonder whether "sustainability" is a dogwhistle of new FUD against vendor-neutral, open standards, community-directed, free software approaches.

@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

@deejoe See too: Matrix vs. XMPP, ActivityPub vs. StatusNet vs. Diaspora, ... . Too much focus on the technical, the new, resulting in work "wasted" on things that became obsolete before they even saw some real adoption outside its community.
@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.

@tigase @hinterwaeldler

@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 ...

@tigase @hinterwaeldler

@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 ...

@tigase @hinterwaeldler

@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 ...

@tigase @hinterwaeldler

@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 ...

@tigase @hinterwaeldler

@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. 😉

@tigase @hinterwaeldler

@z428 @tigase @hinterwaeldler
Btw, you should chain your follow-up posts by replying to the post it's following up instead of all replying to the same previous post. I have to guess how they are chained together this way..

@stevenroose Oh, sorry, I'm a bit lost with the threading view in Mastodon at times. Try to do better next time.

@tigase @hinterwaeldler

@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 ", 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
... (d) has the standards foundation; they do a good job coordinating development of standards for extensions. We might benefit from an organization that takes on some advocating role, but individual service providers are probably better suited for that.
...

@z428 @tigase @hinterwaeldler
I think the main point you fail to realize is that never had a company with money develop a federating chat solution with it. Even just half-baked used the c2s protocol without .
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 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. 😉

@tigase @hinterwaeldler

@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.
might be doing that:
github.com/wireapp/wire-server

@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. 😟

@tigase @hinterwaeldler

@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

@stevenroose I generally tend to agree, and actually this is one thing that keeps me thinking, lately: Yes, it's possible to make things the way you want them, but in reality, in most cases, even the people I know fall back to using / having to use proprietary tools like Slack, tools that get some work done, tools that work out of the box for people who can't or don't want to build things on their own, which is by far the majority of computer ...

@tigase @hinterwaeldler

Show newer

@stevenroose ... or even technology users today. And so, while some enthusiasts get lost in trying to implement XMPP or Matrix client, they're forced into inferior tools by people who (for a good reason) don't care much about a tool and just want to get work done. There would be two ways around this: Either force those silos to adhere to open standards (which won't possibly work for several reasons) or, as a FLOSS community, see that first and foremost we need to ...

@tigase @hinterwaeldler

@stevenroose ... not mainly build things for ourselves but for people who are end-users and will choose what works - because otherwise they will choose the tools and we will lose most of the time in such situations because there are way less people aware of and enthusiastic about FLOSS than "end-users" needing work done. Plus: It would help to strive for less complexity. Make things the way you need requires you to actually know *how* to do that, and ...

@tigase @hinterwaeldler

@stevenroose .. the more complexity you got to wrestle, the more difficult it will be to achieve that. That's why I'm a proponent of *simple* lightweight protocols and standards, things that can easily be implemented, maintained, debugged. 😉

@tigase @hinterwaeldler

Show newer

@stevenroose @z428 @hinterwaeldler
Also, WhatsApp isn't the first time that a big 5 tech company took a huge userbase built on XMPP and gave the community the finger

Among the things that ActivityPub can do is provide discovery mechanisms for communicating about capabilities and bootstrapping key exchanges. I've seen indications that's something the Pleroma devs would like to do with XMPP

@stevenroose @z428 @hinterwaeldler
GTalk, the predecessor to Google Hangouts, was an XMPP network. Much of the base came from Google forcibly onboarding GMail users, of course, but their early infrastructure was XMPP, which they abandoned just as it looked as though interoperability was beginning to happen

ActivityPub is similar to XMPP and other federated protocols in implementing the actor model, but it does so over HTTP, so it has access to better infrastructure for random access to persistent information than XMPP, SSB and other decentralized protocols. CrUD semantics for managing collections and standards for certain social collections don't hurt this use case, either

@yaaps @z428 @hinterwaeldler
Sorry, I wanted you to elaborate on what exactly the Pleroma devs are planning related to and ..

Also, I used GTalk when it was new. While you could use GTalk with XMPP clients like Pidgin, it never federated with other XMPP servers. So yeah it just used the server software until it was too slow for them.

@stevenroose
Pleroma has always had chat in its sights, but @kaniini recently made a throw away remark about XMPP and OMEMO in a thread about resuming progress on LitePub

The theme of using ActivityPub in connection with other federated and p2p protocols is common outside of Mastodon development. From Tahoe-like file systems in Webber's demos to blogs about the synergy among AP, SSB, and Dat, it's pretty certain that sharing private conversations and large objects will eventually use AP as a bootstrap, but rely on other protocols for transmission

@yaaps
An integration with would be cool. ConverseJS can already be embedded in other web pages and a good integration with Pleroma can discover XMPP addresses in user profiles and add a "Start a direct conversation" button or something.
@kaniini
Cc @jcbrand

Steven, this can already be achieved to a degree by just using xmpp URI in PropertyValues. For what it’s worth some software (e.g. Mastodon) does not recognize xmpp URIs as “safe” but others (e.g. Fedilab) properly supports them.

Of course there are other places where one could put the URI, e.g. WebFinger self relation links or a custom actor properties.

Sign in to participate in the conversation
Fosstodon

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.