Blame
Date:
Wed Feb 1 05:00:29 2023 UTC
Message:
Daily backup
001
2023-01-22
jrmu
version=pmwiki-2.2.130 ordered=1 urlencoded=1
002
2023-01-22
jrmu
agent=w3m/0.5.3+git20210102
003
2023-01-22
jrmu
author=jrmu
004
2023-01-22
jrmu
charset=UTF-8
005
2023-01-22
jrmu
csum=
006
2023-01-22
jrmu
ctime=1597415298
007
2023-01-22
jrmu
host=38.87.162.154
008
2023-01-22
jrmu
name=Debate.Zncflaws
009
2023-01-22
jrmu
rev=31
010
2023-01-22
jrmu
targets=
011
2023-01-22
jrmu
text=(:title ZNC Design Flaws:)%0a%0a!! ZNC requires multiple IRC connections for multiple networks%0a%0aZNC requires your IRC client make 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 difficult some apps and confusing. ZNC developers have no interest in fixing this.%0a%0a!! Login is confusing%0a%0aIf your username is john, your password is secret123, and you want to connect to liberachat, your password field needs to be john/liberachat:secret123. If you want to connect to oftc, your password field needs to be john/oftc:secret123. This is an unintuitive way of changing networks.%0a%0a!! ZNC requires too much technical background%0a%0aUsing ZNC requires reading too much documentation in order to use. For example, typing /msg *status help shows a wall of text that only a sysadmin could understand. Jargon like AddTrustedServerFingerprint, ClearAllChannelBuffers, and SetUserBindHost are exposed to users. It would be better if the end-user did not have to read a single page of documentation.%0a%0a!!! ZNC relies on a web panel%0a%0aThere is no need to bundle a web server with a bouncer. Configuration can be managed without user configuration.%0a%0a!!! ZNC is written in C++, a language we don't plan to support%0a%0a!!! ZNC throttles users so it can take hours to connect%0a%0aThe throttling is done poorly -- each connection is attempted and throttled serially, even if the networks being connected to are different. These connections should be done in parallel rather than serially. For example, if you have 30 independent networks to connect to and a 30 second throttling delay, it would take 15 minutes with ZNC, but it should only take 5 seconds with a proper bouncer that connects to all 30 networks simultaneously. There is no need to throttle because they are all unique. On a ZNC server with 100 users, it can take an hour just to connect.%0a%0a!!! ZNC will disconnect users and throttle if SSL certs are not properly signed%0a%0aIf a server doesn't have a properly signed SSL cert, ZNC will disconnect until the user adds the SSL fingerprint manually. Users often don't understand why. To make matters worse, ZNC insists upon reconnecting and failing indefinitely. This causes connection throttling, slowing everyone from being able to connect. Sysadmins are forced to manually intervene.%0a%0a!!! ZNC throttles everyone if someone is glined%0a%0aWhen someone is GLINEd, ZNC tries to reconnect indefinitely, causing everyone to suffer from connection throttling until a sysadmin manually intervenes.%0a%0a!!! Upon disconnect, ZNC loses all messages%0a%0aZNC does not store any buffers to disk and hence, if crashes or suffers a DDoS attack, will loses all its messages.%0a%0a!!! IRCv3 adoption causes bugs%0a%0aIRCv3 adoption has caused documented bugs in older IRC clients. 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. Nothing in the system logs or user clients ever show this error; it just appears to be nonresponsive after IRCv3 capability negotiation.%0a%0aIn another documented bug with ZNC, [[https://docs.inspircd.org/faq/#why-does-my-client-not-show-mode-changesopped-users-on-joinetc-correctly-when-using-inspircd-v3|mode changes]] don't show up properly on InspIRCd v3.%0a%0a!!! ZNC can't prefer IPv6 by default%0a%0aIf you try to support both IPv4 and IPv6 simultaneously, ZNC will not prefer IPv6 when available, and there is no way to fix this currently short of a custom patch. 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. The correct behavior should be IPv6, then fallback to IPv4.%0a%0a!!! ZNC module relies on commands not supported on all IRCds%0a%0aThe ZNC NickServ module appears to use the /nickserv alias which is not supported on all IRCds (not supported by ngircd). The proper nickserv behavior would be to 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 %3cpassword>; for DALnet, the proper command is /msg nickserv@services.dal.net identify %3cpassword>.%0a%0a!!! ZNC does not offer any easy way to download chat logs%0a%0aIt has a chat log module which stores the chat logs on the server hard disk, but there is no easy way for a user to fetch those logs without ssh access.%0a%0a!!! ZNC has no way to register instantly upon connection%0a%0aIdeally, users would be able to register an account instantly upon first connection.%0a%0a!!! ZNC's [[https://wiki.znc.in/Partyline|Partyline]] module has been dropped%0a%0aWhen users are connected to multiple networks, messages often 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.%0a%0a!!! ZNC's blockuser module may be buggy%0a%0aI 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.%0a%0a!!! ZNC has security issues%0a%0aZNC 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.%0a%0a!!! Confusing mobile support%0a%0aA 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. This setup is too complex and confusing for normal people to follow.%0a%0a!!! No fully open source push notifications%0a%0aZNC Push Notifications module relies upon closed/non-free software/services. There is no fully open source push notifications for ZNC, an essential feature for a proper mobile IRC client.%0a
012
2023-01-22
jrmu
time=1649135908
013
2023-01-22
jrmu
title=ZNC Design Flaws
014
2023-01-22
jrmu
author:1649135908=jrmu
015
2023-01-22
jrmu
diff:1649135908:1649135310:=17,20c17,20%0a%3c There is no need to bundle a web server with a bouncer. Configuration can be managed without user configuration.%0a%3c %0a%3c !!! ZNC is written in C++, a language we don't plan to support%0a%3c %0a---%0a> There are two problems. First, I suspect this web panel cannot be easily customized without recompiling. Secondly, it does not follow the UNIX philosophy of Do One Thing and Do It Well. There is no need to bundle a web server with a bouncer. These should be two separate programs because they deal with two separate protocols/objectives. There is no real need for a webpanel at all. There's nothing in the webpanel that could not be configured and managed by sysadmins on behalf of users.%0a> %0a> !!! ZNC is written in C++, an inelegant language.%0a> %0a23,24c23,24%0a%3c The throttling is done poorly -- each connection is attempted and throttled serially, even if the networks being connected to are different. These connections should be done in parallel rather than serially. For example, if you have 30 independent networks to connect to and a 30 second throttling delay, it would take 15 minutes with ZNC, but it should only take 5 seconds with a proper bouncer that connects to all 30 networks simultaneously. There is no need to throttle because they are all unique. On a ZNC server with 100 users, it can take an hour just to connect.%0a%3c %0a---%0a> The throttling is done poorly -- each connection is attempted and throttled serially, even if the networks being connected to are different. These connections should be done in parallel rather than serially. For example, if you have 30 independent networks to connect to and a 30 second throttling delay, it would take 15 minutes with ZNC, but it should only take 5 seconds with a proper bouncer that connects to all 30 networks simultaneously (no need to throttle because they are all unique). On a ZNC server with 1000 users, it can take hours (maybe days) just to connect.%0a> %0a27,28c27,28%0a%3c If a server doesn't have a properly signed SSL cert, ZNC will disconnect until the user adds the SSL fingerprint manually. Users often don't understand why. To make matters worse, ZNC insists upon reconnecting and failing indefinitely. This causes connection throttling, slowing everyone from being able to connect. Sysadmins are forced to manually intervene.%0a%3c %0a---%0a> If a server doesn't have a properly signed SSL cert, ZNC will disconnect until the user adds the SSL fingerprint manually. This confuses >90%25 of users. They always blame our bouncer for not working properly. To make matters worse, ZNC then insists upon reconnecting every minute or so and failing in the same manner. And because ZNC does connection throttling, this slows everyone from being able to connect. You as a sysadmin are forced to manually disconnect networks that have SSL certs that aren't properly signed, or else in a few weeks, your ZNC becomes so slow (due to all the throttling) that it takes >10 mins to connect.%0a> %0a31,32c31,32%0a%3c When someone is GLINEd, ZNC tries to reconnect indefinitely, causing everyone to suffer from connection throttling until a sysadmin manually intervenes.%0a%3c %0a---%0a> When someone is GLINEd, ZNC tries to reconnect every minute, causing everyone to suffer from connection throttling, even if they are not GLINEd.%0a> %0a35,40c35,40%0a%3c ZNC does not store any buffers to disk and hence, if crashes or suffers a DDoS attack, will loses all its messages.%0a%3c %0a%3c !!! IRCv3 adoption causes bugs%0a%3c %0a%3c IRCv3 adoption has caused documented bugs in older IRC clients. 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. Nothing in the system logs or user clients ever show this error; it just appears to be nonresponsive after IRCv3 capability negotiation.%0a%3c %0a---%0a> ZNC loses all its messages if you are ddosed while away, or even if there is a simple brief 10 minute hiccup in networking. When this happens, '''every single message is lost'''.%0a> %0a> !!! ZNC adopts a protocol that introduces new bugs without new features%0a> %0a> ZNC chose to adopt IRCv3, an unnecessary protocol which 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.%0a> %0a45,46c45,46%0a%3c If you try to support both IPv4 and IPv6 simultaneously, ZNC will not prefer IPv6 when available, and there is no way to fix this currently short of a custom patch. 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. The correct behavior should be IPv6, then fallback to IPv4.%0a%3c %0a---%0a> If you try to support both IPv4 and IPv6 simultaneously, ZNC will not prefer IPv6 when available, and there is no way to fix this currently short of a custom patch. 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.%0a> %0a49,50c49,50%0a%3c The ZNC NickServ module appears to use the /nickserv alias which is not supported on all IRCds (not supported by ngircd). The proper nickserv behavior would be to 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 %3cpassword>; for DALnet, the proper command is /msg nickserv@services.dal.net identify %3cpassword>.%0a%3c %0a---%0a> The 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 %3cpassword>; for DALnet, the proper command is /msg nickserv@services.dal.net identify %3cpassword>. This really does not need to be an optional module; it needs to be integrated into the bouncer.%0a> %0a53,54c53,54%0a%3c It has a chat log module which stores the chat logs on the server hard disk, but there is no easy way for a user to fetch those logs without ssh access.%0a%3c %0a---%0a> 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.%0a> %0a57,60c57,64%0a%3c Ideally, users would be able to register an account instantly upon first connection.%0a%3c %0a%3c !!! ZNC's [[https://wiki.znc.in/Partyline|Partyline]] module has been dropped%0a%3c %0a---%0a> Requesting a ZNC account using a web registration form or a bouncer bot is bad design. Users should be able to register an account instantly upon first connection.%0a> %0a> !!! ZNC has poor security%0a> %0a> 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.%0a> %0a> !!! ZNC's [[https://wiki.znc.in/Partyline|Partyline]] module is buggy%0a> %0a67,69c71%0a%3c !!! ZNC has security issues%0a%3c %0a%3c 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.%0a---%0a> !!! ZNC can't be made secure without chroot%0a
016
2023-01-22
jrmu
host:1649135908=38.87.162.154
017
2023-01-22
jrmu
author:1649135310=jrmu
018
2023-01-22
jrmu
diff:1649135310:1649135234:=77,79c77,79%0a%3c !!! No fully open source push notifications%0a%3c %0a%3c ZNC Push Notifications module relies upon closed/non-free software/services. There is no fully open source push notifications for ZNC, an essential feature for a proper mobile IRC client.%0a---%0a> !!! No open source push notifications%0a> %0a> ZNC modules often fall into the category of 1) not useful 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.%0a
019
2023-01-22
jrmu
host:1649135310=38.87.162.154
020
2023-01-22
jrmu
author:1649135234=jrmu
021
2023-01-22
jrmu
diff:1649135234:1615258176:=1,14c1,14%0a%3c (:title ZNC Design Flaws:)%0a%3c %0a%3c !! ZNC requires multiple IRC connections for multiple networks%0a%3c %0a%3c ZNC requires your IRC client make 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 difficult some apps and confusing. ZNC developers have no interest in fixing this.%0a%3c %0a%3c !! Login is confusing%0a%3c %0a%3c If your username is john, your password is secret123, and you want to connect to liberachat, your password field needs to be john/liberachat:secret123. If you want to connect to oftc, your password field needs to be john/oftc:secret123. This is an unintuitive way of changing networks.%0a%3c %0a%3c !! ZNC requires too much technical background%0a%3c %0a%3c Using ZNC requires reading too much documentation in order to use. For example, typing /msg *status help shows a wall of text that only a sysadmin could understand. Jargon like AddTrustedServerFingerprint, ClearAllChannelBuffers, and SetUserBindHost are exposed to users. It would be better if the end-user did not have to read a single page of documentation.%0a%3c %0a---%0a> !! Why we must replace ZNC with psyBNC%0a> %0a> !!! ZNC requires users set up dozens of connections%0a> %0a> ZNC requires your IRC client make 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 %3c30%25 of bouncer users know how to do this. If you rely on ZNC, you will lose >70%25 of potential users. ZNC developers have declared they have zero interest in fixing this design flaw.%0a> %0a> !!! ZNC has a confusing way of logging in%0a> %0a> If your username is john, your password is secret123, and you want to connect to freenode, your password field needs to be john/freenode:secret123. If you want to connect to dal, your password field needs to be john/dal:secret123. This is an unintuitive way of changing networks. Users don't understand this without 1-2 hours of troubleshooting.%0a> %0a> !!! ZNC is not designed for casual users%0a> %0a> It requires reading far too much documentation in order to use. For example, typing /msg *status help shows a wall of text that only a sysadmin could understand. Jargon like AddTrustedServerFingerprint, ClearAllChannelBuffers, and SetUserBindHost are exposed to users -- words that only a sysadmin could understand after reading through several pages of wikis. As sysadmins, we should configure all this for the end-user so the end-user does not have to read a single page of documentation.%0a> %0a65,66c65,66%0a%3c When users are connected to multiple networks, messages often 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.%0a%3c %0a---%0a> When users are connected to multiple networks, messages often 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.%0a> %0a72a73,82%0a> With psybnc, we can use pledge and unveil.%0a> %0a> !!! ZNC treated IRCNow as a hate group%0a> %0a> In the [[https://wiki.znc.in/index.php?title=Template:Providers/table&action=history|ZNC Providers]] page, IRCNow was falsely accused of being involved with hate activities. %0a> %0a> -> 30 January 2020‎ IRCNow removed due to multiple complaints of discrimination and hate activities by its administrators.%0a> %0a> This accusation was made without a fair trial or ability to appeal. Since the development team is not friendly to our goals, IRCNow should not rely on their software.%0a> %0a79a90,95%0a> %0a> !!! Development team has different goals%0a> %0a> ZNC developers most likely have no interest in fixing any of the above design flaws. You are better off forking the psyBNC code yourself and fixing what needs to be done.%0a> %0a> psyBNC may not be complete, but at least we can fork it and design it correctly.%0a\ No newline at end of file%0a
022
2023-01-22
jrmu
host:1649135234=38.87.162.154
023
2023-01-22
jrmu
author:1615258176=jrmu
024
2023-01-22
jrmu
diff:1615258176:1615258154:=89c89%0a%3c ZNC modules often fall into the category of 1) not useful 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.%0a---%0a> 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.%0a
025
2023-01-22
jrmu
host:1615258176=198.251.81.119
026
2023-01-22
jrmu
author:1615258154=jrmu
027
2023-01-22
jrmu
diff:1615258154:1615258132:=85c85%0a%3c 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. This setup is too complex and confusing for normal people to follow.%0a---%0a> 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.%0a
028
2023-01-22
jrmu
host:1615258154=198.251.81.119
029
2023-01-22
jrmu
author:1615258132=jrmu
030
2023-01-22
jrmu
diff:1615258132:1615258104:=93,95c93%0a%3c ZNC developers most likely have no interest in fixing any of the above design flaws. You are better off forking the psyBNC code yourself and fixing what needs to be done.%0a%3c %0a%3c psyBNC may not be complete, but at least we can fork it and design it correctly.%0a\ No newline at end of file%0a---%0a> ZNC developers most likely have no interest in fixing any of the above design flaws. You are better off forking the psyBNC code yourself and fixing what needs to be done.%0a\ No newline at end of file%0a
031
2023-01-22
jrmu
host:1615258132=198.251.81.119
032
2023-01-22
jrmu
author:1615258104=jrmu
033
2023-01-22
jrmu
diff:1615258104:1615257891:=23,24c23,24%0a%3c The throttling is done poorly -- each connection is attempted and throttled serially, even if the networks being connected to are different. These connections should be done in parallel rather than serially. For example, if you have 30 independent networks to connect to and a 30 second throttling delay, it would take 15 minutes with ZNC, but it should only take 5 seconds with a proper bouncer that connects to all 30 networks simultaneously (no need to throttle because they are all unique). On a ZNC server with 1000 users, it can take hours (maybe days) just to connect.%0a%3c %0a---%0a> The throttling is done poorly -- each connection is attempted and throttled serially, even if the networks being connected to are different. These connections should be done in parallel rather than serially. For example, if you have 30 independent networks to connect to and a 30 second throttling delay, it would take 15 minutes with ZNC, but it should only take 5 seconds with a proper bouncer that connects to all 30 networks simultaneously (no need to throttle because they are all unique). On a ZNC server with 1000 users with 10 networks each, and 30 seconds of throttling, we are talking about a startup time of 5000 minutes; more than 3 days would elapse to get connected!%0a> %0a31,34c31,34%0a%3c When someone is GLINEd, ZNC tries to reconnect every minute, causing everyone to suffer from connection throttling, even if they are not GLINEd.%0a%3c %0a%3c !!! Upon disconnect, ZNC loses all messages%0a%3c %0a---%0a> When someone is GLINEd, ZNC stupidly tries to reconnect every minute, causing everyone to suffer from connection throttling, even if they are not GLINEd.%0a> %0a> !!! Upon disconnect, znc loses all messages%0a> %0a39,40c39,40%0a%3c ZNC chose to adopt IRCv3, an unnecessary protocol which 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.%0a%3c %0a---%0a> 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.%0a> %0a53,54c53,54%0a%3c 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.%0a%3c %0a---%0a> 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.%0a> %0a57,58c57,58%0a%3c Requesting a ZNC account using a web registration form or a bouncer bot is bad design. Users should be able to register an account instantly upon first connection.%0a%3c %0a---%0a> 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.%0a> %0a93c93,95%0a%3c ZNC developers most likely have no interest in fixing any of the above design flaws. You are better off forking the psyBNC code yourself and fixing what needs to be done.%0a\ No newline at end of file%0a---%0a> 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.%0a> %0a> ZNC is only 50%25 of the way there to a good bouncer. We chose it because it is more polished than psyBNC currently. psyBNC is only 30%25 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.%0a
034
2023-01-22
jrmu
host:1615258104=198.251.81.119
035
2023-01-22
jrmu
author:1615257891=jrmu
036
2023-01-22
jrmu
diff:1615257891:1615257765:=59,62c59,62%0a%3c !!! ZNC has poor security%0a%3c %0a%3c 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.%0a%3c %0a---%0a> !!! ZNC has terrible security%0a> %0a> 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.%0a> %0a66a67,70%0a> !! Debugging is difficult%0a> %0a> There is no way to turn debugging on or off without compiling ZNC from source and restarting ZNC.%0a> %0a73,74c77,78%0a%3c With psybnc, we can use pledge and unveil.%0a%3c %0a---%0a> And chrooting ZNC is a horrible, ugly hack. With psybnc, we can use pledge and unveil.%0a> %0a81c85%0a%3c This accusation was made without a fair trial or ability to appeal. Since the development team is not friendly to our goals, IRCNow should not rely on their software.%0a---%0a> This accusation was made without a fair trial or ability to appeal. Since the development team is not friendly to our goals, we should not rely on their software.%0a
037
2023-01-22
jrmu
host:1615257891=198.251.81.119
038
2023-01-22
jrmu
author:1615257765=jrmu
039
2023-01-22
jrmu
diff:1615257765:1615257631:=5,6c5,6%0a%3c ZNC requires your IRC client make 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 %3c30%25 of bouncer users know how to do this. If you rely on ZNC, you will lose >70%25 of potential users. ZNC developers have declared they have zero interest in fixing this design flaw.%0a%3c %0a---%0a> ZNC requires your IRC client make 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 %3c30%25 of bouncer users know how to do this. If you rely on ZNC, you will lose >70%25 of potential users. ZNC developers have declared they have zero interest in fixing this design flaw; in fact, they are proud of it.%0a> %0a9,10c9,10%0a%3c If your username is john, your password is secret123, and you want to connect to freenode, your password field needs to be john/freenode:secret123. If you want to connect to dal, your password field needs to be john/dal:secret123. This is an unintuitive way of changing networks. Users don't understand this without 1-2 hours of troubleshooting.%0a%3c %0a---%0a> If your username is john, your password is secret123, and you want to connect to freenode, your password field needs to be john/freenode:secret123. If you want to connect to dal, your password field needs to be john/dal:secret123. Nowhere have I ever seen such a weird and confusing way of changing networks. Nobody understands this until he has spent 1-2 hours of troubleshooting.%0a> %0a13,19c13,19%0a%3c It requires reading far too much documentation in order to use. For example, typing /msg *status help shows a wall of text that only a sysadmin could understand. Jargon like AddTrustedServerFingerprint, ClearAllChannelBuffers, and SetUserBindHost are exposed to users -- words that only a sysadmin could understand after reading through several pages of wikis. As sysadmins, we should configure all this for the end-user so the end-user does not have to read a single page of documentation.%0a%3c %0a%3c !!! ZNC relies on a web panel%0a%3c %0a%3c There are two problems. First, I suspect this web panel cannot be easily customized without recompiling. Secondly, it does not follow the UNIX philosophy of Do One Thing and Do It Well. There is no need to bundle a web server with a bouncer. These should be two separate programs because they deal with two separate protocols/objectives. There is no real need for a webpanel at all. There's nothing in the webpanel that could not be configured and managed by sysadmins on behalf of users.%0a%3c %0a%3c !!! ZNC is written in C++, an inelegant language.%0a---%0a> It requires reading far too much documentation in order to use. For example, typing /msg *status help shows a wall of text that only a sysadmin could understand. You have jargon like AddTrustedServerFingerprint, ClearAllChannelBuffers, and SetUserBindHost -- words that only a sysadmin could understand after reading through several pages of wikis. As sysadmins, we should configure all this for the end-user so the end-user does not have to read a single page of documentation.%0a> %0a> !!! ZNC relies on a confusing web panel%0a> %0a> There are two problems. First, I suspect this web panel cannot be easily customized without recompiling. Secondly, it does not follow the UNIX philosophy of Do One Thing and Do It Well. There is no need to bundle a web server with a bouncer. These should be two separate programs because they deal with two separate protocols/objectives. If you think about the matter critically, you will realize that users don't need a webpanel at all. There's nothing in the webpanel that could not be configured and managed by sysadmins on behalf of users.%0a> %0a> !!! ZNC is written in C++, an ugly and inelegant language.%0a
040
2023-01-22
jrmu
host:1615257765=198.251.81.119
041
2023-01-22
jrmu
author:1615257631=jrmu
042
2023-01-22
jrmu
diff:1615257631:1615257614:=23c23%0a%3c The throttling is done poorly -- each connection is attempted and throttled serially, even if the networks being connected to are different. These connections should be done in parallel rather than serially. For example, if you have 30 independent networks to connect to and a 30 second throttling delay, it would take 15 minutes with ZNC, but it should only take 5 seconds with a proper bouncer that connects to all 30 networks simultaneously (no need to throttle because they are all unique). On a ZNC server with 1000 users with 10 networks each, and 30 seconds of throttling, we are talking about a startup time of 5000 minutes; more than 3 days would elapse to get connected!%0a---%0a> The throttling is done in a very stupid manner -- each connection is attempted and throttled serially, even if the networks being connected to are different. These connections should be done in parallel rather than serially. For example, if you have 30 independent networks to connect to and a 30 second throttling delay, it would take 15 minutes with ZNC, but it should only take 5 seconds with a proper bouncer that connects to all 30 networks simultaneously (no need to throttle because they are all unique). On a ZNC server with 1000 users with 10 networks each, and 30 seconds of throttling, we are talking about a startup time of 5000 minutes; more than 3 days would elapse to get connected!%0a
043
2023-01-22
jrmu
host:1615257631=198.251.81.119
044
2023-01-22
jrmu
author:1615257614=jrmu
045
2023-01-22
jrmu
diff:1615257614:1609035218:=1,4c1,4%0a%3c !! Why we must replace ZNC with psyBNC%0a%3c %0a%3c !!! ZNC requires users set up dozens of connections%0a%3c %0a---%0a> !! Why ZNC is destined for failure%0a> %0a> !!! ZNC requires users set up dozens of confusing connections%0a> %0a7c7%0a%3c !!! ZNC has a confusing way of logging in%0a---%0a> !!! ZNC has an incredibly confusing way of logging in%0a
046
2023-01-22
jrmu
host:1615257614=198.251.81.119
047
2023-01-22
jrmu
author:1609035218=jrmu
048
2023-01-22
jrmu
diff:1609035218:1609035197:=83c83%0a%3c -> 30 January 2020‎ IRCNow removed due to multiple complaints of discrimination and hate activities by its administrators.%0a---%0a> -> 30 January 2020‎ IRCNow removed due to multiple complaints of discrimination and hate activities by its administrators. undo%0a
049
2023-01-22
jrmu
host:1609035218=198.251.81.119
050
2023-01-22
jrmu
author:1609035197=jrmu
051
2023-01-22
jrmu
diff:1609035197:1609035136:=81,85c81%0a%3c In the [[https://wiki.znc.in/index.php?title=Template:Providers/table&action=history|ZNC Providers]] page, IRCNow was falsely accused of being involved with hate activities. %0a%3c %0a%3c -> 30 January 2020‎ IRCNow removed due to multiple complaints of discrimination and hate activities by its administrators. undo%0a%3c %0a%3c This accusation was made without a fair trial or ability to appeal. Since the development team is not friendly to our goals, we should not rely on their software.%0a---%0a> In the [[https://wiki.znc.in/index.php?title=Template:Providers/table&action=history|ZNC Providers]] page, IRCNow was falsely accused of being involved with hate activities. This was made without a fair trial or ability to appeal. Since the development team is not friendly to our goals, we should not rely on their software.%0a
052
2023-01-22
jrmu
host:1609035197=198.251.81.119
053
2023-01-22
jrmu
author:1609035136=jrmu
054
2023-01-22
jrmu
diff:1609035136:1609002418:=79,81d78%0a%3c !!! ZNC treated IRCNow as a hate group%0a%3c %0a%3c In the [[https://wiki.znc.in/index.php?title=Template:Providers/table&action=history|ZNC Providers]] page, IRCNow was falsely accused of being involved with hate activities. This was made without a fair trial or ability to appeal. Since the development team is not friendly to our goals, we should not rely on their software.%0a
055
2023-01-22
jrmu
host:1609035136=198.251.81.119
056
2023-01-22
jrmu
author:1609002418=jrmu
057
2023-01-22
jrmu
diff:1609002418:1608203706:=45a46,54%0a> %0a> !!! ZNC segfaults on OpenBSD when the bindhost is IPv6 but the network is IPv4 only%0a> %0a> If a znc user has a bindhost that is IPv6 only but the network is IPv4 only, it will segfault: %0a> %0a> TDNS: initiating resolving of [irc.example.net] and bindhost [user.fruit.ircnow.org]%0a> Segmentation fault (core dumped)%0a> %0a> This causes all your users to disconnect!%0a
058
2023-01-22
jrmu
host:1609002418=198.251.81.119
059
2023-01-22
jrmu
author:1608203706=jrmu
060
2023-01-22
jrmu
diff:1608203706:1608203035:=47,54c47,49%0a%3c !!! ZNC segfaults on OpenBSD when the bindhost is IPv6 but the network is IPv4 only%0a%3c %0a%3c If a znc user has a bindhost that is IPv6 only but the network is IPv4 only, it will segfault: %0a%3c %0a%3c TDNS: initiating resolving of [irc.example.net] and bindhost [user.fruit.ircnow.org]%0a%3c Segmentation fault (core dumped)%0a%3c %0a%3c This causes all your users to disconnect!%0a---%0a> !!! ZNC segfaults when the bindhost is IPv6 but the network is IPv4 only%0a> %0a> %0a
061
2023-01-22
jrmu
host:1608203706=198.251.81.119
062
2023-01-22
jrmu
author:1608203035=jrmu
063
2023-01-22
jrmu
diff:1608203035:1601186671:=46,49d45%0a%3c %0a%3c !!! ZNC segfaults when the bindhost is IPv6 but the network is IPv4 only%0a%3c %0a%3c %0a
064
2023-01-22
jrmu
host:1608203035=198.251.81.119
065
2023-01-22
jrmu
author:1601186671=jrmu
066
2023-01-22
jrmu
diff:1601186671:1599194194:=40,41d39%0a%3c %0a%3c In another documented bug with ZNC, [[https://docs.inspircd.org/faq/#why-does-my-client-not-show-mode-changesopped-users-on-joinetc-correctly-when-using-inspircd-v3|mode changes]] don't show up properly on InspIRCd v3.%0a
067
2023-01-22
jrmu
host:1601186671=38.81.163.143
068
2023-01-22
jrmu
author:1599194194=jrmu
069
2023-01-22
jrmu
diff:1599194194:1598784333:=90a91,96%0a> %0a> !! psyBNC is the bouncer of the future%0a> %0a> # Written in C, a UNIX hacker's best friend.%0a> # 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.%0a> # Instead of chroot, we can use OpenBSD's pledge and unveil for greater security.%0a\ No newline at end of file%0a
070
2023-01-22
jrmu
host:1599194194=38.81.163.143
071
2023-01-22
jrmu
author:1598784333=jrmu
072
2023-01-22
jrmu
diff:1598784333:1598784317:minor=35c35%0a%3c ZNC loses all its messages if you are ddosed while away, or even if there is a simple brief 10 minute hiccup in networking. When this happens, '''every single message is lost'''.%0a---%0a> ZNC loses all its messages if you are ddosed while away, or even if there is a simple brief 10 minute hiccup in networking. When this happens, '''every single message is lost'''. Nothing is cached to disk.%0a
073
2023-01-22
jrmu
host:1598784333=38.81.163.143
074
2023-01-22
jrmu
author:1598784317=jrmu
075
2023-01-22
jrmu
diff:1598784317:1597806344:=32,35d31%0a%3c %0a%3c !!! Upon disconnect, znc loses all messages%0a%3c %0a%3c ZNC loses all its messages if you are ddosed while away, or even if there is a simple brief 10 minute hiccup in networking. When this happens, '''every single message is lost'''. Nothing is cached to disk.%0a
076
2023-01-22
jrmu
host:1598784317=38.81.163.143
077
2023-01-22
jrmu
author:1597806344=jrmu
078
2023-01-22
jrmu
diff:1597806344:1597806299:=15,17c15%0a%3c !!! ZNC relies on a confusing web panel%0a%3c %0a%3c There are two problems. First, I suspect this web panel cannot be easily customized without recompiling. Secondly, it does not follow the UNIX philosophy of Do One Thing and Do It Well. There is no need to bundle a web server with a bouncer. These should be two separate programs because they deal with two separate protocols/objectives. If you think about the matter critically, you will realize that users don't need a webpanel at all. There's nothing in the webpanel that could not be configured and managed by sysadmins on behalf of users.%0a---%0a> !!! ZNC relies on a web panel. There are two problems. First, I suspect this web panel cannot be easily customized without recompiling. Secondly, it does not follow the UNIX philosophy of Do One Thing and Do It Well. There is no need to bundle a web server with a bouncer. These should be two separate programs because they deal with two separate protocols/objectives. If you think about the matter critically, you will realize that users don't need a webpanel at all. There's nothing in the webpanel that could not be configured and managed by sysadmins on behalf of users.%0a
079
2023-01-22
jrmu
host:1597806344=38.81.163.143
080
2023-01-22
jrmu
author:1597806299=jrmu
081
2023-01-22
jrmu
diff:1597806299:1597806078:=58,83c58,64%0a%3c %0a%3c !! Debugging is difficult%0a%3c %0a%3c There is no way to turn debugging on or off without compiling ZNC from source and restarting ZNC.%0a%3c %0a%3c !!! ZNC's blockuser module may be buggy%0a%3c %0a%3c 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.%0a%3c %0a%3c !!! ZNC can't be made secure without chroot%0a%3c %0a%3c And chrooting ZNC is a horrible, ugly hack. With psybnc, we can use pledge and unveil.%0a%3c %0a%3c %0a%3c !!! Confusing mobile support%0a%3c %0a%3c 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.%0a%3c %0a%3c !!! No open source push notifications%0a%3c %0a%3c 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.%0a%3c %0a%3c !!! Development team has different goals%0a%3c %0a%3c 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.%0a%3c %0a---%0a> - There is no way to turn debugging on or off without compiling ZNC from source and restarting ZNC.%0a> - 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.%0a> - Chrooting ZNC is a horrible, ugly hack.%0a> - 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.%0a> - 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.%0a> - 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.%0a> %0a86,90c67,71%0a%3c !! psyBNC is the bouncer of the future%0a%3c %0a%3c # Written in C, a UNIX hacker's best friend.%0a%3c # 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.%0a%3c # Instead of chroot, we can use OpenBSD's pledge and unveil for greater security.%0a\ No newline at end of file%0a---%0a> ====== psyBNC is the bouncer of the future ======%0a> %0a> - Written in C, a UNIX hacker's best friend.%0a> - 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.%0a> - Instead of chroot, we can use OpenBSD's pledge and unveil for greater security.%0a\ No newline at end of file%0a
082
2023-01-22
jrmu
host:1597806299=38.81.163.143
083
2023-01-22
jrmu
author:1597806078=jrmu
084
2023-01-22
jrmu
diff:1597806078:1597806026:=51,57c51,52%0a%3c !!! ZNC has terrible security%0a%3c %0a%3c 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.%0a%3c %0a%3c !!! ZNC's [[https://wiki.znc.in/Partyline|Partyline]] module is buggy%0a%3c %0a%3c When users are connected to multiple networks, messages often 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.%0a---%0a> !!! 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.%0a> - 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.%0a
085
2023-01-22
jrmu
host:1597806078=38.81.163.143
086
2023-01-22
jrmu
author:1597806026=jrmu
087
2023-01-22
jrmu
diff:1597806026:1597805834:=38,51c38,41%0a%3c %0a%3c !!! ZNC module relies on commands not supported on all IRCds%0a%3c %0a%3c The 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 %3cpassword>; for DALnet, the proper command is /msg nickserv@services.dal.net identify %3cpassword>. This really does not need to be an optional module; it needs to be integrated into the bouncer.%0a%3c %0a%3c !!! ZNC does not offer any easy way to download chat logs%0a%3c %0a%3c 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.%0a%3c %0a%3c !!! ZNC has no way to register instantly upon connection%0a%3c %0a%3c 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.%0a%3c %0a%3c !!! 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.%0a---%0a> - 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 %3cpassword>; for DALnet, the proper command is /msg nickserv@services.dal.net identify %3cpassword>. This really does not need to be an optional module; it needs to be integrated into the bouncer.%0a> - 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.%0a> - 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.%0a> - 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.%0a
088
2023-01-22
jrmu
host:1597806026=38.81.163.143
089
2023-01-22
jrmu
author:1597805834=jrmu
090
2023-01-22
jrmu
diff:1597805834:1597805755:=22d21%0a%3c %0a26d24%0a%3c %0a35,37c33%0a%3c !!! ZNC can't prefer IPv6 by default%0a%3c %0a%3c If you try to support both IPv4 and IPv6 simultaneously, ZNC will not prefer IPv6 when available, and there is no way to fix this currently short of a custom patch. 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.%0a---%0a> - 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.%0a
091
2023-01-22
jrmu
host:1597805834=38.81.163.143
092
2023-01-22
jrmu
author:1597805755=jrmu
093
2023-01-22
jrmu
diff:1597805755:1597805722:=29,32c29%0a%3c !!! ZNC adopts a protocol that introduces new bugs without new features%0a%3c %0a%3c 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.%0a%3c %0a---%0a> !!! 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.%0a
094
2023-01-22
jrmu
host:1597805755=38.81.163.143
095
2023-01-22
jrmu
author:1597805722=jrmu
096
2023-01-22
jrmu
diff:1597805722:1597805651:=22,29c22,24%0a%3c !!! ZNC will disconnect users and throttle if SSL certs are not properly signed%0a%3c %0a%3c If a server doesn't have a properly signed SSL cert, ZNC will disconnect until the user adds the SSL fingerprint manually. This confuses >90%25 of users. They always blame our bouncer for not working properly. To make matters worse, ZNC then insists upon reconnecting every minute or so and failing in the same manner. And because ZNC does connection throttling, this slows everyone from being able to connect. You as a sysadmin are forced to manually disconnect networks that have SSL certs that aren't properly signed, or else in a few weeks, your ZNC becomes so slow (due to all the throttling) that it takes >10 mins to connect.%0a%3c !!! ZNC throttles everyone if someone is glined%0a%3c %0a%3c When someone is GLINEd, ZNC stupidly tries to reconnect every minute, causing everyone to suffer from connection throttling, even if they are not GLINEd.%0a%3c %0a%3c !!! 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.%0a---%0a> - If a server doesn't have a properly signed SSL cert, ZNC will disconnect until the user adds the SSL fingerprint manually. This confuses >90%25 of users. They always blame our bouncer for not working properly. To make matters worse, ZNC then insists upon reconnecting every minute or so and failing in the same manner. And because ZNC does connection throttling, this slows everyone from being able to connect. You as a sysadmin are forced to manually disconnect networks that have SSL certs that aren't properly signed, or else in a few weeks, your ZNC becomes so slow (due to all the throttling) that it takes >10 mins to connect.%0a> - 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.%0a> - 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.%0a
097
2023-01-22
jrmu
host:1597805722=38.81.163.143
098
2023-01-22
jrmu
author:1597805651=jrmu
099
2023-01-22
jrmu
diff:1597805651:1597805603:=16,21c16,17%0a%3c %0a%3c !!! ZNC is written in C++, an ugly and inelegant language.%0a%3c %0a%3c !!! ZNC throttles users so it can take hours to connect%0a%3c %0a%3c The throttling is done in a very stupid manner -- each connection is attempted and throttled serially, even if the networks being connected to are different. These connections should be done in parallel rather than serially. For example, if you have 30 independent networks to connect to and a 30 second throttling delay, it would take 15 minutes with ZNC, but it should only take 5 seconds with a proper bouncer that connects to all 30 networks simultaneously (no need to throttle because they are all unique). On a ZNC server with 1000 users with 10 networks each, and 30 seconds of throttling, we are talking about a startup time of 5000 minutes; more than 3 days would elapse to get connected!%0a---%0a> - ZNC is written in C++, an ugly and inelegant language.%0a> - ZNC throttles users when you first start up ZNC and connect everyone. However, the throttling is done in a very stupid manner -- each connection is attempted and throttled serially, even if the networks being connected to are different. These connections should be done in parallel rather than serially. For example, if you have 30 independent networks to connect to and a 30 second throttling delay, it would take 15 minutes with ZNC, but it should only take 5 seconds with a proper bouncer that connects to all 30 networks simultaneously (no need to throttle because they are all unique). On a ZNC server with 1000 users with 10 networks each, and 30 seconds of throttling, we are talking about a startup time of 5000 minutes; more than 3 days would elapse to get connected!%0a
100
2023-01-22
jrmu
host:1597805651=38.81.163.143
101
2023-01-22
jrmu
author:1597805603=jrmu
102
2023-01-22
jrmu
diff:1597805603:1597415298:=1,15c1,6%0a%3c !! Why ZNC is destined for failure%0a%3c %0a%3c !!! ZNC requires users set up dozens of confusing connections%0a%3c %0a%3c ZNC requires your IRC client make 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 %3c30%25 of bouncer users know how to do this. If you rely on ZNC, you will lose >70%25 of potential users. ZNC developers have declared they have zero interest in fixing this design flaw; in fact, they are proud of it.%0a%3c %0a%3c !!! ZNC has an incredibly confusing way of logging in%0a%3c %0a%3c If your username is john, your password is secret123, and you want to connect to freenode, your password field needs to be john/freenode:secret123. If you want to connect to dal, your password field needs to be john/dal:secret123. Nowhere have I ever seen such a weird and confusing way of changing networks. Nobody understands this until he has spent 1-2 hours of troubleshooting.%0a%3c %0a%3c !!! ZNC is not designed for casual users%0a%3c %0a%3c It requires reading far too much documentation in order to use. For example, typing /msg *status help shows a wall of text that only a sysadmin could understand. You have jargon like AddTrustedServerFingerprint, ClearAllChannelBuffers, and SetUserBindHost -- words that only a sysadmin could understand after reading through several pages of wikis. As sysadmins, we should configure all this for the end-user so the end-user does not have to read a single page of documentation.%0a%3c %0a%3c !!! ZNC relies on a web panel. There are two problems. First, I suspect this web panel cannot be easily customized without recompiling. Secondly, it does not follow the UNIX philosophy of Do One Thing and Do It Well. There is no need to bundle a web server with a bouncer. These should be two separate programs because they deal with two separate protocols/objectives. If you think about the matter critically, you will realize that users don't need a webpanel at all. There's nothing in the webpanel that could not be configured and managed by sysadmins on behalf of users.%0a---%0a> ====== Why ZNC is destined for failure ======%0a> %0a> - 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 %3c30%25 of bouncer users know how to do this. If you rely on ZNC, you will lose >70%25 of potential users. ZNC developers have declared they have zero interest in fixing this design flaw; in fact, they are proud of it.%0a> - ZNC has invented the most confusing way of logging in. If your username is john, your password is secret123, and you want to connect to freenode, your password field needs to be john/freenode:secret123. If you want to connect to dal, your password field needs to be john/dal:secret123. Nowhere have I ever seen such a weird and confusing way of changing networks. Nobody understands this until he has spent 1-2 hours of troubleshooting.%0a> - ZNC is not designed for casual users. It requires reading far too much documentation in order to use. For example, typing /msg *status help shows a wall of text that only a sysadmin could understand. You have jargon like AddTrustedServerFingerprint, ClearAllChannelBuffers, and SetUserBindHost -- words that only a sysadmin could understand after reading through several pages of wikis. As sysadmins, we should configure all this for the end-user so the end-user does not have to read a single page of documentation.%0a> - ZNC relies on a web panel. There are two problems. First, I suspect this web panel cannot be easily customized without recompiling. Secondly, it does not follow the UNIX philosophy of Do One Thing and Do It Well. There is no need to bundle a web server with a bouncer. These should be two separate programs because they deal with two separate protocols/objectives. If you think about the matter critically, you will realize that users don't need a webpanel at all. There's nothing in the webpanel that could not be configured and managed by sysadmins on behalf of users.%0a
103
2023-01-22
jrmu
host:1597805603=38.81.163.143
104
2023-01-22
jrmu
author:1597415298=jrmu
105
2023-01-22
jrmu
diff:1597415298:1597415298:=1,31d0%0a%3c ====== Why ZNC is destined for failure ======%0a%3c %0a%3c - 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 %3c30%25 of bouncer users know how to do this. If you rely on ZNC, you will lose >70%25 of potential users. ZNC developers have declared they have zero interest in fixing this design flaw; in fact, they are proud of it.%0a%3c - ZNC has invented the most confusing way of logging in. If your username is john, your password is secret123, and you want to connect to freenode, your password field needs to be john/freenode:secret123. If you want to connect to dal, your password field needs to be john/dal:secret123. Nowhere have I ever seen such a weird and confusing way of changing networks. Nobody understands this until he has spent 1-2 hours of troubleshooting.%0a%3c - ZNC is not designed for casual users. It requires reading far too much documentation in order to use. For example, typing /msg *status help shows a wall of text that only a sysadmin could understand. You have jargon like AddTrustedServerFingerprint, ClearAllChannelBuffers, and SetUserBindHost -- words that only a sysadmin could understand after reading through several pages of wikis. As sysadmins, we should configure all this for the end-user so the end-user does not have to read a single page of documentation.%0a%3c - ZNC relies on a web panel. There are two problems. First, I suspect this web panel cannot be easily customized without recompiling. Secondly, it does not follow the UNIX philosophy of Do One Thing and Do It Well. There is no need to bundle a web server with a bouncer. These should be two separate programs because they deal with two separate protocols/objectives. If you think about the matter critically, you will realize that users don't need a webpanel at all. There's nothing in the webpanel that could not be configured and managed by sysadmins on behalf of users.%0a%3c - ZNC is written in C++, an ugly and inelegant language.%0a%3c - ZNC throttles users when you first start up ZNC and connect everyone. However, the throttling is done in a very stupid manner -- each connection is attempted and throttled serially, even if the networks being connected to are different. These connections should be done in parallel rather than serially. For example, if you have 30 independent networks to connect to and a 30 second throttling delay, it would take 15 minutes with ZNC, but it should only take 5 seconds with a proper bouncer that connects to all 30 networks simultaneously (no need to throttle because they are all unique). On a ZNC server with 1000 users with 10 networks each, and 30 seconds of throttling, we are talking about a startup time of 5000 minutes; more than 3 days would elapse to get connected!%0a%3c - If a server doesn't have a properly signed SSL cert, ZNC will disconnect until the user adds the SSL fingerprint manually. This confuses >90%25 of users. They always blame our bouncer for not working properly. To make matters worse, ZNC then insists upon reconnecting every minute or so and failing in the same manner. And because ZNC does connection throttling, this slows everyone from being able to connect. You as a sysadmin are forced to manually disconnect networks that have SSL certs that aren't properly signed, or else in a few weeks, your ZNC becomes so slow (due to all the throttling) that it takes >10 mins to connect.%0a%3c - 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.%0a%3c - 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.%0a%3c - 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.%0a%3c - 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 %3cpassword>; for DALnet, the proper command is /msg nickserv@services.dal.net identify %3cpassword>. This really does not need to be an optional module; it needs to be integrated into the bouncer.%0a%3c - 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.%0a%3c - 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.%0a%3c - 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.%0a%3c - 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.%0a%3c - There is no way to turn debugging on or off without compiling ZNC from source and restarting ZNC.%0a%3c - 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.%0a%3c - Chrooting ZNC is a horrible, ugly hack.%0a%3c - 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.%0a%3c - 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.%0a%3c - 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.%0a%3c %0a%3c ZNC is only 50%25 of the way there to a good bouncer. We chose it because it is more polished than psyBNC currently. psyBNC is only 30%25 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.%0a%3c %0a%3c ====== psyBNC is the bouncer of the future ======%0a%3c %0a%3c - Written in C, a UNIX hacker's best friend.%0a%3c - 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.%0a%3c - Instead of chroot, we can use OpenBSD's pledge and unveil for greater security.%0a\ No newline at end of file%0a
106
2023-01-22
jrmu
host:1597415298=38.81.163.143
IRCNow