Our small group uses The Lounge web client for IRC which is a very good PWA, acts as a bouncer, has history search (not unlimited, but pretty long), supports image upload, and basically builds a modern group chat on top of IRC as a backend. We have a few folks who still use traditional IRC clients, but almost everyone just uses the web app. It's not a bad middle ground.
Personally I see that as a feature. Chat is ephemeral, discussions/texts that aren't should be saved elsewhere anyways, otherwise it gets lost with all the other ephemeral stuff.
That’s what I thought until I learned that history really seems to refer to persistence. So if you’re not connected, you won’t get messages, even after you reconnect? For many that’s not very useful.
> So if you’re not connected, you won’t get messages
That's true, if you're not connected, you don't receive messages.
> even after you reconnect?
That's not true, once you're connected, you start receiving messages again.
> For many that’s not very useful.
Yeah, I understand it isn't useful if your perspective is that you should be able to read what happened when you were away. But I guess my previous point is that people shouldn't have to do that, there should be another resource for catching up what happened when you were away, and instead it should be OK to return without having to read through all the messages.
I think this is the number one reason more people don't end up using IRC nowadays. The flow for newer, younger users is:
- Use some software project, want to ask a question, see they have an "IRC channel"
- Hopefully it's a hyperlink to an IRC web chat, or else they'll have to do a lot of research to find out what IRC is
- Join the web chat link, see a room with a list of names
- See no messages
- Ask a question
- Wait ten minutes, get no reply
- Assume it's just dead and leave
The ability to see older messages would be a huge boon, and to see messages between connections as well. I've seen it happen that a user joins a channel, they leave because nobody talked to them, somebody answers their question after they leave, they rejoin, they ask the question again, then disconnect.
IRCv3 has "chathistory" extension. It basically involves combining an IRC network and a bouncer. There are at least two server implementations using it: ergo, which is more or less production ready, but does not have support for multi-server networks, and Libera's sable, which is under (very slow) development.
I wonder why such thing wasn't done 15...20 years ago. Now it seems to be too little too late, with Matrix more or less having been taken the place of IRC.
I guess that because of the "we don't need that here" attitude that ran a lot through the first generation(s) of Internet population.
And it's a shame because with a more dynamic IRC development we wouldn't be in the Slack/Discord silos situation.
Or maybe we would have been anyway because adding more and more complex features to federated, open-protocol systems with many actors involved with different, maybe even competing interests is not easy at all.
But also if I think back at late '90s, IRC had almost the needed critical mass and non-tech users to become something more mainstream...
Never used it, what's so great about IRC? All I know is that's it's self hosted chat with no history retention, which doesn't sound like a solution to anything fancy in particular. The latter bit strikes me as an anti-feature even, if anything.
There isn't much. It's an old protocol, and very simple. But it's simple to the point of naivete and networks only really function with a bunch of ad-hoc extensions on top of it, but there's very little standardisation of those, and that's basically to get things like the concept of having a persistent identity that can't just be hijacked by anyone else on the server, let alone something like persistent message history, media sharing, or end-to-end encryption.
Well, all the stuff you listed is pretty much why it's great. It's almost the simplest thing that could possibly work, and so, it does work, pretty reliably and without fuckups. If you try to turn IRC into Matrix, it just becomes Matrix and you should use Matrix instead - it exists. IRC occupies a particular niche of being simple, but not so simple it doesn't work.
The lack of server-side history is a severely underrated feature, actually. Lack of history means you aren't legally obligated to moderate history (because there is no history) and you aren't legally obligated to have someone on-call to moderate the history. Spam has a lower impact because the spam is not saved.
IRC's severe flaw is not the lack of server-side history, or images or emoji reactions - it's the reliance on constant connection between the client and server. This makes a very bad experience on mobile devices. It works badly on the other side of the equation, too - the online/away/offline social protocol is designed for an era where you log into your computer at the start of the day and shut it down at the end. And in general, the social protocol is from the era where you messages targeted at you are few and mostly interesting, and you may also subscribe to a small number of small social groups or topic subscriptions - none of that is true in the modern social era.
If you want to solve at least the non-social part of that, you end up designing servers that buffer messages on behalf of clients, which is the same as server-side history and creates a legal obligation to moderate it. Bouncers don't have this problem because the bouncer is under the control of the end user, so they can do what they like with it. But bouncers have to run on devices with stable power and internet access.
> Well, all the stuff you listed is pretty much why it's great. It's almost the simplest thing that could possibly work
And that's all well and good, did recognize that, but then isn't it a bit disingenuous to present it as some sort of "real" solution in a thread about a communications technology that aims to cover much more? It's like arguing that Prometheus is the be-all end-all of monitoring, even though the remaining concerns still remain, and are just shoved aside to be some adjacent solution's problem.
> Lack of history means you aren't legally obligated to moderate history (because there is no history)
Is that actually right? Feels pretty suspect to me, you have to hold onto the data at least a little bit to transmit it to all connected clients, being a client-server protocol. I don't think this passes by the courts, not any more than holding onto a few dozen or a few minutes of logs in a non-persistent fashion (i.e. in-memory only) would.
It's not right, there's so many legal contradictions in their statement it's hilarious. And the cherry on the top is that they were recently banned from libera IRC.
"As a rule, strong feelings about issues do not emerge from deep understanding."
> Is that actually right? Feels pretty suspect to me, you have to hold onto the data at least a little bit to transmit it to all connected clients, being a client-server protocol. I don't think this passes by the courts, not any more than holding onto a few dozen or a few minutes of logs in a non-persistent fashion (i.e. in-memory only) would.
It doesn't excuse failure to moderate the service at all, but if there is no chat history, you cannot be excepted to moderate it specifically. Basically, in any even remotely fair legal system, one cannot be excepted to delete something that doesn't exist in the first place.
It's got a simple protocol that's easy to implement.
There's no company who "owns" IRC, as there is with Matrix, and no "reference implementation". Extensions and enhancements are done by consensus of the people writing the clients and servers, there's no central agency that maintains extendion proposals like Python's PEP or Java's JEP. As a result, to be as interoperable as possible, most implementations stick to supporting the existing status quo. If you want to add something new to a client or a server, you run the risk of having that feature only work for a small fraction of users. If it's popular enough, other impementors may choose to make their clients and servers support it.
IRCv3 is an attempt to make collaboration a little more formal, but it's a slow process.
"In fact", yes. But does Element still have an outsized influence over the foundation? Just last month the foundation posted a bit of a defensive blog about how "open source" they are to clear the air, but as far as I can tell, it appears that a majority of the foundation "Spec Core Team" are Element employees. I can't strongly back that up since the page that lists the members doesn't say who they're employed by, so I'm guessing based on what their linked GitHub profiles show.
from memory andrew & uhoreg all joined the team before later applying for jobs at Element - the fact being that if you wanted to be paid to work on Matrix back then, Element was pretty much the only place to do so (being the company formed by the team who created Matrix). I’m not going to fire people from Element or kick them off the SCT and lose their braintrust though.
While long-term chat histories aren't maybe that useful, the problem with IRC is that if your connection dies, you miss all the messages until the connection resumes. That is a big deal on mobile.
Bouncers are an option, but the need to use that sort of extra services will make non-technical users turn away.
Why? With chat history present, reasonable people can search for previously answered questions. Without it, if somebody joins afresh, even if their question was answered just before them, they could have no idea.
IMO it's partly because it's an inefficient platform for storing knowledge, its purpose is instant communication.
If that knowledge is actually valuable, it should be stored elsewhere, in a structured manner. But I get your point, it's better than not having any answer at all.
We ran our co-op on matrix for a while. We switched to discord because onboarding to matrix and making people use this "weird app" was a burden. I would have loved to use IRC, or xmpp, but the way we use these "chat apps" is as the cornerstone of our entire organization, and I couldn't find a good way to get IRC or xmpp to work that way.
For example, we have the "gigs" channel where gigs that are hiring are posted as threads, and people interested reply in that thread asking questions about the gig, putting their names in the hat, getting communicated with about client questions etc. A lot of the information is "duplicated" to our CRM and even our wiki in a little table, but at the end of the day the "chat room" is the hub.
Same for events (which are duplicated to wiki and calendar), announcements (wiki, monthly email newsletter), and long running threads in "general" planning FOSS projects or whatever that people that only check in a couple times a week will pick up again after a gap.
