*Partyline should use &#channels instead of ~#channels #42

New Issue

2026-10-05T03:55:21+02:00

adam commented

2026-10-05 03:55:21 +02:00

Many clients are having problems with partyline using ~#channels (for example: IRSSI, WeeChat, Yaaic). Messages send to those channels appear as private messages to those clients. This is a problem with mobile IRC clients which vibrate on private messages.

We tested changing partyline to use &#channels and all messages sent to partyline appeared normally to channel. This is because most (if not all) clients hardcode & to CHANTYPES (or something what the server sends).

Many clients are having problems with partyline using ~#channels (for example: IRSSI, WeeChat, Yaaic). Messages send to those channels appear as private messages to those clients. This is a problem with mobile IRC clients which vibrate on private messages. We tested changing partyline to use &#channels and all messages sent to partyline appeared normally to channel. This is because most (if not all) clients hardcode & to CHANTYPES (or something what the server sends).

adam closed this issue

2026-10-05 03:55:21 +02:00

adam commented

2026-10-05 03:55:22 +02:00

Its more common for networks to use & themselves, so this might cause an issue where you can't connect to channels on a server. The bitlbee server uses & channels if I remember correctly. Perhaps the prefix should be configurable instead of changed, so that users can change the prefix if they wish to. Currently you can change it if you recompile, you can change the lines at the top of the module source.

// If you change these and it breaks, you get to keep the pieces
#define CHAN_PREFIX_1   "~"
#define CHAN_PREFIX_1C  '~'
#define CHAN_PREFIX     CHAN_PREFIX_1 "#"

Its more common for networks to use & themselves, so this might cause an issue where you can't connect to channels on a server. The bitlbee server uses & channels if I remember correctly. Perhaps the prefix should be configurable instead of changed, so that users can change the prefix if they wish to. Currently you can change it if you recompile, you can change the lines at the top of the module source. ``` // If you change these and it breaks, you get to keep the pieces #define CHAN_PREFIX_1 "~" #define CHAN_PREFIX_1C '~' #define CHAN_PREFIX CHAN_PREFIX_1 "#" ```

adam commented

2026-10-05 03:55:23 +02:00

BitlBee server uses &.

I agree with you that it should be user configurable.

I can try to test does this break & channels.

BitlBee server uses &. I agree with you that it should be user configurable. I can try to test does this break & channels.

adam commented

2026-10-05 03:55:23 +02:00

Tested.

IRCd: charybdis-3.3.0
How I tested:

I connected to network which supports &channels with two connections from which other was direct and another with ZNC which used &#channels with partyline.
I joined both connections to &test and both clients saw each other.

Result; it doesn't break & channels.

Tested. IRCd: charybdis-3.3.0 How I tested: 1. I connected to network which supports &channels with two connections from which other was direct and another with ZNC which used &#channels with partyline. 2. I joined both connections to &test and both clients saw each other. Result; it doesn't break & channels.

adam commented

2026-10-05 03:55:24 +02:00

Tested with &#Hi and this is where problems came in.

Joined with ZNC to &#hi with server which supports &channels.
Joined with ZNC to &#hi with server which doesn't support &channels.
Joined client to &#hi with direct connection on the server on step 1.

Result:
Step 1 joins to &#hi on server, partyline is not accssible.
Step 2 joins to &#hi on partyline. Client on step 1 is not visible.
Step 3 joins to &#hi on server, and clients on step 1 and 3 see each other.

Result: this is a problem.

Tested with &#Hi and this is where problems came in. 1. Joined with ZNC to &#hi with server which supports &channels. 2. Joined with ZNC to &#hi with server which doesn't support &channels. 3. Joined client to &#hi with direct connection on the server on step 1. Result: Step 1 joins to &#hi on server, partyline is not accssible. Step 2 joins to &#hi on partyline. Client on step 1 is not visible. Step 3 joins to &#hi on server, and clients on step 1 and 3 see each other. Result: this is a problem.

adam commented

2026-10-05 03:55:25 +02:00

No, this is more weird. Client in step 2 appears to partyline to client on step 1 and they can discuss with each other, but client in step 2 can't see client 1 in names list. The direct connection can't see any messages which are sent from ZNCs which are on partyline, but client on step 2 can see what client with direct connection says.

