I think there's quite a bit we could do to extend this page and make it more useful for people who are a part of or explicitly interested in joining the working group.

Improving the participation page to include the technical board details in the charter would probably be a part of this (adapting it to use a _data list instead of being defined just on that page so we can add it there too, as well as just improving the look of the thing).

As well as that ircv3 announcements mailing list idea that was suggested, the roadmap stuff that's being done in ircv3/ircv3-specifications#241 and other details we could add or link to this WG page for interested people.

https://lynvie.com/~zarthus/video.mp4

Only happens when the element is active, e.g. you're on http://ircv3.net/support/networks.html

e.g. /software/clients.html shows it on all tables where it only actually makes sense for the Web Clients table.

dan-: makes sense for them only to be on the webclient one methinks, or something similar. one main purpose of the support page is to find software that implements XYZ so you can test using it, so it should stay on there... just not for all clients, esp when none of them implements a thing
dan-: will likely take a bit of liquid updates to the table include tho
dan-: specific attribute on certain specs that allow for it to be dropped from support tables if no s/w supports it, because I don't want that by standard (discourages new spec adoption), though we can steal the handling of the draft specs because that's the default behaviour for those
dan-: etc

• https://encrypted.google.com/search?q=site:ircv3.net

That search doesn't tell a lot about what IRCv3 is and most of meta descriptions are just IRCv3 development community.

They can be added by adding excerpt: "meta description here" in the YAML frontend matter or whatever it was called as.

The base requirements for 3.1 are cap, multi-prefix and sasl. The following software doesn't fill the requirements:

Clients

• BitchX (multi-prefix)
• Konversation (multi-prefix, sasl)
• LimeChat (multi-prefix)
• mIRC (multi-prefix, sasl)
• Mibbit (multi-prefix, sasl)
• AndChat (multi-prefix)
• AndroIRC (multi-prefix)
• IRC7 (multi-prefix)
• LimeChat mobile (multi-prefix)

Servers

• IRCCloud (sasl)
• mammon-ircd (multi-prefix, sasl)

Libraries

• Net::Async::IRC (extended-join, multi-prefix)

not sure why it was removed when it is ircv3 compliant

http://ircv3.net/software/clients.html is missing http://shout-irc.com which is a pity because its great

It would be great if the website could indicate the SASL mechanisms supported by each network listed.

Possibly as a tooltip on the networks page, in a section on the SASL mechanisms page or somewhere else entirely?

It's pretty explicit when servers support batches. Q: Do they send batches. A: Y/N.

However, when it comes to clients... it's much less explicit. Some example questions we could apply:

• Do they request the batch capability by default?
• Internally, can they track which messages are part of which batches?
• Can they post-process messages after they receive the 'batch end' message, collapsing them to display more nicely?
• Do they correctly collapse one or more of the standard batch types, and handle them explicitly?

I dunno, it's hard to say when a client really supports 'batches'. What I think makes the most sense is for the actual batch column on the standard support page to be green when the client requests / can request batch (and handle messages in batches without dropping them or similar), and to create a similar batch-types support page similar to the SASL mechs support page, detailing exactly which batches are supported.

The above is what I'll be going by for the future, and I'll make that batch types support page sometime soon.

pydle just cut 0.8.2 from HEAD (shizmob/pydle@36f4711), so the items which are currently listed as git support can probably be updated.

Makes it much easier to test specs if people know a test network that supports them. Add some sort of testnet indicator to each server (if it has one), and mark it somewhere appropriate.

For SASL mechanisms and BATCH types it would be nice if we had a table displaying what clients/servers support what features the same as with the specification tables.

(if you ask me, at least!)

Make the following YML:

v3.3:
  name: IRCv3.3 Draft
  note: >
    **These specifications are drafts and are NOT completed IRCv3 specs.**

    These caps are generally implemented with the `draft/` prefix until they are made into released IRCv3 specifications.
  specs:
    message-tags:

in either:

draft/v3.3:  # <--
  name: IRCv3.3 Draft
  note: >
    **These specifications are drafts and are NOT completed IRCv3 specs.**

    These caps are generally implemented with the `draft/` prefix until they are made into released IRCv3 specifications.
  specs:
    message-tags:

or

v3.3:
  name: IRCv3.3 Draft
  note: >
    **These specifications are drafts and are NOT completed IRCv3 specs.**

    These caps are generally implemented with the `draft/` prefix until they are made into released IRCv3 specifications.
  specs:
    draft/message-tags:  # <--

