This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
openbsd:irc:zncbad [2020/07/29 01:18] jrmu |
openbsd:irc:zncbad [2020/07/30 01:44] (current) jrmu |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== ZNC Bad ====== | + | ====== Why ZNC is destined for failure ====== |
| - ZNC requires one connection per network. If a user wants to connect to 10 networks at once (freenode, ircnow, dal, efnet, etc), it requires him to set up 10 independent connections on his IRC client. This is almost impossible with mobile apps and very confusing for GUI apps. Practical experience has shown that <30% of bouncer users know how to do this. If you rely on ZNC, you will lose >70% of potential users. ZNC developers have declared they have zero interest in fixing this design flaw; in fact, they are proud of it. | - ZNC requires one connection per network. If a user wants to connect to 10 networks at once (freenode, ircnow, dal, efnet, etc), it requires him to set up 10 independent connections on his IRC client. This is almost impossible with mobile apps and very confusing for GUI apps. Practical experience has shown that <30% of bouncer users know how to do this. If you rely on ZNC, you will lose >70% of potential users. ZNC developers have declared they have zero interest in fixing this design flaw; in fact, they are proud of it. | ||
| Line 10: | Line 10: | ||
| - This same error also occurs when our bouncers are GLINEd. Again, ZNC stupidly tries to reconnect every minute, causing everyone to suffer from connection throttling, even if they are not GLINEd. | - This same error also occurs when our bouncers are GLINEd. Again, ZNC stupidly tries to reconnect every minute, causing everyone to suffer from connection throttling, even if they are not GLINEd. | ||
| - ZNC chose to adopt IRCv3, a terrible protocol because it adds nothing of value to users but introduces a lot of bugs. We have documented that older versions of mIRC (from around v7.33 to 7.41) are unable to connect because either mIRC or ZNC improperly implement IRCv3 capability negotiation. This bug has also been observed with some other Mac and Android IRC clients. What is worse is that nothing in the system logs or user clients ever show this error; it just appears to be nonresponsive after IRCv3 capability negotiation. We are able to reproduce this bug. | - ZNC chose to adopt IRCv3, a terrible protocol because it adds nothing of value to users but introduces a lot of bugs. We have documented that older versions of mIRC (from around v7.33 to 7.41) are unable to connect because either mIRC or ZNC improperly implement IRCv3 capability negotiation. This bug has also been observed with some other Mac and Android IRC clients. What is worse is that nothing in the system logs or user clients ever show this error; it just appears to be nonresponsive after IRCv3 capability negotiation. We are able to reproduce this bug. | ||
| + | - ZNC has no way of supporting both IPv4 and IPv6 simultaneously while preferring IPv6 when available. If you want to prefer IPv6, you are forced to drop support for IPv4 (you are therefore unable to connect to IPv4-only networks). If you choose to support both IPv4 and IPv6, znc usually chooses IPv4 by default, rather than using IPv6 by default. This is a design flaw. The default should be IPv6, then fallback to IPv4. | ||
| - ZNC nickserv module appears to use the /nickserv alias which is not supported on all IRCds (not supported by ngircd). The proper nickserv module should instead adapt to each IRC network so that users do not have to memorize the idiosyncrasies of every single network's services. For example, for ngircd, the proper command is /squery nickserv identify <password>; for DALnet, the proper command is /msg nickserv@services.dal.net identify <password>. This really does not need to be an optional module; it needs to be integrated into the bouncer. | - ZNC nickserv module appears to use the /nickserv alias which is not supported on all IRCds (not supported by ngircd). The proper nickserv module should instead adapt to each IRC network so that users do not have to memorize the idiosyncrasies of every single network's services. For example, for ngircd, the proper command is /squery nickserv identify <password>; for DALnet, the proper command is /msg nickserv@services.dal.net identify <password>. This really does not need to be an optional module; it needs to be integrated into the bouncer. | ||
| - ZNC does not offer users any way to download their chat logs. It has a chat log module which stores the chat logs on the server hard disk -- but how is a user supposed to fetch these logs? Unless you give every single user on your bouncer ssh access, you are forced to manually email them. A hideous solution. | - ZNC does not offer users any way to download their chat logs. It has a chat log module which stores the chat logs on the server hard disk -- but how is a user supposed to fetch these logs? Unless you give every single user on your bouncer ssh access, you are forced to manually email them. A hideous solution. | ||
| - Requesting a ZNC account using a web registration form or a bouncer bot is an ugly hack. Users should be able to register an account instantly upon first connection. | - Requesting a ZNC account using a web registration form or a bouncer bot is an ugly hack. Users should be able to register an account instantly upon first connection. | ||
| + | - ZNC bundles the [[https://wiki.znc.in/Shell|shell module]] by default, a module which makes it easy to exploit a 0day to get shell access to the entire server. It is impossible to delete this module. I complained about this to #znc on freenode and was told by that this was the least of my worries. This goes to show that znc developers do not care enough about security. | ||
| + | - ZNC's [[https://wiki.znc.in/Partyline|Partyline]] module is buggy when users are connected to multiple networks. Often, messages repeat 2x or more, and sometimes it causes the users to join strange channels without requesting it. This otherwise useful module has been dropped starting v1.8, so we will need to switch to psyBNC to keep it. | ||
| + | - There is no way to turn debugging on or off without compiling ZNC from source and restarting ZNC. | ||
| + | - ZNC's blockuser module may be buggy. I have not verified this with certainty, but I suspect that if you send a reconnect message to the *controlpanel, it may connect sometimes even if a user is blocked. | ||
| + | - Chrooting ZNC is a horrible, ugly hack. | ||
| + | - A commonly requested feature is to be able to use ZNC for both mobile phone client and PC IRC client. Here's the [[https://wiki.znc.in/Multiple_clients|ZNC wiki]] explaining how you have multiple clients. Did you understand that? Neither did I. This setup is too complex and confusing for normal people to follow. | ||
| - ZNC developers most likely have no interest in fixing any of the above design flaws. And even if they did, you'd be at the mercy of their development team, which may take years before they fix it. You are better off forking the code yourself. | - ZNC developers most likely have no interest in fixing any of the above design flaws. And even if they did, you'd be at the mercy of their development team, which may take years before they fix it. You are better off forking the code yourself. | ||
| - ZNC modules often fall into the category of 1) useless or 2) proprietary software. For example, the ZNC Push Notifications module is proprietary software. There is no open source push notifications for ZNC, but this feature is essential for a proper mobile IRC client. | - ZNC modules often fall into the category of 1) useless or 2) proprietary software. For example, the ZNC Push Notifications module is proprietary software. There is no open source push notifications for ZNC, but this feature is essential for a proper mobile IRC client. | ||
| Line 18: | Line 25: | ||
| ZNC is only 50% of the way there to a good bouncer. We chose it because it is more polished than psyBNC currently. psyBNC is only 30% of the way to a good bouncer. However, the problem is that znc is going on the wrong path, and will never straighten its course because of the above mentioned design flaws and a stubborn development team. psyBNC, however, is abandonware so we can mold it to fit our own goals. | ZNC is only 50% of the way there to a good bouncer. We chose it because it is more polished than psyBNC currently. psyBNC is only 30% of the way to a good bouncer. However, the problem is that znc is going on the wrong path, and will never straighten its course because of the above mentioned design flaws and a stubborn development team. psyBNC, however, is abandonware so we can mold it to fit our own goals. | ||
| - | ====== psyBNC Good ====== | + | ====== psyBNC is the bouncer of the future ====== |
| - Written in C, a UNIX hacker's best friend. | - Written in C, a UNIX hacker's best friend. | ||
| - psyBNC can multiplex multiple network connections onto a single connection, so that users only have to connect to psyBNC once to access all networks. If a user chooses to connect to 200 networks using psyBNC, his IRC client only has to connect once to psyBNC. This is a lot more intuitive than logging in 200 times. | - psyBNC can multiplex multiple network connections onto a single connection, so that users only have to connect to psyBNC once to access all networks. If a user chooses to connect to 200 networks using psyBNC, his IRC client only has to connect once to psyBNC. This is a lot more intuitive than logging in 200 times. | ||
| + | - Instead of chroot, we can use OpenBSD's pledge and unveil for greater security. | ||