Phones interrupt the connection every time you close the app, and if there's even a way to avoid this (yes on Android, no on iPhone) the user sees a notification that something is running in the background (fine) and their battery life is 80% less (not fine). The way IRC works is just inherently incompatible with the way mobile devices work, since IRC assumes stable endpoints. And because it's a protocol not a product, this can't be fixed.
Even if a new protocol was created which fixed this, the necessary design change would bring so much baggage that it would become Matrix. To solve the unstable endpoint problem, servers need to store messages until all endpoints retrieve them (which is never, for channels of non-trivial size, since at least one client isn't coming back) or time out (how long do you set that? a week? If you're holding all messages permanently, you might as well never time out clients).
The obvious storage design will hold each channel's messages once, not once per client connection buffer. Which means a lot of things: you might as well send it to new clients when they join; each message will have an ID so you might as well support replies and emoji reactions; you have to moderate it for illegal content; since messages have IDs, you might as well retract moderated messages on clients. At the end of the design process, what you have is nothing like IRC any more.
I know - I was a longtime IRC user way back when. You're still not quite groking my point. Lemme try and make it a bit more clear:
OP lamented that things like IRC meant that if you weren't always connected, you'd miss messages.
I simply posited, from a philosophical perspective rather than the technical perspective you are focused on, that it's OK for us to not be connected all the time. That not everything we miss is as important as we feel it might be when we think about missing out. That the truly important details will make their way to us one way or another.
No, OP lamented that a "connection interruption" means you miss messages. You were participating in a conversation, but you don't receive the whole conversation because your connection was interrupted. It's much worse on phones, because your connection is interrupted every time you look something up on the web, check the weather, send a message on another app, or anything else.
>No, OP lamented that a "connection interruption" means you "lose" messages. You were participating in a conversation, but you don't receive the whole conversation because your connection was interrupted.
Again, I know this. And please don't mis-quote OP, they clearly said "miss", just like I said.
I've told you twice, now, that you're focusing so much on the technical aspect of a connection that you are completely missing the philosophical idea I have very clearly, also twice, suggested. How IRC works, on mobile and on desktop, is not the point. I don't know how else to explain myself, so I'm gonna move on. Hope you have a pleasant day.
Edit: For posterity's sake, OP's quote at the time of this this post is...
>... if you have a connection interruption you miss messages.
Even if a new protocol was created which fixed this, the necessary design change would bring so much baggage that it would become Matrix. To solve the unstable endpoint problem, servers need to store messages until all endpoints retrieve them (which is never, for channels of non-trivial size, since at least one client isn't coming back) or time out (how long do you set that? a week? If you're holding all messages permanently, you might as well never time out clients).
The obvious storage design will hold each channel's messages once, not once per client connection buffer. Which means a lot of things: you might as well send it to new clients when they join; each message will have an ID so you might as well support replies and emoji reactions; you have to moderate it for illegal content; since messages have IDs, you might as well retract moderated messages on clients. At the end of the design process, what you have is nothing like IRC any more.