Subchannels

[SoniEx2]

Preface

Let's start with an analogy because it makes it easier to explain.

So, I buy a new hard drive. I plug it in on my Linux box and it shows up as /dev/sdc. I give it a partition table with /dev/sdc1 as a linuxfs. I format it with ext4, and mount it somewhere. Let's call this mountpoint the "partition root" and let's refer to it as / for the purposes of this analogy.

I make some files, download some others, put them in the partition root, and I have e.g. /a.txt, /b.html, /c.png, etc.

After 5000 files or so, I need to get an important document, and altho I don't remember its name, I remember what it's about, so I do some (very slow) searches for it, but find nothing.

So I start making directories, and directory trees. /documents, /documents/webpages, /scripts, /audiovisual, /audiovisual/images, etc. After everything is organized, I go in /documents/work/important and find the document I was looking for, in only a few clicks.

Subchannels

So I bring you: subchannels! They work like directories in a file system. You can make a channel, say, #some, and anyone who can write to it (send messages) can make subchannels.

Quieting someone gives them read-only permission, so they can't write to subchannels. Banning someone bans them from the whole hierarchy of subchannels. Op/voice would still be per-channel, and so would modes.

---

I'm pretty sure I'm not committing a logical fallacy with that analogy. Do be careful with ad hominem tho. ;)

[RyanSquared]

Is there a problem with channels such as #lua-support (which I'm sure you know exists), or ##starbound-modding?

Also you literally made no effort to say how this would be implemented.

[RyanSquared]

Banning someone bans them from the whole hierarchy of subchannels.

---

Op/voice would still be per-channel, and so would modes.

You are aware how bans are implemented, right? Same with quiets?

[SoniEx2]

Is there a problem with channels such as #lua-support (which I'm sure you know exists), or ##starbound-modding?

There isn't a problem with it, except IRC clients don't usually show things like that following a hierarchy. A standardized separator would allow them to. Partial inheritance is just a bonus.

See also usenet, e.g. comp.linux.kde.dev.

You are aware how bans are implemented, right? Same with quiets?

