I don't feel like typing much because it's nap time but IRCv3 is an almost closed group of friends, mostly znc core developers, who have decided they can choose what the future of IRC looks like.
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.
While a number of people in the group are friends, I definitely wouldn't call it a closed group of friends. These are people that have been developing different IRC projects for many years, all discussing the protocol and making sure clients + servers actually work together. Friendships will come from this over years.
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.
>ZNC guys and Atheme guys did not get along because political reasons, so they threatened to fork the project.
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.
Almost everything you have said is false. Please cease this defamation.
>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.
A few of the people in that group (but none on the technical board) have been contributing to projects and then disappear once the IRCv3 bits are included. Thusly it appears from a broad glance that they had no interest in the project itself as much as getting another client onboarded with IRCv3 support.
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.
I fail to see the issue. They fixed your project to stay compatible with the spec. They didn't stay, but isn't this the behavior of anyone who just fixes an issue they had in a project?
> I don't feel like typing much because it's nap time but IRCv3 is an almost closed group of friends, mostly znc core developers, who have decided they can choose what the future of IRC looks like.
This is how standards get built now. See also: systemd, R6RS.
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.