*Partyline should use &#channels instead of ~#channels about znc HOT 12 CLOSED

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 "#"

from znc.

BitlBee server uses &.

I agree with you that it should be user configurable.

I can try to test does this break & channels.

from znc.

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.

from znc.

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.

from znc.

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.

from znc.

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.

from znc.

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

from znc.

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.

from znc.

Whoops, I mixed the issue numbers up

from znc.

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.

from znc.

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

from znc.

Irssi: irssi/irssi#93

from znc.