Yes. Altho most modes wouldn't be inherited, bans and quiets would be. Chanserv would allow higher-ups to get op/voice on the subchannels, but you shouldn't get automatic op/voice on the whole hierarchy (it would conflict with freenode's policies otherwise).

[RyanSquared]

There isn't a problem with it, except IRC clients don't usually show things like that following a hierarchy. A standardized separator would allow them to. Partial inheritance is just a bonus.

Then add a ISUPPORT for it instead of having a "subchannel" - channels such as -* get stacked under .

Yes. Altho most modes wouldn't be inherited, bans and quiets would be. Chanserv would allow higher-ups to get op/voice on the subchannels, but you shouldn't get automatic op/voice on the whole hierarchy (it would conflict with freenode's policies otherwise).

This honestly sounds like something that won't ever get implemented.

[SoniEx2]

Also note that a subchannel CAN override a ban (with a ban exception), without affecting its parent.

[dequis]

If i were you I would have put more effort into explaining how this would be implemented in servers and clients, what's the UI supposed to be like, what kind of filtering is applied by servers or clients on received or sent messages, how backwards compatibility would be handled, etc. But instead you decided to spend five paragraphs explaining the UI of filesystems, which I can't see how you'd apply to a stream of messages.

[SoniEx2]

Well let's take a look at HexChat's UI, in tree mode. You have servers/networks, then they expand into channels/users, and you can collapse whole networks. With subchannels, channels would be able to expand into more channels, and so on.

For tab mode, you'd have a tab bar for networks, then a tab bar for channels, then a tab bar for subchannels, then a tab bar for subsubchannels, etc. Having multiple tab bars means you can quickly switch between networks while being fairly deep in a subchannel.

Backwards compatibility? This is backwards compatible: it's basically about standardizing a separator, and the behaviour of that separator (how that separator makes the IRCd behave).

For modes of type "list" that are channel-bound (bans, ban exceptions, quiets, etc) they'd be inherited, for modes of type "list" that are user-bound (op, voice, etc) they would NOT be inherited. Every other mode (+c +C +t +n etc) wouldn't be inherited. Optionally add modes to disable inheritance of specific lists. (e.g. banning $noinherit could disable ban list inheritance)

There would be additional search functions to get a list of subchannels. This would make searching for channels faster, as you wouldn't need as much bandwidth (and you could potentially limit the results, even e.g. when searching for channels, hide subchannels).

[RyanSquared]

Again, why can't you just ask IRC authors to implement the parsing of subchannels delimited by -? Also, it should be the responsibility of the channel operators to make sure bans are synchronized, and possibly not synchronized, across channels.

[RyanSquared]

I wanna turn IRC into usenet because it's cool

[grawity]

"Ask IRC authors"? Where would you do that if not the IRCv3 WG?

[RyanSquared]

@grawity: @SoniEx2 is trying to implement this on a protocol level; I'm instead counterproposing that it should be parsed client levels.

[SoniEx2]

@ChickenNuggers IRCd level*

[SoniEx2]

And a flag somewhere to indicate the server's separator.

[grawity]

Overall this seems like an ircd-specific feature. Clients can already just sort channels alphabetically; they still prefer sorting by size for some reason. (Even if it does result in noobs trying to ASL tech support channels.)

Just like extbans are an ircd-specific feature (for now), start with implementing ban inheritance via / in some ircd and see how it works out.

[RyanSquared]

Why should IRCds have to store more information when it is already easily doable via the current protocol?

[SoniEx2]

What about server-side search filtering?

[RyanSquared]

Use a service such as ALIS and search for something matching the first part of the channel.

[SoniEx2]

Why should IRCds have to store more information when it is already easily doable via the current protocol?

@ChickenNuggers It doesn't! Just split on the separators and search the tree for bans/ban exceptions/etc. No extra information stored. ;)

[RyanSquared]

So, remind me again, why should this be added to a spec?

[SoniEx2]

@ChickenNuggers Search. Filtering. No subchannels.

[RyanSquared]

Random words. How descriptive. Please elaborate more on what you mean.

[SoniEx2]

@ChickenNuggers I want the channel list to not display subchannels when you search, unless you're searching specifically for subchannels of a given channel.

So /list would filter everything with the separator out. /list #channel would list direct children of #channel, /list #channel-subchannel would list direct children of #channel-subchannel, and so on.

In addition to that I want partial inheritance when it comes to channel modes.

[RyanSquared]

@ChickenNuggers I want the channel list to not display subchannels when you search, unless you're searching specifically for subchannels of a given channel.

I think it should be reversed if at all. Subchannels unless said otherwise.

[RyanSquared]

I want to clarify my stance on this. I think it is a good idea to have subchannels. However, I try my best to point out flaws in everything I can so that we can fix them before they get pushed.

[RyanSquared]

literally add SEPARATOR in the 005, and tweak /list a bit because of user experience

[attilamolnar]

Hello,

As I see there are many questions about this, so I suggest to help us get into a realistic mindset about what is possible and how things should work, please provide some proof of concept code and/or get vendors to implement a mock to let everyone see this in action.

[attilamolnar]

If that's too much to ask, please consider https://github.com/ircv3/ircv3-specifications/issues/212#issuecomment-181398652 and try to explain as much as possible. Ideally, you should provide enough information about the use cases, protocol changes (if any), etc. to make it possible that potential adopters of your idea can figure it out whether it interests them or not.

[RyanSquared]

Currently, here are some thoughts that were discussed:

• 005 SEPARATOR=- (Protocol change)
  • This is the delimiter to use for "subchannels" and can be stacked
  • This can be changed on a per-server basis
• Use cases
  • Organizing channels in a client's list
  • Inheriting channel modes.
  • MODE #channel-subchannel +I bqi (+I is inherit, takes arguments "bqi" [ban, quiet, invite only]) is inherited through channels
  • Managing subprojects or related things
  • Real current applications: #lua-support, #weechat-offtopic, and ##starbound-modding

[SoniEx2]

This is how your IRC client usually looks like (assuming a GUI client such as HexChat or KVIrc):

NETWORK (this is collapsable)
|-- #CHANNEL1
|-- #CHANNEL1-EN
'-- #CHANNEL2

With this proposal, here's how it would look like:

NETWORK
|-- #CHANNEL1 (this would be collapsable)
|   '-- EN
'-- #CHANNEL2

The separator, - in this case, would be put on the ISUPPORT. Some networks might want to use / or : instead of -.

In terms of /list, it'd probably be behind a CAP, and would make /list accept an optional path argument. If the CAP is enabled, /list returns only top level channels (e.g. #CHANNEL1 from the example above). /list #CHANNEL1 would return direct subchannels of #CHANNEL1, e.g. EN (but not EN-DEV if EN had a DEV subchannel).

Channel mode inheritance would only be allowed for A-type CHANMODES. It wouldn't make much sense otherwise. (voice someone on the top level channel and they get voiced everywhere else? umm... no thanks)

[RyanSquared]

In terms of /list, it'd probably be behind a CAP

I think adding a CAP just for this is a bit too much. Again, why not add in an argument for LIST to NOT show them?

[SoniEx2]

@ChickenNuggers Because otherwise it'd hide subchannels for all clients.

[RyanSquared]

@ChickenNuggers Because otherwise it'd hide subchannels for all clients.

I don't think we should hide things by default.

[SadieCat]

:-1: This is more effort than its worth. The existing convention of #group-subgroup or #group.subgroup is fine.

[Mikaela]

• MODE #channel-subchannel +I bqi (+I is inherit, takes arguments "bqi" [ban, quiet, invite only]) is inherited through channels

RFC already defines +I as invitation mask and that is how you see it everyhwere so that is impossible.

My comment at IRC: those subchannels seem like interesting idea, but it seeems that you archieve the same thing by running ircd and putting only chanels of one topic there (doesn't unrealircd do this?) so I also say :-1:.

[SoniEx2]

What about the IRC client tree view part?

[M2Ys4U]

:-1: I would argue this is not in scope for IRCv3.

[Mikaela]

What about the IRC client tree view part?

Clients can archieve that with scripts. For example I am using autosort.py for WeeChat to have chanels in alphabedical order and it does this as side effect (I don't need them to be intended).

2016-02-08 21:19:51+0200   [28] irc.fr.#antispammeta (notify: all)
2016-02-08 21:19:51+0200   [29] irc.fr.#antispammeta-alerts (notify: all)
2016-02-08 21:19:51+0200   [30] irc.fr.#antispammeta-debug (notify: all)
2016-02-08 21:19:51+0200   [31] irc.fr.#archlinux.fi (notify: all)
2016-02-08 21:19:51+0200   [32] irc.fr.#archlinux-newbie (notify: all)
2016-02-08 21:19:51+0200   [33] irc.fr.#archlinux-security (notify: all)
2016-02-08 21:19:51+0200   [34] irc.fr.#archlinux-women (notify: all)
2016-02-08 21:19:51+0200   [35] irc.fr.#archlinux-women-dev (notify: all)

to take the first part from /buffer that is in that order.

Typing this I also remember that ZNC puts channels in alphabedical order causing them to appear like that when users attach.

[clokep]

What about the IRC client tree view part?

Please don't include UI decisions in any of the IRCv3 documentation, this should be up to client authors!

[kaniini]

:-1:, this is another feature that is unlikely to see implementation in charybdis. I cant speak for other IRCd authors, but I suspect same situation there.

[DanielOaks]

I think this is unnecessarily complicated for the benefit you get from it.

Besides, if I already have a channel named something like #my-cool-chan and someone registers #my-cool, do they now get some control over my existing channel? In addition, I've had several instances where the people who, for instance, run #coolchan and #coolchan-offshoot are separate people, so this would be transferring power over a channel to people who should not have it.

Doing this by parsing out characters that may be legitimately used in channel names seems very silly and like it can very easily bite users. If anything, you would want to send a specific command instead, but I'm not sure of the overall benefit to something like this anyway until I see a real spec. :-1:

[SoniEx2]

Besides, if I already have a channel named something like #my-cool-chan and someone registers #my-cool, do they now get some control over my existing channel? In addition, I've had several instances where the people who, for instance, run#coolchanand#coolchan-offshoot` are separate people, so this would be transferring power over a channel to people who should not have it.

Ugh, good point. .-.