Do you really think those "extremely competent and high spirited developers" haven't tried? Not only that there are numerous attempts to extend or replace IRC, but those attempts generally understood what is fundamentally different between an ephemeral room-base chatting protocol and a protocol that allows efficient traversal, aggregation and streaming of possibly large social graph and interactions.
Very incisive. Your post got me thinking: Rather than a federated system like Mastodon, what sort of protocol could (a) function as a temporary, room-based, privately hosted chat, that also (b) encoded the social graph and aggregated interactions in a distributed way that could be polled by any client? It seems like the past 30 years have designed either for the decentralized, chat-first model, or else the centralized social-first model (federated or not). I'm thinking of what an LLM could do in terms of summarizing and compressing both at the client level, so large aggregate searches would know where to look in a decentralized universe of chat rooms to more or less emulate the data-retrieval functionality of a massive centralized social network...
While technically different, relays in the ATProto protocol serve a similar purpose; it can be thought as a materialized view in RDB as far as I understand. So if ATProto proves to be successful in the future, extensions to relays might make that possible transparently. (One big limitation of relays right now is that they have to consume the entire repository at once, making it hard for individuals to host their own relays.)
What about like just readable fragments of materialized views that were encoded into the messages themselves. So that a sharp local context and a blurrier larger context could be reconstructed from any given message. Sort of like a Mipmap. And with maybe 10% of the messages in a thread you could reconstruct a fairly accurate representation of the whole thread, at least good enough to run a search on. Every client could serve as a relay that stored its own threads and a constellation of associated mipmaps, and, if some were missing messages, it would be obvious which other clients needed to be checked for the missing portions the next time they logged on. Old/archaic data could be warehoused by clients that chose to do so. No central servers at all, you just crawl client to client looking for the connections, and build your own graph based on what you're looking for.
