IRC v3
ircv3.net
ircv3.net
Developing kiwiirc.com over the past few years to cover many different IRC servers in all different languages and using many different services/auth services has been a real pain. It won't improve overnight but these IRCv3 extensions making their way into many different IRC server projects are really helping to smooth things out.
There is currently a re-write of the Kiwi IRC project to experiment and make use of the entire IRCv3 extension set, along with some other features to make web based IRC clients just as friendly and modern as people expect from messaging applications today. This will be a huge boost to the millions of people using IRC via Kiwi IRC.
IRC is getting interesting again and IRCv3 is up there making a lot of this possible.
Anyway, I strayed off topic. I too am excited for IRCv3 and the future of IRC. I love the protocol, and despite it's drawbacks it serves my purpose well.
And thank you for all your work on KiwiIRC. I love the project :)
I have been running https://github.com/pteichman/cobe for a number of years and once in a lucky while it approaches the sentience of a drunk howler monkey.
>IRC is getting interesting again and IRCv3 is up there making a lot of this possible.
Could you elaborate? What are the most promising things about IRC today? I personally am a huge fan and have been a user for over a decade now. But I do see a lot of underutilized potential.
Probably says more about your social circle than IRC. There's a lot of channels and if hookers and blow are more your speed than say, gentoo, you can certainly find a channel primarily discussing them.
I just believe that even the most benign, non-techy use of IRC poses demands that are incompatible with the vast majority of users today. But that's a strength to me. IRC is filled to the brim with some of the smartest, most creative, exciting people I could think of.
that is all.
see also: DEFCON, HoHoCon, pretty much any alt-Con.
Sounds like nerds and hookers and blow can go together just fine.
I wouldn't recommend it to my friends, who were hard enough to get off WhatsApp and into Telegram at least. To my parents, who have trouble enough running Skype. To the girlfriend, who's happy with Snapchat. IRC, even at the very basic level with a GUI or Web client, demands things from users I don't consider realistic to expect from them.
I'm very happy with it the way it is though. Just saying that I won't waste time recommending Arch Linux as a desktop OS to friends who have trouble keeping a Windows install useable for six months.
???
Could you provide some, I can't think of any.
Also Vector seemed fairly decent (with the small plus of the matrix/vector association). Riot isn't much shorter then Vector, it has violent/negative association, and changing names (unless its a major improvement) seems like a bad idea for a piece of software relying on network effects and trying to become popular.
It's also free software and easy to set up so I encourage everybody to check it out.
I like WeeChat as a client, it's fast and lean and works inside the tmux session that pretty governs my digital life both private and professionally. Alas, it's not always accessible. Getting Putty to reliably work with tmuxed ncurses apps is a nightmare for example, imho.
Glowing Bear solves this brilliantly. It looks great, you get features like inline display of media and is easily secured with certificates from Let's Encrypt.
Thank you, devs. This'll make my "newly discovered FOSS projects of the year" list for sure.
By contrast, if you want to switch off Slack, can you still talk to people who stay on Slack, or do you have to get them to switch too?
I like IRC over Slack for the same reason I like email over Slack: I can just use my client with the interface I like, and the network takes care of getting my message to someone using a different interface, that they like. It doesn't require we compromise on a shared, fixed interface, a la Slack.
Adding tags forced them to increase message length because of how IRC messages are hilariously limited to 512 bytes in all directions. In the existing protocol you already have to guess how long your messages are allowed to be because the server tacks on a prefix to your message before relaying it, which can require it to truncate characters to fit the modified message into the length limit. Having some amount of tags tacked on as well would have made it impossible to guess how much room you had.
Now if they had started with fixing the actual protocol they wouldn't have had to deal with that. Honestly this feels more like a standard "let's add cool stuff" push than intelligent stewardship of the protocol. I guess that is kind of cool too though.
People assume that IRC as a protocol is not fantastically outdated and it's architecture is inherently distributed and fault tolerant. Even if those things are not really true (at least not at the levels that other moder modern systems would be considered at), people hold onto the belief.
Imagine user A negotiates a length fo 1024 bytes with the server, user B negotiates a length of 2048 bytes.
User B sends a message via the server to user A.
What happens?
However reading their site more carefully I suppose their stated goal technically is to only provide extensions to the protocol.
So the situation you describe already happens, user A has 512 bytes to send to the server, but the server has 512-prefix_length bytes to send to B. This is a flaw in the original protocol and the currently accepted solution is to truncate server-side(what to do is not stated explicitly, though it is implied that you probably shouldn't wrap messages). But fixing it is probably out of scope.
(On Freenode and other networks with a similar service, your hostname can be changed by services, but the client is notified of this and can update its knowledge about the prefix).
And how would it be split?
Or should there be a mechanism for reassembling message frames?
Imagine you have a 513 byte tag in a message.
We are working on it but when you have hundreds of different implementations which are all broken in their own way its not as easy as just adding a way to negotiate the length. Extending the length to add an extra 512 octets for message tags was a temporary fix.
>Now if they had started with fixing the actual protocol they wouldn't have had to deal with that.
We HAVE started with working on fixing the protocol. Almost all of the specifications in IRCv3.1 and most of the specifications in IRCv3.2 fix core protocol issues.
Offline messages and simulatnous logins from multiple places are just two features I was missing in IRC and didn't even know till I had them, haha.
But yeah, IRC networks just worked as message broker and not as databases, so I never thought about it.
Well, a native Android client. But other than that, what more could I ask for?
The whole reason the Slacks and Hipchats and Discords of the world exist is that IRC is a terribly limited protocol that many people have tried to hang enhanced functionality on top of and none have succeeded.
Personally, I'm in favor of letting the better product win. IRC has been objectively superseded in nearly every way that matters.
IRC is not a limited protocol. What is happening is that people are using limited computers and networks (smart phones) that aren't capable of the same thing a 1990s computer was.
Let's see, in addition to what's above, off the top of my head:
* Video chat / screen sharing
* Audio chat
* First class support for connectors to external services (i.e. not a fake client connected to each room)
* First class support for permissions, registration, etc (rather than a fake god-client service package)
* REST API
It's a great microcosm of the free-vs-proprietary debate that's been raging so long. Slack is winning the fight because it wins in ways that are visible to everyday users, while not being philosophically better.
You know what else IRC can't do? Be a version control system. And it can't be a webserver, or do GPU accelerated machine learning, or act as a spreadsheet.
As for "First class support" I'd argue that those kind of things make for a less flexible chat system. It's like having a strongly typed classes instead of everything as strings; like Powershell vs a unix shell.
REST API? Ah yes, in 2016 everything needs to be HTTP, I forgot.
I'm very curious how you think user registration and an API make for a less flexible system. What exactly are you wanting to do with Slack that the existence of an API and a registration system prevent you from doing or get in your way of doing?
And considering that Slack is generally accessed via HTTP, it kind of makes sense for it to have a sane HTTP interface, something for which every language has decent tooling for...
Matterbridge connects Mattermost with IRC, XMPP, Slack, Discord, and Gitter: https://github.com/42wim/matterbridge
Chat apps don't magically "just work" - either you run your own infrastructure, or use someone else's.
It works really well and is a cheap solution.
Freenode and Weechat seem to support the changes, but I honestly worry that the protocol ends up more complicated than it needs to be, or possibly more complicated than people can use. Diaspora already provides a lot of what IRCv3 looks like it's trying to do. I guess I'm just not sure what the difference is.
This worked great when people were typically using IRC from their login on a server at their university (and this is also originally why IRC servers used the 'ident' protocol when you connect - to stop you spoofing other users on the same shared system).
It stopped being a viable persistent identity for all users when the @hostname part stopped being persistent - when people started gettting dynamically assigned addresses on internet connections at home.
Please, someone, just offer us an open source slack clone that runs off on a R-pi and has a walk through wizard to enable the 99% of typical install requirements.
Even as someone who works in the industry, I dont have time to learn the bells and whistles that running a chat server requires.
I do agree though that the user experience for my OTR-enabled messengers is shit (especially the "first message not encrypted" problem).
Maybe also backport some features of Slack, like edition of messages (with a flag marking it as edited), or a common way to have plugins/extensions, or tagging links as images.
This works on Slack but only with their client. Use one of the bridges and you have no clue what's going on and they have a centralised system for this. Syncing that somehow across all servers in an IRC network, across netsplits and everything, is far from simple. You'd also need to do this retroactively somehow if a client received a message, disconnects, the message is updated and the client then reconnects, in order to present an accurate history.
> or a common way to have plugins/extensions
IRC already has a way to allow for extensions. Or do you mean client side?
> or tagging links as images
I'm not sure the IRC protocol should care about that at all. It's more up to the client to detect image links and Glowing Bear for example already does and can display them inline.
Yes, it's not simple. But it's not impossible to do. And yes, it might not work in 100% of cases, after netsplits, but so what?
You said you agreed on A
No I edited it later to say that I meant I was in favour of B
Oh, I never saw that edit...
Who speaks about magic?
Just send a message with the original ID and make the difference. Mark it in the UI, and redisplay it.
Also, edits would ruin many of the funny situations encountered on bash.org. :)
It wouldn't have to be complex, either, and it certainly isn't useless (says me and a few other people already!).
Quick example: I recently typed out about 10 long lines of business development chatter in Slack, the first of which contained a list of prospects. I realized I left a few out in my list, and edited the message to add them in. Without editing, I'd have to have either posted the complete list again or added them in as a second comment. Editing the original message is simply a lot less confusing.
With editing if people read the first version of your opening message, you don't know if they saw the edits or not.
I find edits useful for typos/formatting/cosmetics, but I don't ever edit significant information into a previous post for that reason.
I'm not sure why your comment was down voted, but as both an IRC and Slack user, I have to say I love Slack's built in pastebin.
I do wonder though, should IRC evolve to be like Slack or should it evolve idependently? I feel that the new features should be more vital, rather than "neat"... like maybe more focus on privacy and/or anonymity. Undoubtedly, I am just resisting change...
I see chat like in-person communication where editing something already said is impossible.
Once you try it, you never want to go back.
You advocate for privacy, You advocate for openness, You advocate for transparency, You advocate for interoperability, You advocate for host-it-yourself, You advocate for customisability, You advocate for scriptability ...
But then all of a sudden "oh no IRC, not enough colours, geez, running a bouncer, who wants to do it?"
-------
I'd design irc-v3 to be bouncer-friendly, and maybe to integrate some bouncer-y features into IRC servers as well (most IRC servers keep logs anyway)
IRCd developer and network staff member here. Dead wrong. I don't think I've seen a single IRCd that keeps logs, and doing so would make it much more expensive to run an IRC network. Additionally, it would be a huge violation of privacy, and we value our users' privacy. The IRCd only logs server events (e.g. network-wide bans, server connection/disconnection, use of administrative tools) and user connections/disconnections (for anti-abuse purposes).
If network staff have logs of something, it was either because their IRC client was present in the channel or because someone else gave them logs.
Most of my network's servers hang around 2-3% CPU usage and <5GB disk usage, and we'd like to keep it that way because we don't want it to cost a lot to host. We have an average of 1000-2000 users per server.
Yeah media sharing can be done with, what's it called, CTCP? That's just piping stuff through a short message service, like Twitter or DNS. It doesn't properly display media either, but it allows for small file transfers.
And of course scrollback can be done with bouncers. But it's not something I see my mother using. Facebook Messenger is what I see my mother using.
Is there anything new on the website, or it it just being linked again?
If I were to give one piece of advice: forget IRC. If you want to make a free, large scale chat system, just forget you ever saw IRC. There are no solutions in that neighborhood.
Anyway, why isn't this being done through the IETF?
Why don't you send them logs of the conversations?
> IRC (current version) works fine for me. The trick is to front it with ZNC or similar software.
But ZNC actually uses a bunch of IRCv3 features.
All the things you don't think about, and most of the ones you do, work together the way they do because of the IETF.
You see those other things that don't work together? Those are the ones the IETF didn't do.
I asked why this should be done under the IETF? What are the benefits, specific to the IRC protocol, of doing this under the banner of the IETF versus not? What do you believe will be gained by doing this under the IETF?
There's plenty of protocols and technologies that we use today that don't fall under the IETF banner and are plenty successful. The W3C is an organisation that comes to mind for example.
There are plans to contribute an updated base RFC to the IETF in due course though.
"IRCv3 exists and is addressing some of these issues; this is great news and we wish them well. It’s almost a contradiction in terms to get competitive between openly interoperable communication projects - we look forward to increasing the richness of Matrix<->IRC bridges as the project progresses."
Why not merge the two projects or just focus on one? WebRTC seems to be a better protocol right now.
That worked quite nice, for ~15 years, and whole community was created, things worked quite nice, diehard users used BNC and terminals, but lately everyone is switching to Discord.
Main matchmaking is still on IRC, but other sub-groups migrated to discord long ago, and that scares me, because no one at the moment knows what will happen with Discord year or two from now.
However, I don't really understand how reposts work. I always thought that URLs are a unique key.
Is this a way to kind of "retry" them? In this case I'd be curious about how they work.
After a period of time, new submissions are their own post, to allow submissions that did not get visibility have a chance at being seen. This is also sometimes done manually by the mods if they see something particularly interesting that was missed (not sure about the last point though again, I believe it to be true).
Related, I've been working on these sites for a while which I hope can be useful: http://defs.ircdocs.horse/ http://modern.ircdocs.horse/
Still, it's been really interesting to get into. It's nice seeing how things have gone so far and how they're going forward (and digging into the archives is always fun).
Take the "away-notify" extension for example. Without it you would have to repeatedly poll a channel with WHO to see if all users in that channel have marked themselves as away.
They have put lots of pressure on and harassed other developers of clients and networks, sending them patches and infiltrating their devs if necessary, so their ideas are actually implemented.
If you complain about those ideas and specs, they'll tell you to refer to their github issue tracker, but they mostly ignore those who are not part of that core group I mentioned.
A lot of the core group all work on different competing projects, servers and clients, and do frequently discuss any proposal made by anyone if it makes sense.
Historically the IRCv3 project originated at Atheme as a project to bring some extensions to IRC in order to make it more modernized, such as the SASL binding (IRC Authentication Layer). ZNC guys and Atheme guys did not get along because political reasons, so they threatened to fork the project. Atheme decided to spin off the IRCv3 project at that time as it was no longer really interesting to Atheme anyway (IAL was adopted in basically every IRCd and most mainstream clients).
While I cannot really comment on the current managerial processes of the project (as I do not know what internal discussions the technical board has anymore, if any), the technical board allows people to submit things that they know will never ever be ratified, without saying what the outcome will be when it is already known to them, in order to give the appearance that they are an open project. In fact, advising people to not work on specifications that mainstream vendors will not adopt is actively discouraged by the working group, as the image of being open and the appearance of being non-offensive is more important than discouraging people from wasting their time.
As for charybdis (a widely deployed IRC server): we keep an eye on the IRCv3 group and implement things that we find interesting. There is no commitment from us to implement future IRCv3 work just because it is an IRCv3 specification.
As for IRC itself: IRC is a wonderful thing, but honestly in 2016 we can do much better. The backwards compatibility requirement of IRCv3 (which exists because they do not feel they have enough influence yet) is a serious crutch that prevents a lot of potential work for fixing design problems with IRC. The lack of unique identifiers at the client level (other than nickname) makes a lot of things like nickname ownership painful. The overall concept of IRC is a powerful one, but the technical foundation is crap. This is why Slack, gitter.im, etc are kicking IRC's ass right now, and IRCv3 is honestly too little too late for that fight. These services offer easy integration with any type of website and the IRCv3 group is too busy talking about bringing HSTS to IRC. This is a total and complete inversion of priorities verses where they should be.
I do not wish to start an argument over things which are long dead. However, I think it is important to note that the "political reasons" were that you were constantly derailing discussions and threatening people.
I can publish all of my IRC logs if anyone wants evidence of this.
>IRCv3 is an almost closed group of friends, mostly znc core developers
There is only one ZNC developer actively involved with IRCv3 (DarthGandalf) and even they have not been particularly active in the last few months.
>who have decided they can choose what the future of IRC looks like.
We accept any reasonable proposals providing you are willing to provide a strong rationale for it.
>They have put lots of pressure on and harassed other developers of clients and networks, sending them patches and infiltrating their devs if necessary, so their ideas are actually implemented.
No IRCv3 technical board member has ever forced a developer to accept patches. Some people have contributed patches to various IRC implementations in order to improve IRCv3 compliance but those patches have been accepted out of the free will of the maintainer.
>If you complain about those ideas and specs, they'll tell you to refer to their github issue tracker,
We prefer that discussions happen on the tracker rather than IRC as it is persistent and can be referred to in the future.
>they mostly ignore those who are not part of that core group I mentioned.
This is completely false. Please provide evidence of this happening.
How exactly does this work? Someone starts contributing to your project and it's an "infiltration"?
This in combination with the marketing efforts of the IRCv3 group places large amounts of pressure to just accept and maintain the patch in order to ensure that you wind up on their list of recommended software to use, instead of their advocacy of using a different software which has added the patches.
This is how standards get built now. See also: systemd, R6RS.
That’s completely different from the experience I had with them.
NNTP/usenet is a protocol. Reddit is a business.
Email is a protocol. Facebook is a business.
Protocols don't go bankrupt and close up shop. They'll still be around in 10 years.
Protocols don't magically pull the rug out from under you, dictate how you use them, or suddenly change features you want and need without you having any ability to remain on the old system. They don't suddenly up the system requirements or discontinue support for old clients. I can still email from any device I ever could, palm pilot, powermac, whatever. Meanwhile your favorite app is dropping support for Android 4 or whatever 24months after release. Or app xyz no longer works on a 2 year old iOS.
Protocols are something I can rely on. Businesses fly by night. I'm not going to start using Discord now and have it be gone this time next year, I've been using IRC for decades, and I'm going to keep using it. It works perfectly, everywhere. Especially if I have mosh and a server running my irc client somewhere else.
You seem to feel differently. Go ahead, tell me why it shouldn't be the case.
It's not a new protocol.
So I'll reframe my question and ask: Why isn't TLS a base extension?
We strongly believe that the future of IRC is TLS-only.
There have been lots and lots and lots of discussions about that, but considering it’s just an extension to the existing IRC protocol, it’s not that easy.
But it’s easily possible to enforce SSL over IRC already.
IRC was new in 1988. It's 28 years old protocol now.
This is like the email situation where encryption options exist, but it's too hard for mere mortals to use. If it's built into the base protocol then there's a chance that clients would implement the standard and actually use it.
Seriously though, I think this is exactly what is needed for IRC: a facelift. IRC is hugely superior to centralised tools like Slack for obvious reasons. But if people are moving to Slack it's not enough to say they should not do that, but try to actually offer a competitive user experience.
People tend to dismiss web application development for being careless, but at the same time forget that this is what made these clear text fairly rudimentary protocols popular. Until we get encryption built-in, more robust programming languages and figure out distribution on the desktop it's unlikely that the ecosystem will come back.
Even though open source is "cool" now, I can't help but feel it's mostly people working for companies that just want to export their technical debt for free and use open source as a marketing tool.
I think it's more that originally FOSS developers/users were hard-core's who were into the tech and the ideology of 'Free Software'. The user-base now has many people who are into 'open source' for the collaborative (group motivation) and perceived technical benefits at an infrastructure level. It's a benefit because there's more 'free' code flowing around, but the downside is that as soon as a proprietary thing is better the user-base moves to it - they have no link with ideology, they're linked to utility.
Also, I have to get invited, check my email, sign up, and skip the tutorial every time?
Also, in this particular case, Matrix also appears to be a well thought out platform for decentralised communication, one that is likely to be flexible enough to meet the needs of multiple different forms of communication.
Equally out-of-date are the screenshots of the clients on the homepages. I don't think I will ever see an IRC desktop or web client that has decent UI according to today's standard. Then again probably I am too young to be their target audience.
Edit: Okay there are some IRC clients that actually look good, such as Riot, but not on the list of IRCv3 client.
It's one of the largest web based IRC clients and currently getting a rewrite at the moment, but we've always had a lack of design input unfortunately.
Btw, your file upload button at bottom right seems to be not working, it says "Application AisMDMMInTAOji478kuNxz is unavailable." when I click on it.