This change stops accidentally advertising a draft as a finished product.

The feed is linked in the footer, but ideally it should also be linked in the <head> to allow autodiscovery by browsers, feed readers, etc. Something like:

<link rel="alternate" type="application/rss+xml" href="/feed.xml" />

We have the Google Docs stakeholders list here.

Do we want to throw that onto the website, on the Participants page or something? Or would it be best to mostly leave it at organisations involved with us on the site and leave that as an 'administrative' document?

The official website doesn't support IPv6.

Since it seems to use Netlify, it should suffice to follow the instructions on their IPv6 support announcement for enabling it.

I feel like we could make this page quite a bit better.

Especially with the discussions we've been having about the merits of actually releasing features in batches (3.1, 3.2, 3.3, etc), it may be worth looking at different ways we could display the features.

One thing we can look at is the IRCCloud page describing the various IRCv3 features, and whether it'd be useful or appropriate for us to take a similar approach (presenting each spec with a short tagline describing what it accomplishes and giving a general overview of it). Depends on our audience and who we're targeting with the page, but I'll sketch out some ideas, and people can present their own in here.

This is a very general issue. Basically, we need to do some overhauling on the front page and some of the other pages to present ourselves and the work we're doing more clearly. Basically, to show people why they should be involved and/or keeping an eye on us, the sort of features IRCv3 specifications provide and what we're working on, that sort of thing.

We have multiple audiences, and we should see who we really want to and need to cater to, and tailor the parts of our site to that.

This is probably gonna be a fairly decent overhaul to the site. We should keep #9 in mind as part of it.

I'd love seeing the Android client Revolution IRC on the support tables, unfortunately I don't have the time to personally look through what it supports and make a PR about it

So we've now merged the new merged Message Tags spec. Awesome, cool, all good.

So previously (when the message-tags 3.3 spec was just a draft), the support row very specific referred to support for the message-tags capability (since it was prefixed by draft/ and all, showing as draft/message-tags-0.2).

Now that the message-tags capability is presented as a part of the core Message Tags spec, it makes things a little difficult. With ratifying the new version, I've changed the row name from draft/message-tags-0.2 to message-tags cap (seen here). For what it's worth, I think making this change and leaving it here is the best way to go with it, it's very clear what a green/red on the row means, and I don't think a general 'tag support' row would be useful for devs. But people have discussed whether including a separate, more general row that just indicates 'supports tags/tagging at all' would be useful.

Specifically, I think that a project 'supports tags' can be better indicated by the existing rows which show support for specs that define and use specific tags. The only way it feels like a 'supports tags' indicator could be useful is for devs looking to hack on a new project and seeing which ones support general tag functionality already that they could extend? I dunno, it doesn't feel like a very useful bit of information to have on there, whereas showing the message-tags cap support indicates support for TAGMSG and c2c tags, which are definitely of interest to devs.

Thoughts appreciated!

Something like this in the footer of every specification (with a bit better wording) so it's easy to find what you can test on/with and widespread support for a SPECIFIC spec, rather than just looking at the support table and manually comparing when you're just interested in one thing

Peeps have reported that on slow connections our site takes forever to load. That's sketchy, look at it, test it here with built-in browser tools for this, and make sure it loads fast.

• https://help.github.com/articles/custom-404-pages/

The current GitHub pages 404 error isn't very helpful, I think it should at least link back to index.

Which means at least IRCv3.1 base compatibility unless the base/optional at http://ircv3.net/irc/ mean nothing.

Both the _config.yml (though commented) and the GitHub organization URL indicate http://ircv3.org as being the official domain, though that domain doesn't resolve. It seems the official TLD is .net, not .org.

Is this so or am I missing something? :)

Their website's domain expired on April 2nd. Is this project dead, or have they simply just switched domains? Their organization also appears to be inactive (supporting the former position), with the last commit being made on January 30th.

If it is dead, we might want to remove it from this list (or maybe mark it as "Past Participants" or something): participants.yml

Setting .page-header { line-height: 1.5; } and .content { line-height: 1.5 } makes everything far easier to read.

The site is all about specifications. Is there a plan to make information for humans - why new protocol, what issues need to be addressed, what are those shiny exciting, useful new features for networks, and client / server authors that stakeholders in the IRC protocol, such as IRC networks and IRC network operators interested in?

(reposted)

In brief

• Use a different plugin to provide anchors to the IRCv3 website
  • Not everyone has JavaScript - Chrome on 2G, NoScript, text-based browsers, etc

