IRCv3(ircv3.net)
ircv3.net
IRCv3
https://ircv3.net/
96 comments
Given that Matrix seems to be quite successful these days, and afaict is basically a next-gen IRC, is there any compelling reason to push IRC?
Because Matrix basically has one decent server implementation and one decent client, both provided by the same company, and even that client is some godawful Element thing. I run a Matrix homeserver and use it daily but frankly, I prefer IRC.
Have you tried the CLI clients like gomuks[0]? They give a very IRC feel to Matrix imo.
[0] https://matrix.org/docs/projects/client/gomuks
[0] https://matrix.org/docs/projects/client/gomuks
> Because Matrix basically has one decent server implementation and one decent client, both provided by the same company, and even that client is some godawful Element thing
This is a fair criticism, but IRC is decades old while Matrix is what, 3-5 years old? Give it time and choice of clients and servers will only improve.
This is a fair criticism, but IRC is decades old while Matrix is what, 3-5 years old? Give it time and choice of clients and servers will only improve.
And by "improve" everyone understands "get more complicated and bloated" :-P
Features desired by modern users have a minimum complexity to them. It's just unavoidable. Classic IRC has many drawbacks and missing features:
- messages sent to you while logged out are lost
- no support for videos, images and GIFs
- (usually) not great support for emoji
- no support for file attachments
- no useful mobile clients unless with support from the server
Yes, those can be considered frivolous features, but they are used by people to express themselves (which is, in essence, what a chat protocol is used for), they are expected because IRC's competition has them, and some of them are an objective usability improvement that I'm not willing to go back on.
- messages sent to you while logged out are lost
- no support for videos, images and GIFs
- (usually) not great support for emoji
- no support for file attachments
- no useful mobile clients unless with support from the server
Yes, those can be considered frivolous features, but they are used by people to express themselves (which is, in essence, what a chat protocol is used for), they are expected because IRC's competition has them, and some of them are an objective usability improvement that I'm not willing to go back on.
A lot of these features are normally handled by other services. So for videos, images, and gifs, these can be represented by a URL that's pasted in the channel that you can view with a web browser.
The advantage of doing it this way actually makes it easier to scroll back in the chat history when you're searching for something that was posted.
The advantage of doing it this way actually makes it easier to scroll back in the chat history when you're searching for something that was posted.
fwiw, these are all addressed by IRCCloud or The Lounge (and some others to varying degrees)
Yes, by innovating and giving people the user experiences they want.
IRC is a joke once you’re used to Slack, especially in an organization that uses it well.
IRC is a joke once you’re used to Slack, especially in an organization that uses it well.
I appreciate having a streamlined chat application, but understand that others feel differently. IRC applications are much better on resource consumption and snappier in my experience, but aren't all that practical on a mobile device.
Naturally, how each of us feels about that experience is subjective. So setting that aside, the part about IRC that I haven't seen handled with Slack is being a one-stop shop. With IRC, I can discover and access multiple communities within a single server at once. The most popular servers can be connected to and browsed with a click in most IRC applications. With Slack, I need to find a project's Slack workspace, request an invitation, then go through the process of adding it to each of my clients. I'd love to see the equivalent of a FreeNode workspace where I can join an OCaml channel and a Ruby channel without going through all of the above and dealing with walled-off communities.
Revisiting resource consumption, I've opted out of communities that moved to Slack because once I hit around 10 workspaces, the Slack app slowed to a crawl and guzzled RAM. To be fair, that's gotten a lot better in recent years, but I still find managing several workspaces to just be too much cognitive overhead. I may only be in one channel on each workspace, but I can't easily switch between them. With IRC, doing a "/join ##ocaml" is super fast, barely consumes additional resources, and adds a new tab to my main interface for fast switching between channels.
Naturally, how each of us feels about that experience is subjective. So setting that aside, the part about IRC that I haven't seen handled with Slack is being a one-stop shop. With IRC, I can discover and access multiple communities within a single server at once. The most popular servers can be connected to and browsed with a click in most IRC applications. With Slack, I need to find a project's Slack workspace, request an invitation, then go through the process of adding it to each of my clients. I'd love to see the equivalent of a FreeNode workspace where I can join an OCaml channel and a Ruby channel without going through all of the above and dealing with walled-off communities.
Revisiting resource consumption, I've opted out of communities that moved to Slack because once I hit around 10 workspaces, the Slack app slowed to a crawl and guzzled RAM. To be fair, that's gotten a lot better in recent years, but I still find managing several workspaces to just be too much cognitive overhead. I may only be in one channel on each workspace, but I can't easily switch between them. With IRC, doing a "/join ##ocaml" is super fast, barely consumes additional resources, and adds a new tab to my main interface for fast switching between channels.
The big thing I miss in IRC is that I can't just open my IRC client, connect to a channel, type a few messages, close the client again, do other stuff, come back a few hours (or even days) later, and see if there are any replies to it.
I know about IRC bouncers and all that, but I don't want to set up a server just for that, and managing them is a pain as well. I know about IRCCloud too, but I don't use chat often enough to justify $5/month (I'm poor, and I just want to chat occasionally).
I don't care much for Slack for many reasons, but at least I can actually use it. I find IRC to be functionally unusable because of this.
From a quick glance, it looks IRCv3 solves this with the chathistory extension/specification.[1] But AFAIK most (no?) servers implement this (yet) and the specification isn't finished either.
https://ircv3.net/specs/extensions/chathistory
I know about IRC bouncers and all that, but I don't want to set up a server just for that, and managing them is a pain as well. I know about IRCCloud too, but I don't use chat often enough to justify $5/month (I'm poor, and I just want to chat occasionally).
I don't care much for Slack for many reasons, but at least I can actually use it. I find IRC to be functionally unusable because of this.
From a quick glance, it looks IRCv3 solves this with the chathistory extension/specification.[1] But AFAIK most (no?) servers implement this (yet) and the specification isn't finished either.
https://ircv3.net/specs/extensions/chathistory
That's fair. Async communication is not its forte. There are definitely times I wish I could communicate with someone that way. Some channels have a logger and that can be helpful. For the most part, I like the "inbox zero" approach. I can hop on and just start chatting and there's no cultural expectation that I've gone through pages of chat logs from the last time I left.
> I know about IRCCloud too, but I don't use chat often enough to justify $5/month (I'm poor, and I just want to chat occasionally).
I'd also add that I've often seen IRCCloud banned from many channels due to extreme amount of spam from their users.
I'd also add that I've often seen IRCCloud banned from many channels due to extreme amount of spam from their users.
I also abandoned Slack completely due to its horrendous performance and UX. I find comments like the parent above you utterly perplexing.
There are Slack gateways that exist for native applications. I currently use a Slack libpurple plugin with Pidgin, and although threading is slightly cumbersome, eliminating Electron and/or a browser has greatly improved my experience overall.
There are Slack gateways that exist for native applications. I currently use a Slack libpurple plugin with Pidgin, and although threading is slightly cumbersome, eliminating Electron and/or a browser has greatly improved my experience overall.
I didn't mind using slack when they had an IRC gateway.
IRC is a protocol
Slack is a product
There is a really big difference
Slack is a product
There is a really big difference
The thing is, I don't want these experiences. Am I allowed to stop having them now? Turns out: Not if I want to keep doing my job.
Burn Slack to the ground is my considered stance at this point.
Burn Slack to the ground is my considered stance at this point.
I use Fluffychat on mobile and Fractal on Gnome. Fluffychat is excellent, but Fractal is still lacking e2ee support (there's a rewrite on the way with support already in place).
gomuks is pretty good these days.
It helps that IRC is extremely simple. Most servers you can connect to and chat using telnet if you're so inclined.
Matrix is pretty simple too; one HTTP hit to send a message; one HTTP hit to receive a message. c.f. https://news.ycombinator.com/item?id=20949477
As others have pointed out, there's also a pretty decent range of very usable "daily driver" clients these days (Element, weechat, FluffyChat, nheko, Quaternion, NeoChat all spring to mind). 2nd generation servers are also progressing well (Dendrite in Go & Conduit in Rust).
As others have pointed out, there's also a pretty decent range of very usable "daily driver" clients these days (Element, weechat, FluffyChat, nheko, Quaternion, NeoChat all spring to mind). 2nd generation servers are also progressing well (Dendrite in Go & Conduit in Rust).
I've been interested in reading more about the Matrix client protocol, is there documentation anywhere? At least as far as sending/receiving text messages and maybe threading.
That linked message has a lot of good information though.
That linked message has a lot of good information though.
Thanks! I did look around the site quite extensively. That page says
> this is specific to a homeserver implementation
which suggests that it's not documenting a Matrix protocol. Unless Matrix has no standardized client protocol? Are all clients going to be homeserver-specific?
Even so I'd hope there's some document that says "Matrix standardizes server-server communication, client-server communication is out of the scope of this standard and is left to individual implementations" or something like that.
> this is specific to a homeserver implementation
which suggests that it's not documenting a Matrix protocol. Unless Matrix has no standardized client protocol? Are all clients going to be homeserver-specific?
Even so I'd hope there's some document that says "Matrix standardizes server-server communication, client-server communication is out of the scope of this standard and is left to individual implementations" or something like that.
no idea who was smoking what when they wrote that paragraph; i've deleted it.
I've done that, but good luck joining a channel and writing a message before you have to answer your first PING and get disconnected again because you didn't respond in time.
Why should I care? I will never be inclined to connect to IMs via telnet. I just want something that works on mobile without holding a connection open and that supports media uploads.
Matrix seems to lack a good high density client. The only one that's really full featured is Element but it's very consumerish and uses lots of screen space. As soon as you bridge multiple IRC networks and have lots of other chats open, the chat list becomes really messy imo.
Element Web has various high density modes including a dedicated IRC style mode which looks and behaves like xchat?
Thanks Arathorn, I've now given this a try. However it's not nearly as compact as I would want. Especially the room list on the left, as it still uses the room avatars in this mode it will only show a pretty small number of rooms there. Making the font smaller won't fix that. When I move everything to Matrix I will have at least 50 rooms open at any one time (different IRC servers, whatsapp bridged, telegram etc etc) and I don't want to scroll too much.
Also, every time I have to expand the "Show xxx more" ones for each section, I can't just scroll to the bottom of the list. So that's an extra click.
When I mean a high density look I mean without avatars etc :)
Also, every time I have to expand the "Show xxx more" ones for each section, I can't just scroll to the bottom of the list. So that's an extra click.
When I mean a high density look I mean without avatars etc :)
Oh it does? I try Matrix on a yearly basis with all the bridges and I didn't see it last year. I'm giving it another try in the next month or so. Last time the bridges weren't stable enough yet. I didn't notice this feature that time. Thanks for pointing it out!
I'd prefer a light desktop client though. I didn't spend much time with the web version, perhaps this is why I missed it. But I will definitely give it a try!
By the way I understand the focus on consumer usability, as it's needed for wider adoption. I'd really love for matrix to become mainstream.
I'd prefer a light desktop client though. I didn't spend much time with the web version, perhaps this is why I missed it. But I will definitely give it a try!
By the way I understand the focus on consumer usability, as it's needed for wider adoption. I'd really love for matrix to become mainstream.
> The only one that's really full featured is Element but it's very consumerish
I heard that server is very consumerish too.
I heard that server is very consumerish too.
A couple of past threads:
IRC v3 - https://news.ycombinator.com/item?id=12671063 - Oct 2016 (217 comments)
IRCv3 - https://news.ycombinator.com/item?id=11005999 - Jan 2016 (77 comments)
IRC v3 - https://news.ycombinator.com/item?id=12671063 - Oct 2016 (217 comments)
IRCv3 - https://news.ycombinator.com/item?id=11005999 - Jan 2016 (77 comments)
[deleted](1)
One of the things I really appreciate about IRC is the raw simplicity of the protocol. I hope that does not get lost in an effort to modernize.
I don't really care much about the protocol myself. I'm never going to be speaking "raw IRC" at any point, so why does it matter? I understand that you want to keep protocol simplicity high to make it easier on implementers, but other than just enough to encourage implementation, I don't see the need. We're talking about human chat applications here. Machine chat can use simpler protocols of course, like a light layer atop MQTT, or the existing base XMPP spec.
Writing bots from scratch in a new language is more fun when parsing is easy.
Yeah but this is such a niche usecase. Also, Matrix uses an HTTP API and almost every language at least has a binding to libcurl, so it's trivial to get something up for Matrix as well. If you're not into the ascetic appeal of writing bytes raw onto a socket, then IRC just seems silly these days.
>> Writing bots from scratch in a new language is more fun when parsing is easy
> Yeah but this is such a niche usecase.
I think the point is that writing anything for anything is simpler, faster, and has fewer dependencies when parsing is easy.
> Also, Matrix uses an HTTP API and almost every language at least has a binding to libcurl.
Certainly there are advantages of using Matrix and it's HTTP compatibility to implement some solutions. However, I can also imagine some projects are best served with a simple protocol with lean libraries that don't incur unnecessary dependencies on HTTP and the related bloat and complexity.
I think the point is that writing anything for anything is simpler, faster, and has fewer dependencies when parsing is easy.
> Also, Matrix uses an HTTP API and almost every language at least has a binding to libcurl.
Certainly there are advantages of using Matrix and it's HTTP compatibility to implement some solutions. However, I can also imagine some projects are best served with a simple protocol with lean libraries that don't incur unnecessary dependencies on HTTP and the related bloat and complexity.
Back when i was in highschool i wrote a few IRC clients just to learn socket programming in Delphi and later C and Java. I always appreciated how easy it is to get a simple client running.
Actually, I have in fact been speaking "raw IRC" quite a few times. Not much anymore but back in the days when working on a new servers it was quite convenient to just telnet irc.x.yz 6667, NICK Hultner, USER Hultner * * * * (don't care for quick sess), JOIN #xyz-help, PRIVMSG #xyz-help Hello, anyone familiar with error Z1 on XYZ?, pong.
That's basically everything you need to know for some basic chat.
That's basically everything you need to know for some basic chat.
I've interacted with IRC servers via telnet a ton of times. But overall I think that era of protocol design is unfortunately long passed (looking at you SMTP)
My dream is we move away from overly complex layers on top of HTTP and move to open simple protocols.
I miss simpler, human readable, conversational APIs like the IRC protocol.
The last time I looked at IRCv3 I was disappointed by how much was an optional extension.
My opinion is that a strong 'minimum' protocol is critical to interoperability and opportunities for federated protocols to function well across providers. I recall that was the main, non XML, reason that XMPP failed. Of course I also dislike XML as a data storage / transmission format.
My opinion is that a strong 'minimum' protocol is critical to interoperability and opportunities for federated protocols to function well across providers. I recall that was the main, non XML, reason that XMPP failed. Of course I also dislike XML as a data storage / transmission format.
IRCv3 is written to be backwards compatible so it makes sense to have a ton of optional stuff - considering it is backwards compatible, everything is optional :-P.
And it makes sense, IRC is already out there and has a ton of servers and clients working, you can't split that community based on the client they're using otherwise you're just creating yet another isolated chat protocol like a ton others before it.
And it makes sense, IRC is already out there and has a ton of servers and clients working, you can't split that community based on the client they're using otherwise you're just creating yet another isolated chat protocol like a ton others before it.
I really want the IRC protocol to decouple its sessions from the TCP connection and move to using HTTP as a transport, even if the only api verb is "send" and the only response is "receive output buffer".
I used to really love IRC, and think it could undergo a resurgence given the right upgrades.
I used to really love IRC, and think it could undergo a resurgence given the right upgrades.
What upgrades do you think should be added? I miss the environment of IRC 25 years ago. Its something that no messenging application has really been able to replicate for me.
At a bare minimum it needs to be redesigned for modern computers. We have left the days where user all use desktops which sit online always and hold an open connection. IRC needs to support something HTTP like with history.
MQTT or another pubsub queue protocol is probably a better choice than HTTP for disconnected operation. Use it over websockets if you want it to go through proxies.
What's the advantage of using HTTP?
I can reverse proxy it, I can dockerize it, I don't have to modify my firewall, I can TLS-SNI vhost it, I can decouple the TLS keys from the daemon process by terminating TLS on a different container, I can connect to it from weird LANs that filter non-HTTP, I can drop the TCP connections from my mobile device without dropping my whole login session, et c.
I don't know what makes http important for reverse proxy or docker. I've reveres proxied and dockerized apps that listen on normal TCP port.
Reverse proxying non-http protocols and preserving the client ip back to the backing service involves a terrible hack called Proxy Protocol that IIRC haproxy invented to work around the fact that TCP-directly protocols don't normally allow you to carry metadata (like HTTP does in headers).
https://www.haproxy.com/blog/haproxy/proxy-protocol/
It's messy. The tooling around TLS and reverse proxying for HTTP is much more common and easy.
https://www.haproxy.com/blog/haproxy/proxy-protocol/
It's messy. The tooling around TLS and reverse proxying for HTTP is much more common and easy.
Indeed, and it's because TCP is not meant to deal with that sort of proxy-ing and framing. HTTP is specifically an L7 protocol and that makes it a good spot to do things like framing and signalling (through headers and such).
Is proxy protocol really a terrible hack? (Ok the part where it expects the header to be in a single packet and have no other data kind of is, but that usually works out ok) It's a way to pass some meta data at the beginning of the session and you can configure it.
Alternatively, if your proxy and origin are on the same ethernet broadcast domain, you could just change the destination ethernet address and resend the packet as-is, or stick it in an IPIP tunnel.
Alternatively, if your proxy and origin are on the same ethernet broadcast domain, you could just change the destination ethernet address and resend the packet as-is, or stick it in an IPIP tunnel.
> preserving the client ip back to the backing service involves a terrible hack called Proxy Protocol
No need for that, there's an IRC extension to indicate the source IP to the backend: https://ircv3.net/specs/extensions/webirc
It's supported by all the major IRCd implementations these days.
No need for that, there's an IRC extension to indicate the source IP to the backend: https://ircv3.net/specs/extensions/webirc
It's supported by all the major IRCd implementations these days.
Whether you are in an enterprise, university, airport, internet cafe, restrictive country etc. HTTP traffic just works.
No one is going to open up non-standard ports especially not for IRC which most people aren't familiar with.
No one is going to open up non-standard ports especially not for IRC which most people aren't familiar with.
Not everything has to run on top of HTTP or use json.
IRCv3 gets a lot more right than wrong.
IRCv3 gets a lot more right than wrong.
If you want adoption within the enterprise then you really need to use HTTP.
And these days even most SMBs are taking network security seriously and blocking non HTTP ports.
And these days even most SMBs are taking network security seriously and blocking non HTTP ports.
So let those who need it use existing HTTP <-> IRC gateways or write their own. IRC is flexible enough to accommodate this which is testament to how resilient and extensible the protocol has proven to be over the decades.
I see no reason whatsoever to make HTTP a core requirement.
I see no reason whatsoever to make HTTP a core requirement.
Which is why everyone uses Slack, Teams etc and IRC is irrelevant.
Because there wasn't enough focus on end user experience.
Because there wasn't enough focus on end user experience.
"Everyone". Obviously not. Having used IRC for 25 years, I'll take excellent SNR over the sort of focus on end user experience you're talking about.
> I'll take excellent SNR over the sort of focus on end user experience you're talking about
The kind of SNR that causes an attempted takeover? As IRC has depopulated it's been increasingly inhabited by a particular type of person and has a particular culture. That's fine, but ascribing some technical superiority to it because of your cultural preferences doesn't make sense. IRC attracts a certain type of user who persists despite its UX; it's not technologically superior. The rest of us who aren't in that culture go elsewhere, to a network that fulfills our needs. Like Matrix (or even XMPP for some).
The kind of SNR that causes an attempted takeover? As IRC has depopulated it's been increasingly inhabited by a particular type of person and has a particular culture. That's fine, but ascribing some technical superiority to it because of your cultural preferences doesn't make sense. IRC attracts a certain type of user who persists despite its UX; it's not technologically superior. The rest of us who aren't in that culture go elsewhere, to a network that fulfills our needs. Like Matrix (or even XMPP for some).
>The kind of SNR that causes an attempted takeover? As IRC has depopulated it's been increasingly inhabited by a particular type of person and has a particular culture.
If you mean anime subbers, 4channers, and the warez/pirate crowd , they've all moved to Discord or Telegram. The only ones left are the technically inclined folk who adopted the platform at its genesis (i.e. #c, #perl, etc.)
If you mean anime subbers, 4channers, and the warez/pirate crowd , they've all moved to Discord or Telegram. The only ones left are the technically inclined folk who adopted the platform at its genesis (i.e. #c, #perl, etc.)
No I mean the technically inclined. Adding a layer of gatekeeping just means folks who are okay with that keeping make it across. IRC has a very particular culture.
You're being disingenuous. IRC has been right at the center of the vast majority of non-enterprise technical communities and especially opensource for the last 25 years.
Say what you will about culture but this is a fact and I don't see it changing. Slack and Teams are gimmicks at best. Matrix unusable for me, every single one of my peers and, apparently, the vast majority of said technical communities that keep their center of operations firmly entrenched in IRC.
Say what you will about culture but this is a fact and I don't see it changing. Slack and Teams are gimmicks at best. Matrix unusable for me, every single one of my peers and, apparently, the vast majority of said technical communities that keep their center of operations firmly entrenched in IRC.
We recently switched to use self-hosted Mattermost plus Matterbridge[1] to connect with IRC, Telegram, Discord, etc. There is also an amazing console client - Matterhorn[2].
[1] https://github.com/42wim/matterbridge
[2] https://github.com/matterhorn-chat/matterhorn
[1] https://github.com/42wim/matterbridge
[2] https://github.com/matterhorn-chat/matterhorn
Note that mattermost by default phones home to a spyware analytics service even when you selfhost it. The env vars for disabling it are hidden/undocumented.
Copy the diagnostics/securityalert env vars from here, as well as the sed lines:
https://github.com/caprover/one-click-apps/blob/master/publi...
Copy the diagnostics/securityalert env vars from here, as well as the sed lines:
https://github.com/caprover/one-click-apps/blob/master/publi...
Mattermost CEO here, thanks for the share out! We're big fans of Matterbridge and Matterhorn as well!
I hope the categories that are already available in the Web client will be available in the mobile [1] and Matterhorn [2] clients too.
[1] https://github.com/mattermost/mattermost-mobile/issues/5387
[2] https://github.com/matterhorn-chat/matterhorn/issues/711
[1] https://github.com/mattermost/mattermost-mobile/issues/5387
[2] https://github.com/matterhorn-chat/matterhorn/issues/711
Weird. I contribute to a lot of open source projects.
Never once used IRC. Discord, Slack, Gitter but never IRC.
And love the idea of Slack being a gimmick.
Never once used IRC. Discord, Slack, Gitter but never IRC.
And love the idea of Slack being a gimmick.
slack has to be the worst 'end user experience' I've had with messaging. The threading is horrible, the client is huge and regularly 'stalls' (garbage collection?), and the voice chat is laggy as all get out. Basically, for large international orgs - it seems to be more trouble then its worth...
about the only highlight is ease of creating bots for monitoring and automation.
about the only highlight is ease of creating bots for monitoring and automation.
This should fix the “broken enterprise network” problem:
https://www.stunnel.org/
Listen on port 443; problem solved until they switch to server allow lists.
https://www.stunnel.org/
Listen on port 443; problem solved until they switch to server allow lists.
Using HTTP would be an absolutely massive improvement for IRC. IRC is essentially useless on mobile without having some man in the middle server to convert IRC to http.
It's even pretty useless on laptops or desktops that aren't always running.
It's even pretty useless on laptops or desktops that aren't always running.
Quassel and the mobile Quasseldroid app fix that and more :) They add a lot of mod cons like infinite scrollback, persistent connection and multi network bouncing with a really good UI.
> IRC is essentially useless on mobile without having some man in the middle server to convert IRC to http.
That's not true. I used HoloIRC client on Android with no problem.
> It's even pretty useless on laptops or desktops that aren't always running.
There is no need to. If it's about talks history, chats are not right tool then, forums are more convenient.
Chats are suitable for casual or urgent instant discussions. In all other cases forums are better because user doesn't have to present during discussion, he can return and comment any time he want.
That's not true. I used HoloIRC client on Android with no problem.
> It's even pretty useless on laptops or desktops that aren't always running.
There is no need to. If it's about talks history, chats are not right tool then, forums are more convenient.
Chats are suitable for casual or urgent instant discussions. In all other cases forums are better because user doesn't have to present during discussion, he can return and comment any time he want.
>There is no need to. If it's about talks history, chats are not right tool then, forums are more convenient.
This sounds like a fox and the grapes situation. You can't see history on IRC so rather than noting the deficiency, you list it as a feature.
As a modern IM user, I am part of many low volume groups and the history is essential as there will usually only be 5 or so messages in the day which I would have just missed if I had used IRC. I agree that history on a fast pace 100 member chat is not so useful but not having it isn't a benefit either.
This sounds like a fox and the grapes situation. You can't see history on IRC so rather than noting the deficiency, you list it as a feature.
As a modern IM user, I am part of many low volume groups and the history is essential as there will usually only be 5 or so messages in the day which I would have just missed if I had used IRC. I agree that history on a fast pace 100 member chat is not so useful but not having it isn't a benefit either.
Many modern IRCDs expose a websocket connection, if that's HTTP enough
Does the web socket let you see the history while your device was sleeping?
irccloud allows this
Not familiar with the service but is irccloud one of those services that sits in the middle and converts IRC to a modern http protocol for your device to consume?
Yes but not only. If you pay for their service It's also an IRC bouncer, meaning you can bring your own IRC client. It'll replay messages for you.
RobustIRC does this: https://robustirc.net/docs/robustsession.html
(Disclaimer: I’m a developer of RobustIRC)
(Disclaimer: I’m a developer of RobustIRC)
This is super cool! Where do you irc?
For what it's worth, we've been throwing around a websocket standard that should be supported across a range of servers. On the decoupling sessions from the TCP connection side, the server that I work on (Oragono https://oragono.io ) does this by default, and I've heard that InspIRCd has plans to do work on this issue as well. Definitely a lotta fun stuff in this area.
Websockets over http over sockets is silly. There's no point in moving a socket based protocol to a websocket; if you're going to change it, make it just use HTTP and skip the terrible hack that is websockets in the first place.
I like oragono and also wrote an ircd in go, and was inspired a bit by some of the project's code.
I like oragono and also wrote an ircd in go, and was inspired a bit by some of the project's code.