IRCv3 Spec round-up
ircv3.net
ircv3.net
Remember back in the day when everything was an open protocol? We didn't use five chat clients -- we used Trillian to connect to all the different networks.
> Clients that supported multiple protocols died for a reason.
Yeah, because everyone moved to closed networks.
As for beeper it seems to lack xmpp support (despite some of the services that they support using it internally). Although I will say that it looks cool.
"Yeah, because everyone moved to closed networks."
This is not how I remember it but let's agree to disagree :p
The main question remains though, what does irc3 offers over xmpp and matrix?
irc3 brings irc up to modern standards so that when are using a combo client, the features you have on the other networks work on IRC too.
This seems backwards, didn't you use Trillian _because_ your friends were using closed networks and you didn't want to run a bunch of clients? I don't really remember anyone rushing to Trillian because it was the best XMPP client it was because it could speak to multiple closed networks. It died because trying to keep up with reliably doing so was a pain, particularly when the normal user moved past only needing plain text IM to work reliably.
It's odd you put Facebook Messenger in the protocol group that killed off Trillian as it has always supported that. When Facebook Messenger launched it was XMPP compatible and nowadays when it has moved to be fully proprietary it has remained supported through reverse engineering (just like most protocols Trillian supports).
That example aside your further examples of "open protocols" Trillian supported are even less open and more hostile to 3rd party clients than Facebook Messenger:
> The "closed" networks that Trillian accessed still used open protocols. But my progression was AIM, then ICQ at the same time, then Trillian which could do both plus the few people on Yahoo messenger and GTalk and IRC
AIM used their proprietary OSCAR protocol, which ironically the "O" stood for "Open" but they never actually distributed a spec/standard and actually went through great effort to prevent other reverse engineered 3rd party clients from being compatible over time. OSCAR had to be reverse engineered no different than (newer) Facebook Messenger or Discord or so on today.
ICQ was where OSCAR was developed (under ownership of AOL). All of the above applies and it intentionally broke unauthorized 3rd party clients many times.
Yahoo Messenger used their proprietary YMSG, had to be reverse engineered, and was often hostilely changed to shake 3rd party clients.
GTalk was better but that's because it was intentionally XMPP compatible. Like I said though "I don't really remember anyone rushing to Trillian because it was the best XMPP client it was because it could speak to multiple closed networks.".
I guess you could throw IRC in as a non XMPP open protocol but, ignoring that these were normally just gatewayed, it doesn't explain either the success or decline of Trillian. All of the supported 3rd party chat clients do.
.
Since the internet became consumer towards the end of the 90s there hasn't been a time the majority of people were on open protocol chat networks or a multiprotocol client got popular without support for popular closed protocols of the day. Many clients and bridges have come but they have all eventually run out of steam trying to catch up to the latest hostile changes or the latest proprietary protocol that is taking off while none have ever supported more than the basic feature set like plain text and maybe images across multiple platforms reliably. Not saying it's impossible or people should be using closed protocols just that's how it's been.
To say closed protocols and clients are a new thing that killed the old multiprotocol apps is false, they started to solve exactly that probably but just ran out of steam. Now Matrix has some of us nerdy folks exited about an easy way to glue such networks together via an open federated protocol (which XMPP folks never really liked doing for some reason) and 3rd party integrations are being maintained again. They are still going to run into hostility and lack of feature parity but as we know from the ~2000-~2010 era it can work okay for plain text if you're fine with the occasional missed message or temporary protocol outages from upstream changes.
We can do both with a single service...
the true problem here is that IRC is long-forgotten by many, completely unknown by most, and those that remain remain because they have a strong attachment to IRC. That strong attachment will make driving a standard forward very difficult, because no two true IRC fans are going to have the same opinions on what a new version should look like.
It's the true fans of open source stuff that hold open source stuff back the most.
I get these now through quassel but it'd be nice to have them in the protocol.
I have a feeling IRCv3 will never be finished though. The activity level is just too low.
Except for the noobs that plonk down a question and leave a minute later.
Quassel is really nice, it's got infinite scrollback, multi-network, GUI configuration that is stored on the server, logs go into a database, and the desktop and mobile clients (QuasselDroid!) are really good. It brings IRC into this century without giving up what makes it so good. Unlike Matrix which is aiming more at the Whatsapp/Telegram/Discord community.
I use both mind you, but I don't integrate IRC into Matrix for this reason. I use Matrix just for the individual and small group chats and Quassel for IRC. Matrix gets too messy when you're on tens of different group chats.
It was the nicest form of instant conversation I've ever had. Watching the blurred text become a message was lovely and every conversation felt snapper rather than anxiety-inducing as you start at the "x is typing" message, instead you just watch the sentance grow, then materialise.
Lots of my early stuff (late 90s and early 00s) has basically vanished from the 'net as well; I know the feeling.
"Bob and Phil are typing..."
"Bob, Phil and 3 others are typing..."
Phil: I'm just walking down a fine wee snicket.
Bob: What's the frequency Kenneth?
Phil: ■■■■■■■
Bob: ■■■
3 others typing...
Though I suppose you could visualize it in the nickname somehow. But I hate the current retrieve trend of "and 3 others". It didn't really tell you anything if one of the other participants is someone you want to know about. Because you still don't know if any of them is typing or not.
If it's important, show it for everyone. Otherwise don't bother showing it at all. But showing it for some randomly picked users makes no sense.
Then again, in practice I found that if more than two or three people are typing at a given moment, it's probably a conversation that's lively enough already, and I'd usually just wait to see what the participants end up writing regardless of who it is. So the value of such a notification is about the same as if the all the typing users were named in it explicitly. :)
Sometimes just the writing is cathartic enough that once you've gotten it off your chest, you don't really need to hit submit.
I also had a limit over 52 chars with elipses to stop walls of text.
I wonder how many other people do this.
thunderous storm of typing notifications blacks out the screen
Still thinks its miles better than slack/skype for inter-office communication(Notice i said communication not app/task-tracking/1001-Things our over-engineered 'chat-programs' provide today).
XChat - Good times :)
PS. Would love to see some benchmarking for a modern-irc-daemon written in say Go or something else with good concurrency primatives. Was quite a issue 'back in the day' the max clients per server.
mIRC... those were the days. Good times, indeed!
Especially when you were running "Kuang 11"[2], which developed from a client script into a shared library, written in some compiler language and offering, itself, a script API, in addition to the client's :-)
I don't know how many times some idiots tried to take over a channel and Kuang 11 (or a sister project, it was, I think, which used the K11 API) reacted so fast, that our clients stood rock solid and could not be flooded, etc.
[1]: https://www.amigaos.net/software/115/amirc [2]: http://de4.aminet.net/comm/irc/KuangEleven3Gm.readme
Minimalist implementations can also cherry-pick newer features they want. For example, this IRC client explicitly says it in its "non-features" section: https://git.causal.agency/catgirl/about/
The second is more green field projects, like the stuff to allow a more web client friendly protocol compared to IRC currently by defining how to use web sockets avoiding the need for stuff like IRCCloud or Mibbit proxying their user's connections. Or chathistory to make it more mobile/not permanently attached friendly.
It's niche is as simple as it was way back when, you can create your own chat server for your community. Instead of having to use Discord, Slack, etc you can create your own and control it fully. While it's possible to do that to this day it's not to the same level it was back in the late 90s for example.
IOW we're stuck with a decaying protocol ecosystem—for messaging, and everything else—until we outlaw surveillance capitalism, which we probably won't do. Email wouldn't be able to take off if it were invented today, because it lets you use it without one company seeing everything. The state of things is really bad. It's a drag on productivity, with endless wheel-reinventing and deliberately-bad interoperability.
The success of slack and the failure of IRC has nothing to do with surveillance capitalism.
The new IRC is Matrix, or at least for now. For me at least, it fullfills the same needs:
- deploy your choice of server-software on your preferred server.
- use your preferred client to connect to your preferred server.
- allow communities to manage themselves in a decentralized manner, without any San Fransisco-based big-tech company imposing their CoC, ToS or view of "diversity" upon them.
And it does so in a way which is mobile-friendly and supports all the "modern" additions to IM which normal people have come to expect. I can't see how IRCv3, if it ever lands, can compete with this. It's years (decades?) behind at this point.
And if it lands a spec which is equally capable as Matrix, how can it ever be compatible with "the old IRC"? Myself, I'm still running my IRC network and servers, but they are bridged to Matrix and I encourage the community to move there too. And thus ends my interest in IRCv3.
All in all, this seems like a lot of spec-work going into a what is surely going to be a doomed venture.
I want to like Matrix, but this is currently the most painful point, for me. There are very few mature clients, so they don't serve as many niches or specific tastes as IRC clients.
> I can't see how IRCv3, if it ever lands, can compete with this. It's years (decades?) behind at this point.
Not sure what you mean by "landing". Many specs are already implemented, deployed, and used in the wild.
> And if it lands a spec which is equally capable as Matrix, how can it ever be compatible with "the old IRC"?
Every IRCv3 spec is designed with backward compatibility in mind, so old clients are not left behind, they just don't benefit from the new features. The main mechanism for this is a capability negotiation when clients connect.
Darn hippies with their inclusivity and community standards!
People like you is why I long left this forum and IRC servers in general. You give the tech industry a bad name.
You might be assuming everyone else has the same relationship with the words that you do and this could be a mistake.
The question isn’t “If this can work with Matrix why not XMPP?”, the question is “Will Matrix have the same issues as XMPP?”
Success is adoption. Enough users to break the network effect.
Signal is currently a good example of roughly the amount of users you need to start breaking the effect. So that's what success looks like. A very low bar version of it.
the main matrix homeserver blocks you from federating with them if you violate their CoC and kicks all matrix users from your room
If you use the main Matrix homeserver and you're in a room hosted on another server when this happens, does your client show a helpful message like: "Sorry, you're not allowed to be in this room any more, because the people hosting the room committed the following thoughtcrime: $REASON"?
I worry that it will instead just look like some generic network error message, with the remote server being tacitly deemed an un-place full of unpersons. Down the memoryhole it goes.
In my opinion that doesn't really matter. matrix.org is "just another homeserver" - it just happens to be one with a large amount of Spaces and rooms, and thankfully federation doesn't orbit around matrix.org nor does it depend on that.
There are plenty of other homeservers which federate with each other quite happily. I've seen some rooms which have a policy of not allowing users with a matrix.org account, because they disagree with the matrix.org CoC/policies/actions, and that's also fine, because the nature of the matrix protocol allows that freedom. If a person wishes to stick with matrix.org, well, they have that choice. If a person has a homeserver which gets booted from federating with matrix.org, that's also fine - the problem will eventually be routed around by federating with plenty of other homeservers. This happens already.
And still no e2ee, after all these years.
But even if they didn't, there would be no reason not to move their public conversations to the protocol that they use for direct messages.
There are (were) many smaller groups that use private channels. It is also how me and my first bf and some of my friends ended up talking.
At the end of the day, even with all problems that exist in TLS implementations, I have a lot more faith in TLS than I do in some college student's hacked together web chat client's e2ee implementation. As for XMPP, just how widely available is OMEMO in XMPP client software? The last time I tried to deal with XMPP and e2ee I was constantly confronted with clients that did not support this or that protocol. I can't speak for Matrix, maybe it "solved" the problem, but as I said if e2ee was not part of the standard from the beginning it is going to be hard to push it out as an afterthought.
Your favorite curve is suddenly vulnerable? Use a library like libsodium which has a solid track record and will be updated to replace the default algorithm if there is a need.
I will take signal's "hacked together" e2ee implementation over openssl.
As for clients without omemo support, I did not have any issue so far.
EsperNet is on the list too. I remember spending a lot of time on there way back when.
Want to just chat? Snoonet, Slashnet, Quakenet.
Want to just chat but want it to be technology focused? Darkscience, 2600net.
This is a shortlist of public networks I can recommend to a new/returning user; there are many smaller networks out there that you might discover organically with time.
Didn't see anything about WebRTC, so no multimedia? I'm fine with that, too. Basic is good.
Now, I am not up to date with modern chat apps, but I'd imagine most of what is out there has everything in this draft and then some. So, why would anyone commit to the protocol besides nostalgia. Not saying it's bad, just wondering
Not in my experience. I would want a new hire to be able to search past history for context and to many businesses like to monitor the chats.
Keep in mind, IRC would generally be hosted by the business themselves so they’d have full access to the data. Why would that business want to hide their employees messages from themselves?
Edit: I found this helpful page on the site describing open participation. https://ircv3.net/participation
Myself I wanted to stay, but he kinda "closed" freenode - you need to register using a web form and access using SASL. Since he dropped the old nick database, you can't use your old nick anymore. I doubt there are many people online there at this point.
So now Libera is what Freenode used to be, nothing more nothing less, only with more well-defined management that learned their lessons about vetting contracts. They're doing a great job at continuing the Freenode spirit and everything is settled back to normal.
Pretty much the best outcome possible from all this IMO.
Ps the sign up form is so un-irc. The great thing about IRC is that you don't need any identity.
Sadly Libera.Chat is only at about half the size [0] that Freenode was. Sure, a lot of those lost will not have been active participants anymore (just keeping their bouncer/client running) but all of them?
I also think this would have triggered people to think "do I actually still want to be on IRC"? Rather than just idling for years.
However I didn't know it was still only half the size. That is much worse than I expected.
I know some of them have moved to other networks, for example the alpine linux team went to OFTC. So part of it is explained by that. Still a split of the community but OFTC is a very similar type of community.
Judging from the statistics, it looks like a significant fraction decamped to OFTC (~10-15k) instead of Libera (~50k).
On the other hand, Discord's UI treats threads as temporary channels, and that works way better because you can actually see the thread as unread or not in the channel and server lists. I really wish Slack would steal this.