I'll be tarred and feathered for saying this, but every time I see a modern chat app I pine for the days of ICQ (as it looked in the 90's).
It had a UI I prefer over anything since - compact, comparatively unobtrusive, information-dense, and fast. I could port my full chat history around with me between machines, and also search it reliably (no vanishing scrolling or lazy-loading handicaps). And it was handy you could advertise different presence states to different people/groups.
Discord is incredibly noisy and information-dense and while maybe not for "normies", it’s definitely not just IT guys using it. Though I wonder how many people actually like to use it.
Does IRCv3 need new leadership to continue to drive it forward? Over at Parley/Ahoy (https://git.mills.io/prologic/parleyhttps://git.mills.io/fastidious/ahoy) we've managed to create a federated decentralized IRC chat experience with a Discord/Slack-esque feel but true to both IRC / IRCv3 (Ahoy being a fully featured IRCv3 client).
Rather than claim a Discord-esque feel, you should point out the features you're referring to explicitly. Discord is infamous for its absolutely awful UX and hostility to open source ecosystem. I'm sure you're referring to neither of those aspects, but consider that those reading your reference might be entirely unfamiliar with the (presumably) positive aspects that you're actually imitating.
You are right. To be perfectly honest, the only thing I took from Discord at all (it's UI is generally awful yes, I agree!) is the support for multiple servers. But now that I think about it some more, that's not really even a unique feature.
Anyway, you are right. But that's more about Ahoy and less about Parley. Parley was just answering the question of "What if IRC was federated, and what if it borrowed some ideas from Salty.im -- DNS discovery + WKID".
IRCv3 isn't a corporate body, its a semi-formal group of IRC developers. There's nothing prohibiting you from proposing protocol extensions if they are within the scope of the working group.
parley and ahoy both look quite interesting!
Retrofitting irc into a real federated protocol is cool.
Also like the idea of picking up discords ui/ux. How did
you manage to get avatars for ahoy? Is there a ircv3 protocol
i missed?
It's part of the IRCv3 Metadata spec: https://ircv3.net/specs/extensions/metadata -- It just isn't very well documented or prominently displayed on the spec's page(s) I think. Took me a while to find it too.
If you look at "old" internet: fidonet telnet bitnet ftp fsp wais netnews whois++ gopher relaynet ... i mean irc is one of the only ones that is still used, and mostly as it was 35 years ago. Pretty impressive.
People love knocking on IRC but people are still on it, still using it...
But, seriously, that got me curious. There are many protocols from that early era that are still with us today. NTP, DNS, SMTP, IMAP, BGP, SNMP, NFS, ICMP. If you allow the 1990's as counting as "old" we can add SSH and SSL, DHCP, LDAP.
Actually, its just inertia and lack of reliable forum hosting,
the actual "killer app" that replaced volatile and unarchivable
chat content, but no one learned from it and people flocked to Discord,
which is even more hostile to archiving/scanning chat history.
I am starting to wonder is archiving or scanning history even possible with how hostile internet has become. Especially when so many tech companies will scan and download same content countless times without single care of damage or cost the cause...
Just imagine hosting that history on your instance for users and then some vibecoder without care in his work starts scanning it automatically every 5 seconds just in case it might have changed...
There is still a niche community of people running Gopher servers. I wrote a small basic implementation of a Gopher server in Python before for fun once and it hosted a Gopher hole for a few years. I doubt even one person actually looked it at besides me, but the RFC is simple and can be implemented pretty fast.
Yeah, but the major upgrades for things like telnet and ftp were adding appropriate encryption layers and improved authentication to include things like certificates. IRC shoehorned those into the connections awkwardly but it's still not often mandatory and registration is painful.
Also usenet is still very popular but mostly used for file sharing.
I don’t believe it was or continually is limited to text only, but I do believe we had netiquette back then which helped to reconsider spamming internet with media and other decorators, only to have it all forgotten 72h later
This, which is not uniform across servers, and has more work if you want to do certificate-based auth. Additionally getting a nick cloak is good opsec and also extremely not uniform.
They are not confused. A lot of companies still use FTP internally and for B2B. Many people would be very uncomfortable if they knew how much companies including banks, payment systems, etc... and governments still depended on FTP and clear text authentication. That's even before broaching the subject of which of the applications and daemons in use are being actively maintained.
Hosting files to be downloaded via web browser isn’t what it’s useful for. If you’re going to do that, you might as well use… a web server.
FTP is useful for bidirectional file exchange over the Internet. There are other protocols, but they all have drawbacks. SFTP can be used for similar functionality, but it requires users to have SSH access. SMB and NFS don’t really work so well over the Internet and are a pain to configure for multiple users. For setting up accounts dedicated to transferring files, you really can’t beat FTP (or really FTPS, which is just FTP over SSL).
Fair point, but I would assume the AWS S3 by itself is bigger than the FTP/SFTP traffic globally including banks. No idea if it’s true, and I’m not sure we can get reliable stats on this
I thought of that ... you could put it in the list but I wouldn't unless you're talking cron. I mean when I started it was like mail bob@froggy.ucla.edu and bob would open up pine or emacs and not get any spam or have to do anything crazy and we'd have a conversation.
that modality is long dead. we still have email but it's not that same ... I however could take mirc from like 1995 and still use everything.
I think the main problem with IRCv3 is that there are a million optional extensions (see https://ircv3.net/software/clients for a feature support matrix of popular clients)
This can get especially confusing when people on different clients have divergent views of the same conversation. e.g. some can see the emoji reacts, others can't. some can see "replies", others can't.
Emojis and reacts are the only extensions that can cause people to have a meaningfully different view. It's part of why it took so long to ratify replies, and reacts still are not ratified.
We're also discussing ways for servers to provide a fallback to clients which don't support them.
Wow that is hilarious. This kind of fragmentation pretty much guarantees failure. I'm pretty sure it's what killed Thrift. See their similar "don't use this" table:
Makes me wonder if moving away from discord back to IRC would be a fun move. But I think we'd miss mobile access and accounts on different devices maybe? Any thoughts?
I consciously use IRC like that: I don't have a bouncer, and connect only when I feel bored and want to see what is going in some channels (nowadays mostly just #emacs on Libera). I can only follow the conversation when I am online and there, and when I leave there is nothing to catch up to. In some sense it is like a digital third-space as oppose to a permanent dual presence that I have to share my attention with. Depending on your use-case this is not ideal, but for me it is a nice, relaxing addition to a lazy weekend evening when I have nothing better to do.
IRCv3 gives you all of that, and I'm working on an ircd that has builtin support for multi-device access & chat history (which covers mobile between the two --- there are improvements you can do on top of that, but those two are kind of the foundation).
I'm also extending it with support for Discord/Matrix/etc-esque communities (in a 100% standard-client-compatible way).
It’s just they need a bouncer (an always online irc server you run) for things like push notifications (and chat history on servers without the chat history extension).
Bouncers (and some IRC v3 extensions on newer servers) allow you to be logged in to the same account from different devices.
I’ve also had some fun writing a bridge from discord to irc for some personal discord servers (but it uses some account impersonation hijinks that make it impractical for other to use).
IMO those are the main reasons IRC isn't still used. It's basically only usable on a desktop or always-stationary laptop, or with a bouncer which is obviously expensive to set up and doesn't provide a good user experience.
VoIRC is a joke project. It encodes your voice to base64 and sends that to an IRC channel at a rate that would get you kicked off most servers for spamming. Saved you a click.
Slack is a very bad that is super slow no matter what time of day I use it. It completely locks up on a spotty network. Discord works way better and their voice chat is several leagues above.
Very bad is pretty harsh for the possibly least bad chat app that I have used. I don't like the centralization on Discord but the reason it is popular is because their app is better than the competition.
Yes, but compared to "modern" apps IRC is very rudimentary and you would not get messages if you "close the app". You always have to run some secondary infrastructure like a bouncer to get offline messages or see what happened while you were away.
I know that's not the fault of the protocol itself, but that's always one of the biggest hurdle for IRC adoption when everyone is used to just open apps and see the full history at all times.
The protocol needs ugly extensions to have a variety of devices plug into the same user account. For me back in the day this was an ssh session running the IRC client in a screen, and it was no worse than whatever else was available.
Just yesterday i was working on my game engine for the original Xbox using the open source NXDK kit (which is much lower level than the official XDK) and i finally, after literal years, managed to find and fix a couple of bugs that caused flickering (much more obscure than you'd expect and didn't show up even in the emulator).
So i decided to share it with a couple friends and retro enthusiast communities on Discord. I took a video capture of my engine working, showing the 3d rendering, audio, video, etc with an Xbox->HDMI->USB capture chain. Then attached the file on Discord's input field and posted it (i have a tab with the web UI pretty much constantly open in Firefox). People weren't around at the time but some saw it today and commented while i was sleeping (with my computer off).
Last time i checked, this wouldn't be possible with IRC because:
1. There is no video (or any other file) host on IRC servers.
2. IRC discussions are ephemeral, you either need to be online all the time or setup some sort of proxy that keeps the discussions around while you or others are away (or do what i used to do 15+ years ago - run a terminal-based irc client in a screen session in a VPS :-P).
AFAIK #1 is still impossible and #2 is an optional extension (that i've never seen in real life). Meanwhile i can now connect to a new Discord community and not only not worry about losing any messages while i do other stuff (i often check what people have talk about in Discord since my previous "visit" to be up to date) but also search what people talked about previously - e.g. did anyone brought up some XYZ topic i want to talk about?
IME the above two (also add images and audio to the mix - in two of the communities i'm in there are people who post WIP music they make) are basically 90% of how i see people use Discord: they post something (very often media-based) and very often others see/respond to it in their own leisure much later (in some channels people even live on different timezones so they can't do otherwise).
TBH nowadays if i wanted to set up some community in a self-hosted manned and wanted to stick with open stuff, i'd probably use RocketChat or something like that (Godot uses a self-hosted RocketChat instance that while a bit more janky than Discord, it seems to provide pretty much the same features i mentioned above).
You can use a bouncer on IRC to retain messages while you were offline. In reality, it's the same with every other network: you need a server which receives and retains messages while you're offline.
With WhatsApp, Discord, etc, that server is provided by Facebook, Discard respectively. With XMPP, Matrix, that server is the instance in which you have an account or where the channel is hosted.
With IRC, you use a bouncer. What makes IRC unique is that a bouncer is _optional_. You can even join a channel without an account and without a server which keeps logs while you're offline. This ephemeral level of joining doesn't exist in WhatsApp, Discord, XMPP, Matrix, etc.
And, btw, this is not a new thing: I first saw bouncers 15 years ago and they weren't even new back then.
I know there are technical ways to work around IRC's limitations, my point is that their mere existence adds more friction to using IRC so people move on to more frictionless places - and with chat apps being fundamentally social, that friction affects people who don't even mind the frictions themselves but their peers do (though personally i do mind these frictions - i do not want to bother with hosting anything or setting up bouncers or anything of the sort, i just want to pop in a channel, see what people were discussing, talk with whoever is there and/or share some of my own stuff and that's it).
Concord channels on Nostr (https://concordprotocol.org/clients/) are handy for avoiding the centralization and privacy issues of Discord while also avoiding the reduction in asynchronous and media-enhanced functionality you'd get with IRC.
That said I can't say it's hard to just run irssi inside of tmux and attach/detach as necessary remotely. Nor is it hard to throw my media I'm sharing onto a web server. But yes, you do need to mix and match your utilities, rather than have an all in one package.
I do often enough find this to be more of a feature than a bug -- being stuck with Discord's UI is gross, but the network effect does have me continuing to use it for some groups.
It isn't hard, as i wrote i used to run irssi in screen back in the day when there wasn't another alternative, but that required me to have a VPS (i don't nowadays and i don't really want one because i don't want to bother with the admin side of things) and it is extra friction - and that is for someone like me who already has the knowledge to do it. For most people it is an insurmountable obstacle.
I think you underestimate how hard it really is. I don’t think anyone I know who isn't a professional programmer (and some who are) would have found either of your examples easy.
The way some of us operated back in the day was to link to a forum post with a video upload or a chan board with a video upload from IRC. IRC was ephemeral, light-weight, fast and forums, chan boards were the semi-persistence, long enough for the majority of the intended audience to download. Some still do this today. [1]
> they post something (very often media-based) and very often others see/respond to it in their own leisure much later
who pays for the storage to keep the file on a computer somewhere, and the network to serve the file to the internet indefinitely? in Discord's case, it's the users
usenet iirc tried to do a sort of "torrent" the data across enthusiasts' / participants' computers?
What you are describing here is microblogging like Twitter or Instagram, not using a chat to do chatting. Chatting, by design, is ephemeral and text only.
And yet that is how people use Discord - or more precisely, a mix of the two in the same interface. I think telling people they're not supposed to do something they find working is always losing battle.
How? From a quick search don't see anything in the spec about files or images. The closest i can think of is attaching metadata (which is a draft), but these are meant to store utf8 strings and i doubt a base64 encoded video is what the writers of the spec had in mind.
I have been using SourceHut’s IRC client to access it for a while, but never quite found a good iOS client, since Goguma is just the Android client compiled for iOS.
I wonder if I can find the time to build a native iOS IRC client that follows Liquid Glass, and works as well as Goguma. Not many people would use it, but it’d scratch my own itch, as they say.
The protocol is so simple[1] that it shouldn’t take that long or be that hard[2], I think.
I've been building my own (native) mIRC clone for MacOS as a side project, exactly on the scratch my own itch kind of thinking! :)
Didn't really look into iOS though, I'll have a think...
So far:
- Swift 6/AppKit built with SwiftPM only, no Xcode project. As a stack of modules.
- The default behaviour is native window(s), but have a classic MDI frame (with child windows inside one main window) that I really enjoy playing with and debugging.
- Behaves "the mac way" (menu bar, text editing, scrolling, full-screen, dark mode, VoiceOver), and anything that belongs to mIRC behaves the mIRC way. Still lots of rough edges though.
- Conversations are tabs in one shared window, the tab bar acts as mIRC's switchbar, the treebar becomes a sidebar. DCC transfers get their own standalone windows as I felt that makes it better as p2p.
- The options, defaults, and menus are an exact copy of mIRC 7.85 - I'll evolve it after "finishing"
- Only the top UI layer touches AppKit, so the parts that have to match mIRC exactly can be tested headless in CI.
- The IRC protocol, session state, mIRC formatting, a mirc.ini-compatible config, a scripting interpreter that copies mIRC's evaluation model (PCRE2 tuned to behave like mIRC's PCRE 8.45), DCC, and the display format strings are all pure Swift.
- Some decisions go beyond mIRC to fit MacOS: an untrusted server certificate is asked the user and pinned, never just trusted. Router port mapping uses MacOS's own port mapper. And also created a few new pixel icon sets I haven't fully decided on.
I didn’t, indeed. But I just looked and didn’t quite like the design, so it doesn’t seem to be what I’m looking for.
Still, better than Goguma for iOS as far as design goes. I wonder how the features compare through, as Goguma is the gold standard, akin to Conversations for XMPP.
Many GUI IRC clients do image / video embedding, even 10 years ago. Voice chat / video / screenshare is probably not a good fit unless you run some kind of secondary infrastructure like Jitsi and make it look like it's part of the client. Doesn't seem like a great fit though.
Yeah it'd need to be some kind of secondary infrastructure - I don't see it being part of any official IRC spec any time soon. But it would absolutely make IRC more appealing to the "average" user.
I like IRC, and I am online all day on various servers, for nostalgia reasons mostly, but I think everyone knows it's dated, had its time and will slowly fizzle out if we like it or not.
I think the main problem there is that there's not really any motivation to build that on top of a simple protocol like IRC. The strength of the protocol is that it's distributed, easy to understand, text based and lightweight and I'd guess most current IRC users are people who use it for a very long time already.
Tucking all these mainstream features that people are used to this days to get feature parity with any other competitor (Slack / Teams / Discord / Matrix etc.) will not make IRC more popular, it will make the protocol more complicated and fragmented.
I've ended up managing to vibe an IRC client for Twitch over the last couple of weeks to make following the sometimes flood of the [Hasan] 'Piker Broadcasting Service' stream chat a bit easier;
Some of the actors that are listed on that page already implement many of the v3 features (Like https://www.irccloud.com), so it's not really something that will come with a big bang and we have to wait for a release, it's just that not all clients support it yet.
I know, but it doesn't seems to be in the RFC yet. RFC creates specs and agreements between the protocol and it makes it officially acceptable for clients to start consider respecting it.
I'm running a Matrix server using https://github.com/matrix-construct/tuwunel as an alternative to IRC, but I missed the lean-and-mean of IRC since Matrix is full on event driven delivery like XMPP/Jabber.
IRCv3 are the consensus-based standards body for modern IRC and has ratified the WebSocket spec. Its very unlikely there will be another IRC RFC because getting anything through the IETF is a bureaucratic nightmare. I was a reviewer for the draft IRC-CTCP RFC and it eventually died because the IETF wanted external reviewers who didn't work on the spec and that just didn't exist.
I've been using https://www.irccloud.com for years, it takes care of all these things and also has an app / push notifications. It's still IRC, but it takes care of a lot of the annoying parts of it that made it feel dated.
I never worry about presence in any form of chat. I don't care if people are there when I message them; it's up to them to pick up my messages at their convenience.
Some never left. Notoriously, some bigtech companies have an internal IRC network for tech discussions because that's one communication system that you can rely on to stay up even during catastrophic outages.
Go linger in the ircv3 channel for a week or two, the answer is yes.
Mostly complainers who would rather see IRC stay the same. Right now one of them is complaining the author is a vibe coder, as if that somehow makes the critique that IRC continues to be far behind everything else less real.
I largely credit mIRC for getting me into computers and programming. But I haven't used IRC in a decade... I wonder if kids these days even know what it is.
IRC was great. But I don't think it can bounce back with the alternatives that we now have. A focussed effort to get Matrix working, or any of the open source alternatives would be better. Of course, people invest their time in what they think is fun and that is fine. But the already existing alternatives provide what people need and want today, so IRCv3 will have it infinitely harder.
At what point do we say matrix isn't going to work? It's been like this for years. It's so overengineered on an immutable chat history on a blockchain it has crossed the line into "way too expensive to run and maintain for streams of cat pictures and memes". Worse is better.
I don't get this, it is working. It's largely replaced IRC in open source spaces. It's not going to penetrate the mainstream but it's fine for what it is and people do use it all the time.
People have different definitions for "working". I assume that the people who claim that Matrix doesn't work are the ones comparing to alternative commercial solutions and all the polish that usually accompanies those.
A decade ago Moxie Marlinspike argued[1] that to develop Signal more quickly, he and his team could not be distracted by federation. At the time I wasn't sure what to think, but it does seem that the effort level of using the integrated approach of client/server/protocol may just logistically be easier.
I wish IRC supported images. It's weird that to share a screenshot I need a chat platform that also support VOIP when I just want to paste an image in the chat.
I built a terraform based box that runs ergo ircd with The Lounge as a front end. So basically irc3 as an app server, but you can still federate where needed. Works great. Cheap, performant, I can integrate services into it without all Slack’s bullshit.
I can't be bothered to sign up for both libera and oftc. When everything was on freenode, you didn't have to jump through any hoops just to ask a question.
It had a UI I prefer over anything since - compact, comparatively unobtrusive, information-dense, and fast. I could port my full chat history around with me between machines, and also search it reliably (no vanishing scrolling or lazy-loading handicaps). And it was handy you could advertise different presence states to different people/groups.
In other words, designed by IT guys. And a reason (among many others) normies would never get on board. Not saying I disagree personally.
Anyway, you are right. But that's more about Ahoy and less about Parley. Parley was just answering the question of "What if IRC was federated, and what if it borrowed some ideas from Salty.im -- DNS discovery + WKID".
I've set up an ergo^1 server for experimenting. Channel history is currently in draft stage; and maybe it will be forever.
If any of you want to drop by for some reason and want to try it out: #hn on exp3.irc.basilikum.monster:6697
See here for a list of IRCv3 capable clients (draft/chathistory for history support): https://ircv3.net/software/clients
[1] https://ergo.chat/
People love knocking on IRC but people are still on it, still using it...
But, seriously, that got me curious. There are many protocols from that early era that are still with us today. NTP, DNS, SMTP, IMAP, BGP, SNMP, NFS, ICMP. If you allow the 1990's as counting as "old" we can add SSH and SSL, DHCP, LDAP.
Just imagine hosting that history on your instance for users and then some vibecoder without care in his work starts scanning it automatically every 5 seconds just in case it might have changed...
More illuminating: To what (relative) extend? And what's the trajectory?
Looking at Google Trends: https://trends.google.com/explore?q=%2Fm%2F03t2s%2C%2Fg%2F11...
Also usenet is still very popular but mostly used for file sharing.
FTP is useful for bidirectional file exchange over the Internet. There are other protocols, but they all have drawbacks. SFTP can be used for similar functionality, but it requires users to have SSH access. SMB and NFS don’t really work so well over the Internet and are a pain to configure for multiple users. For setting up accounts dedicated to transferring files, you really can’t beat FTP (or really FTPS, which is just FTP over SSL).
that modality is long dead. we still have email but it's not that same ... I however could take mirc from like 1995 and still use everything.
This can get especially confusing when people on different clients have divergent views of the same conversation. e.g. some can see the emoji reacts, others can't. some can see "replies", others can't.
We're also discussing ways for servers to provide a fallback to clients which don't support them.
Then i noticed the horizontal scrollbar :-P
https://thrift.apache.org/docs/Languages.html
I'm also extending it with support for Discord/Matrix/etc-esque communities (in a 100% standard-client-compatible way).
It’s just they need a bouncer (an always online irc server you run) for things like push notifications (and chat history on servers without the chat history extension).
Bouncers (and some IRC v3 extensions on newer servers) allow you to be logged in to the same account from different devices.
I’ve also had some fun writing a bridge from discord to irc for some personal discord servers (but it uses some account impersonation hijinks that make it impractical for other to use).
I know that's not the fault of the protocol itself, but that's always one of the biggest hurdle for IRC adoption when everyone is used to just open apps and see the full history at all times.
So i decided to share it with a couple friends and retro enthusiast communities on Discord. I took a video capture of my engine working, showing the 3d rendering, audio, video, etc with an Xbox->HDMI->USB capture chain. Then attached the file on Discord's input field and posted it (i have a tab with the web UI pretty much constantly open in Firefox). People weren't around at the time but some saw it today and commented while i was sleeping (with my computer off).
Last time i checked, this wouldn't be possible with IRC because:
1. There is no video (or any other file) host on IRC servers.
2. IRC discussions are ephemeral, you either need to be online all the time or setup some sort of proxy that keeps the discussions around while you or others are away (or do what i used to do 15+ years ago - run a terminal-based irc client in a screen session in a VPS :-P).
AFAIK #1 is still impossible and #2 is an optional extension (that i've never seen in real life). Meanwhile i can now connect to a new Discord community and not only not worry about losing any messages while i do other stuff (i often check what people have talk about in Discord since my previous "visit" to be up to date) but also search what people talked about previously - e.g. did anyone brought up some XYZ topic i want to talk about?
IME the above two (also add images and audio to the mix - in two of the communities i'm in there are people who post WIP music they make) are basically 90% of how i see people use Discord: they post something (very often media-based) and very often others see/respond to it in their own leisure much later (in some channels people even live on different timezones so they can't do otherwise).
TBH nowadays if i wanted to set up some community in a self-hosted manned and wanted to stick with open stuff, i'd probably use RocketChat or something like that (Godot uses a self-hosted RocketChat instance that while a bit more janky than Discord, it seems to provide pretty much the same features i mentioned above).
With WhatsApp, Discord, etc, that server is provided by Facebook, Discard respectively. With XMPP, Matrix, that server is the instance in which you have an account or where the channel is hosted.
With IRC, you use a bouncer. What makes IRC unique is that a bouncer is _optional_. You can even join a channel without an account and without a server which keeps logs while you're offline. This ephemeral level of joining doesn't exist in WhatsApp, Discord, XMPP, Matrix, etc.
And, btw, this is not a new thing: I first saw bouncers 15 years ago and they weren't even new back then.
That said I can't say it's hard to just run irssi inside of tmux and attach/detach as necessary remotely. Nor is it hard to throw my media I'm sharing onto a web server. But yes, you do need to mix and match your utilities, rather than have an all in one package.
I do often enough find this to be more of a feature than a bug -- being stuck with Discord's UI is gross, but the network effect does have me continuing to use it for some groups.
[1] - https://altchan.org/sh/8
who pays for the storage to keep the file on a computer somewhere, and the network to serve the file to the internet indefinitely? in Discord's case, it's the users
usenet iirc tried to do a sort of "torrent" the data across enthusiasts' / participants' computers?
Ircv3, the thread title, supports file sharing
I wonder if I can find the time to build a native iOS IRC client that follows Liquid Glass, and works as well as Goguma. Not many people would use it, but it’d scratch my own itch, as they say.
The protocol is so simple[1] that it shouldn’t take that long or be that hard[2], I think.
[1]: Which is the beauty of it, ofc.
[2]: Famous last words.
Didn't really look into iOS though, I'll have a think...
So far:
- Swift 6/AppKit built with SwiftPM only, no Xcode project. As a stack of modules.
- The default behaviour is native window(s), but have a classic MDI frame (with child windows inside one main window) that I really enjoy playing with and debugging.
- Behaves "the mac way" (menu bar, text editing, scrolling, full-screen, dark mode, VoiceOver), and anything that belongs to mIRC behaves the mIRC way. Still lots of rough edges though.
- Conversations are tabs in one shared window, the tab bar acts as mIRC's switchbar, the treebar becomes a sidebar. DCC transfers get their own standalone windows as I felt that makes it better as p2p.
- The options, defaults, and menus are an exact copy of mIRC 7.85 - I'll evolve it after "finishing"
- Only the top UI layer touches AppKit, so the parts that have to match mIRC exactly can be tested headless in CI.
- The IRC protocol, session state, mIRC formatting, a mirc.ini-compatible config, a scripting interpreter that copies mIRC's evaluation model (PCRE2 tuned to behave like mIRC's PCRE 8.45), DCC, and the display format strings are all pure Swift.
- Some decisions go beyond mIRC to fit MacOS: an untrusted server certificate is asked the user and pinned, never just trusted. Router port mapping uses MacOS's own port mapper. And also created a few new pixel icon sets I haven't fully decided on.
Still, better than Goguma for iOS as far as design goes. I wonder how the features compare through, as Goguma is the gold standard, akin to Conversations for XMPP.
I think the main problem there is that there's not really any motivation to build that on top of a simple protocol like IRC. The strength of the protocol is that it's distributed, easy to understand, text based and lightweight and I'd guess most current IRC users are people who use it for a very long time already.
Tucking all these mainstream features that people are used to this days to get feature parity with any other competitor (Slack / Teams / Discord / Matrix etc.) will not make IRC more popular, it will make the protocol more complicated and fragmented.
I appreciate its text-only nature and would never want to see image/video embeds and/or voice chat in my client.
https://hasanabi.neocities.org/?theme=nightshade
fwiw, I was logging in with Quassel for several weeks before I started that project, that needs an OAuth token for the IRC login
I'm running a Matrix server using https://github.com/matrix-construct/tuwunel as an alternative to IRC, but I missed the lean-and-mean of IRC since Matrix is full on event driven delivery like XMPP/Jabber.
Mostly complainers who would rather see IRC stay the same. Right now one of them is complaining the author is a vibe coder, as if that somehow makes the critique that IRC continues to be far behind everything else less real.
It's a server side change, robustifying the server-to-server links and its effects on connected clients.
At what point do we say matrix isn't going to work? It's been like this for years. It's so overengineered on an immutable chat history on a blockchain it has crossed the line into "way too expensive to run and maintain for streams of cat pictures and memes". Worse is better.
A decade ago Moxie Marlinspike argued[1] that to develop Signal more quickly, he and his team could not be distracted by federation. At the time I wasn't sure what to think, but it does seem that the effort level of using the integrated approach of client/server/protocol may just logistically be easier.
[1] - https://signal.org/blog/the-ecosystem-is-moving/
So yeah, we are going to have the Dyson swarm before this is done.