No, this is more weird. Client in step 2 appears to partyline to client on step 1 and they can discuss with each other, but client in step 2 can't see client 1 in names list. The direct connection can't see any messages which are sent from ZNCs which are on partyline, but client on step 2 can see what client with direct connection says.

adam commented

2026-10-05 03:55:25 +02:00

I think that it would make more sense to have a dedicated connection to the ZNC server for partyline, where it is completely isolated from any IRC server, then we can use #chans.

Since on the git version of ZNC, you can connect to the user and not a network, we could use partyline as user-only.

This would also allow us to message other uses without any prefixes.

I think that it would make more sense to have a dedicated connection to the ZNC server for partyline, where it is completely isolated from any IRC server, then we can use #chans. Since on the git version of ZNC, you can connect to the user and not a network, we could use partyline as user-only. This would also allow us to message other uses without any prefixes.

adam commented

2026-10-05 03:55:26 +02:00

That sounds like good idea. If it was different connection, would bufferplayback work? (Issue #21).

That sounds like good idea. If it was different connection, would bufferplayback work? (Issue #21).

adam commented

2026-10-05 03:55:27 +02:00

I brought this issue up a looong time ago on sourceforge, and in response they made it possible to change the prefix character for the channels. I personally use +#channel, which is considered valid by my irc client, while ~# is not (which I also reported as a bug for the client, I believe). To get this, just set lines 14-16. As far as I know, you don't need the hash (#) mark for a valid channel if it has another prefix, but there's no real reason to take it out or change it. Keep in mind you'll have to change this every time you update the partyline module.

It would also be much better if the partyline channels weren't stored with the prefix at all, and it was only shown to the client--this way you could change it at will, and not have to worry about being unable to join the correct partyline channel because the prefix is set incorrectly; currently if you join +#efreak and then change the prefix to ~#, everyone in +#efreak stays there seeing +#efreak, and users will be unable to join/part the old channel.

I brought this issue up a looong time ago on sourceforge, and in response they made it possible to change the prefix character for the channels. I personally use +#channel, which is considered valid by my irc client, while ~# is not (which I also reported as a bug for the client, I believe). To get this, just set lines 14-16. As far as I know, you don't need the hash (#) mark for a valid channel if it has another prefix, but there's no real reason to take it out or change it. Keep in mind you'll have to change this every time you update the partyline module. It would also be much better if the partyline channels weren't stored with the prefix at all, and it was only shown to the client--this way you could change it at will, and not have to worry about being unable to join the correct partyline channel because the prefix is set incorrectly; currently if you join +#efreak and then change the prefix to ~#, everyone in +#efreak stays there seeing +#efreak, and users will be unable to join/part the old channel.

adam commented

2026-10-05 03:55:28 +02:00

Whoops, I mixed the issue numbers up

Whoops, I mixed the issue numbers up

adam commented

2026-10-05 03:55:28 +02:00

This is client side issue.

Without partyline:

2014-07-12 22:21:05+0300 -- SAFELIST ELIST=CTU CHANTYPES=# EXCEPTS INVEX CHANMODES=eIbq,k,flj,CFLPQcgimnprstz CHANLIMIT=#:100 PREFIX=(ov)@+ MAXLIST=bqeI:100 MODES=4 NETWORK=AthemeNet KNOCK :are supported by this server

When /znc loadmod partyline is executed:

2014-07-12 22:21:49+0300 -- CHANTYPES=#~ :are supported by this server.

This is client side issue. Without partyline: > 2014-07-12 22:21:05+0300 -- SAFELIST ELIST=CTU CHANTYPES=# EXCEPTS INVEX CHANMODES=eIbq,k,flj,CFLPQcgimnprstz CHANLIMIT=#:100 PREFIX=(ov)@+ MAXLIST=bqeI:100 MODES=4 NETWORK=AthemeNet KNOCK :are supported by this server When `/znc loadmod partyline` is executed: > 2014-07-12 22:21:49+0300 -- CHANTYPES=#~ :are supported by this server.

adam commented

2026-10-05 03:55:29 +02:00

Bug report to WeeChat old issue tracker (fixed): https://savannah.nongnu.org/bugs/?35124

Bug report to WeeChat old issue tracker (fixed): https://savannah.nongnu.org/bugs/?35124

adam commented

2026-10-05 03:55:30 +02:00

Irssi: https://github.com/irssi/irssi/issues/93

Irssi: https://github.com/irssi/irssi/issues/93

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#42