-
Notifications
You must be signed in to change notification settings - Fork 379
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
*Partyline should use &#channels instead of ~#channels #94
Comments
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.
|
BitlBee server uses &. I agree with you that it should be user configurable. I can try to test does this break & channels. |
Tested. IRCd: charybdis-3.3.0
Result; it doesn't break & channels. |
Tested with &#Hi and this is where problems came in.
Result: Result: this is a problem. |
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. |
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. |
That sounds like good idea. If it was different connection, would bufferplayback work? (Issue #21). |
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. |
Whoops, I mixed the issue numbers up |
This is client side issue. Without partyline:
When
|
Bug report to WeeChat old issue tracker (fixed): https://savannah.nongnu.org/bugs/?35124 |
Irssi: irssi/irssi#93 |
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).
The text was updated successfully, but these errors were encountered: