[derefr]

IRC doesn't solve those problems; individual users solve those problems on top of IRC (and usually not very well.)

A proper open-ecosystem solution would involve network-level history-storage-and-retrieval nodes (basically archival peers in the IRC protocol), and additions to the protocol to direct archive-access queries to those nodes.

[deckard1]

> A proper open-ecosystem solution

Not sure what you mean by "open ecosystem solution." IRC is literally just a few RFCs, a variety of server software, and a variety of client software. It's as extendable as you need it, and most networks have their own extensions already. Is that not open enough for you?

> IRC doesn't solve those problems; individual users solve those problems

As opposed to...? AI solving them? Do we need a corporation to hold our hand while we solve these issues? I'm not following what you're objecting to here. You're free to write and propose your own RFCs and extend IRC however you wish.

[derefr]

> Is that not open enough for you?

I was trying to contrast with existing solutions—IRCCloud, for example, "solves" the problem of history search by effectively wrapping IRC into a proprietary web cloud service.

By an "open-ecosystem solution", I mean a solution that applies to anyone and everyone who uses the IRC protocol, rather than only for users of some specific client.

I'm not saying IRC isn't amenable to open-ecosystem solutions; I'm saying that nobody has (yet) tried to solve this problem in an open-ecosystem way.

> As opposed to...?

As opposed to network-operators being enabled to solve these problems for users of their networks.

Consider the contrast of POP3 vs. IMAP. In POP3, the tasks of "email storage" and "email search" are left to the user, and often they'll solve them badly (by e.g. setting up direct POP3 connections from several devices to one POP3 account, ending up with random emails living only on one or another device, whichever one happened to pull them.) In IMAP, by contrast, email storage and indexing happen on the IMAP server, and users don't need to worry about it. But, since the solution doesn't involve any proprietary services, users can still "take control" of the process if they want—in this case, by setting up their own IMAP server. They just don't have to do that.

> You're free to write and propose your own RFCs and extend IRC however you wish.

I think we're in violent agreement about that. My point was that nobody seems to want to do that for the IRC ecosystem vis-a-vis network-level message archiving.