Test case

Visit https://ircv3.net/irc/#v3-2-metadata without JavaScript enabled, as referenced by the IRCCloud blog.

More can be added later if needed, this is just to keep the issue from being forgotten.

Charybdis is no more: charybdis-ircd/charybdis@40ac82e and points to http://github.com/freenode/ircd-seven as a replacement, which doesn't support the same extent of CAPs. Freenode is already listed on the networks support tab, but I think adding ircd-seven to the server list would make sense. Should be a straightforward copy pasta.

As mentioned in #48, it would be nice to see information for services packages.

I'm not sure how much use services packages have for the various IRCv3 specifications (since they usually use an S2S protocol, probably a lot of things they don't care about), but at least for things like SASL support it would be very useful.

See also #139, let's do something like this after #135 is merged.

At #znc it was asked if there is any good Android IRC app which works well with ZNC and I replied:

any from http://ircv3.net/software/clients.html that supports server-time, I would say
it doesn't separate by mobile OS though
none it looks like

I think that especially with mobile the OS should be indicated somehow, but it wouldn't hurt with others either, it just must be kept in mind that clients can support multiple OSes.

There's a bunch of clients and servers in the support tables which haven't been maintained in years. We should probably remove them.

Desktop Clients

• Colloquy — last release almost five years ago, last commit 19 months ago.

Web Clients

• Iris — last commit over two years ago, marked as legacy on GitHub.

Mobile Clients

• AndChat — website link dead, removed from Google Play according to /r/irc.
• IRC7 — website link dead, WP7 no longer a thing that exists.

... plus probably a bunch more that I can't investigate

Servers

• ChatIRCd — website link dead, no commits in over a year.
• Elemental IRCd — no commits in over two years.
• mammon-ircd — no commits in over three years.

Due to recent behaviour that clearly and verifiably violates the code of conduct, namely persistent abuse and harassment towards project members, eskimo has been blocked from the github org and their software (igloo) has been removed from support tables (838d0f3).

Their recent actions go beyond previously reported unverified behaviour, to the point that they are no longer welcome to contribute to the project, nor do we want any association with them, even in an informational capacity.

Bah, merging the FAQ PR has given us about 5px of layout where it's sketchy and broken. Should be a simple fix, just modifying/defining some lengths in the css:

At #64 (comment) I said:

Possibly offtopic for this issue, but having the site over https would be nice. It just seems weird that encryption is recommended (HSTS (if we ignore ircv3/ircv3-specifications#207)), but the site is only accessible with http.

I am fully aware of the site being on GitHub pages and thus not being able to have TLS as it uses custom domain.

And @DarthGandalf replied:

Yes, it's offtopic. Please open a separate issue for that if you want that
feature.

Reporting this for someone else, it's not my own system. This is occurring on Windows 10, using Edge. Not reproducible in Chrome on the same system.

Screenshot is hopefully self-explanatory :)

So we obviously want some sort of limit, so we don't end up with 9000 random networks on there. Things like number of clients, activity, whether they're a top100 network and such come info it.

Where do we wanna set the limits here, and which sort of networks do we want on that page? What is most useful for end users?

I feel like the networks page answers two questions:

1. Where can I go to test my IRCv3 client implementation? (testnet section)
2. Do many real-world networks implement IRCv3 stuff? (real-world section)

What do we think here?

I think some kind of formatting would make it more clear what clients are required to have in order to be IRCv3.1 compatible.

The technical board's stayed largely the same for a fair while now. So have the processes that IRCv3 has worked with. Figured I'd make an issue to discuss that (just opening it in this repo because this is where previous TB membership has been discussed in the past).

So, what other projects make sense to bring onto the TB? Or are there any irc-related people who've been doing stuff actively that people think we should bring on?

Obviously, Atheme (iirc last time we chatted to them we couldn't come to agreement on who to be put forward to represent them), networks are always useful so maybe someone representing solanum and/or one of the networks that're putting work into that project? They're both really big, obvious hitters, who else has been active and pushing development?

In general, more network involvement would be appreciated I think - but aside from freenode a lot of the other big networks seemed not-that-interested in working with us because of previous bad experiences in years past. Should we reach out again? If so, who should we reach out to.

I know that I've been really inactive, and sling's been doing more than me in terms of pushing stuff towards v3?

Somewhat of a side discussion, given the lack of real 'power' that TB membership brings (there's the perceived power of course, but in terms of process it's more limited and I think we tend to be pretty lax in terms of most parts of the process that require 'actual authority'), I find that most of the time when people ask for TB changes what people are really looking for is a change in the processes the group runs with.

In ircv3/ircv3-specifications#375 (or along with when I was writing up that PR) I was really messing about with changing up our processes in general, overhauling them to make them more defined or to try and speed up useful, active development. Lately I've been a lot more bent on the idea of implementors getting together to build ideas, prove they work, and then submitting them to us once they're ready and running (ala znc with server-time, irccloud with the client-tags they introduced, etc). Anyone have ideas about changing processes or ideas to improve them, or itches/issues they have with the current processes v3 works under?

https://ircv3.net/irc/ does not link to https://ircv3.net/specs/extensions/standard-replies

On the DH-* SASL documentation pages, there should be a bit warning saying they're deprecated, etc. Honestly I'm surprised this isn't done already.

This would probably be best implemented as something along the lines of a deprecated: true in the YAML front matter of the actual spec files and the addition of an if statement in the spec layout.

When you hover over elements, they shift 1px (or-so) to the left. Fix it plz.

This was brought up again recently, just like a news tab on the site with a simple RSS feed to announce changes to interested people. Could be cool to look at doing, would probably throw it on the WG page to improve #83 as well.

It's been a fair while since we switched to the new format. It's about time that we had a re-think of the site in general and updated it.

Some general discussion:

I'm mostly trying to improve visibility of different clients and features, because most IRC users don't even know what's possible, or only see what irccloud can do, but think that's something proprietary

but then obviously theres irccloud that has a decent twitter+blog feed that showcases what irc clients can do too, that gets a fair amount of traction. i assume your quassel stuff will also be a decent showcase when you get that running

its all well and good to have a single place to push it, but showing that there are mutliple projects and a wider range of dev is also important to broaden the scope

But it’s hard to promote as a “product” when there’s loads of different approaches and focuses

i think for general updates and showcasing what clients can now do should be an ircv3 thing, since thats what most new features are based upon anyway. though i think it could do a better job at it than jsut tweeting things here and there imo

that would also promote ircv3 specs to irc devs

all things that have been mentioned before. removing the wall of text from the homepage, perhaps using a shorter 2 scentence "what is ircv3" paragraph instead along with a mini news/blog/whatever you want to call it of new things that are now possible using ratified specs. not too technically in depth, just enough to explain what features can now be done. secondaly, the roadmap. i can still never find this on the site. then links to the more indepth

info + support tables etc on seperate pages

just clearer, and small updates on a more abstract level for what ircv3 is aiming for and can already do. a lot of people talk about ircv3 in the scope that its to improve irc, but theyre not so so indepth with the protocol that the website makes any sense to them

but ircv3,net is the best place to explain simply whats possible now imo

The other thing is that we’re still not quite there yet with a lot of specs.

Def a more user focused side of it than a dev focus would be good

Its a decent brand to build on as a “product”

The other thing is that we’re still not quite there yet with a lot of specs.

this is one for the other things the website could probably show better. basically a callout for devs to try out things. theres the roadmap, sure, but its jsut a list of github issues that everyone glosses over

if theres any in a suitable position to actually trialled out and the majority fo us thinks its worth more focus over others, a callout on the website for it would be cool. even jsut to show casual readers that things are happening. i wonder if you coudl automate that via github labels. hmm

personally I’d even go as far as to split this into a user-focused and a dev-focused website

mixing and merging both is suboptimal for both target groups

mixing into the same page - yes. on the same website is completely doable though, and better for seo as you mentioned earlier

yes, definitely, but like matrix does maybe as separate subpaths. and maybe a subdomain on the same page for the redirector thing we discussed earlier

not totally against it, but i do think that may be too much out of scope for ircv3.net imo

Since we now have 3.1 and 3.2, we should be listing which version of the spec software packages support.

Suggested by @Mikaela, in response to the confusion in znc/znc#960

It's been suggested that this should contain more information about what specific features, specifications, and extensions are supported for each software package. A dropdown / collapsible element listing would probably work – I'll have a play about with this.

Jekyll has inbuilt SASS stuff. we have a whole lot of places where we can simplify and make our stuff easier to understand using those, so we should do it.

As discussed in IRC, having some disclaimer to note the best-effort status of the software lists would be good. @jwheare has offered to handle this.

Something along the lines of:

We make a best effort to keep this list up to date but it may deviate from recent releases. Please submit updates or corrections for this list to our Github repository or contact us.