An effort that simplifies channel maintenance, like how easy it is to open a new Subreddit (the #1 portal, a static website URL representing your community identity) is the most important step forward.
Once you establish a www identity for your community, then and only then can you discuss community chat.
For example, lobster.rs community meets on IRC FreeNode, a protocol established on their about page.
------
The reason Reddit, Facebook, and Discord are popular, is because of the easy web-based onboarding process for new users. There are also web guis which make it easy to start new communities.
Support the WWW first, and users will come (as long as the onboarding process is as easy as competitors)
XMPP was primarily about person-to-person communication, with group channels being a separate add-on.
Part of iMessage's popularity is the ability to have group conversations the same way as those person to person communications - to the point where SMS users may get excluded from conversations.
IRC is just a terrible architecture which is exposed in its protocol, but it will survive a long time because you fire it up to participate in a community, not just to talk to an individual person.
IMHO paid tools like Slack got adoption when we had pre-existing protocols and clients for decades prior because it works as a package community-as-a-service (imho, to the point of being a detriment to usability). We had the technology to solve the problem, but the packaging and focus made it a legitimate product.
IRC is for public channels (and supports direct messages). It’s far from perfect, but I wouldn’t call it terrible; it works very well for its original purpose (and has been for almost 3 decades now).
Servers in a network generally have little to no proper recovery from partitions/splits, and a split may result in changes in moderator/administrative users due to the lack of persistent permissions. There is no attempt to recover discussions during a split, or to apply consistent ordering to communication. Splits, which should be transparent, become a highly impactful event to the users within a channel.
Due to the lack of packetized responses and the simplistic method of determining an active TCP connection, it is possible to (for instance) be disconnected because of asking for a list of channels on a slow connection.
It has a _lot_ of problems, and most of the ones I listed are at the network protocol layer. It is still usable for environments where there are very active administrators and few to no bad actors, but it falls apart quickly on the public internet.
Probably any single protocol could be used to build a client that Slack or WhatsApp or [insert your target here] users would appreciate with good designers, (and/or with really little to no education.)
Multi-protocol clients are generally not optimal. The set of features that can be used will be the lowest common denominator, and if it's not the case there will be discrepancies in the design.
(Same story for bridges.)
Every protocol has their set of trade-offs, and every developer has their opinion on what's best (or the least worst). Also not every developer work with designers or have designing skills(!)
It's good for developers to be able to write what they want and how they want it. It's fine if their intended target is already with their circle of friends on the platform (if their is a target at all). It's less practical if the target is outside and their circle is not on the platform (network effect/peer pressure etc.).
That's a general "issue" in Free Software, (I'd say in software, maybe anywhere? it's just more visible here.)
Some might say waste of resources, but who gets to decide what to do with others' free time.. no easy answers.
(Sorry to spoil the fun by trying to rationalize :p)
I for one value freedom, through decentralisation (or federation as some like to insist on), and as technicalities I believe standard and extensibility of said standard are necessary. XMPP seems to fit this role ok enough to me.
I'm not even talking about multi protocol clients because, as you said, it tends to level downwards rather than upwards. But if I could "fork" the UI and slap my protocol on it, instead of having to build it from scratch, I'd save a lot of time.
You are going to be more suspicious if you are using $protocol-specific-for-encrypted-chat than if you are just browing the web.
> Bits are bits
I agree, but this does not stop my ISP from throttling my SSH speed.
There are also replay attacks and probably many other issues I can't think about. Maybe some IM protocol already deals with that.
> A decentralized messaging and sharing app built on top of Secure Scuttlebutt (SSB). https://www.scuttlebutt.nz
I think it's high time we had a concerted effort to have one great UI (probably per platform), and allow all protocol enthusiasts implement the specifics of their own choosing. It's fair to say that at this point the requirements for a "modern" UI are known, and while not all protocols may be up to the task, a very high percentage can be implemented in the most famous ones.