[komali2]

For me the issue with IRC protocol (not that I know much about it outside my interaction with UIs built around it) was authentication, and connectivity.

So I had an android IRC app for a bit, some top paid one, and get booted from a bunch of my favorite channels because apparently it was just sat in my pocket cycling my connection and flooding the channel with join/unjoins.

That, plus the weird way to authenticate doing /msg Nickserv identify. That might be just how the server I was connecting to was implemented, but it felt fucky.

[mjevans]

That's more an issue with your connection. Mobile devices have really bad connections. IRC was //never// designed with them in mind; they literally didn't exist and were not likely to exist for decades (which it has been).

IRC was designed, mostly, for two types of users: A) Large institution users who had a fixed link to the internet and ran in their shell on a mainframe. B) Dial-in users, who's devices mostly stayed connected, and when they disconnected, usually required manual intervention to get back on.

Anyone, and I mean ANYONE using a mobile phone SHOULD be using a 'bouncer' or other gateway to access a live communications environment. This would be more like use case A where someone has a small agent on a slice of a server they 'trust' and that maintains state (for their client) and stateful connection (for links to other servers and users).

IIRC, Quassel IRC has such a client/server model for the client, there are probably others too.

[zapzupnz]

I guess that's the thing, though. Yes, mobile users should be using a bouncer — but who's going to set it up for them, who's going to host it for free and in a manner that it has guaranteed next-to-no-downtime?

It occurs to me that if IRC networks hosted their own bouncers, but that these bouncers were written efficiently to exchange data directly with the IRC servers' and their database rather than keep individual logs and so on, we might have something close to the "open-the-app-and-see-past-messages-without-needing-to-be-permanently-connected" quality that people have come to expect from instant messengers, Slack, Discord, etc.

(but then you might as well just write such functionality directly into the IRCd)

[caf]

(but then you might as well just write such functionality directly into the IRCd)

Nah, such a thing would make most sense as a separate daemon that uses the server-server protocol to connect to the ircd (ie. it appears to the rest of the network as just another ircd).

It wouldn't be hard to build such a thing, the hard part would be convincing an existing IRC network to run it.

[kuschku]

> That, plus the weird way to authenticate doing /msg Nickserv identify. That might be just how the server I was connecting to was implemented, but it felt fucky.

That's what SASL has been for for over a decade nowadays :)

https://i.k8r.eu/Jr-NBg.png