hi guys

i'm using ergo for my chat service on mobile apps, but when it on 2000 concurrent connection the service become slowed down heavily, some user can connect after waiting 2-5 minutes, do i need to adjust config for handling this many connection.

lovin this projects so far 👍

#26 is going to be difficult to implement and may impact our ability to rapidly iterate on experimental IRCv3 features. Meanwhile, we know (#237) that a single oragono instance can scale to approximately 10k clients and 2k clients per channel --- enough for most teams / communities.

Let's explore options for deploying oragono that would be highly available (i.e., resilient to server failure) while maintaining the invariant that at any given time, all clients are connected to a single server (eliminating the need for true s2s). Possible primitives:

1. A load balancer (haproxy?) that elects a single "live" server, then directs all connections to the live server
2. Leader election among the cluster so that only one server is "live", with the others remaining hot spares. This is Hashicorp Vault's model: https://www.vaultproject.io/docs/concepts/ha.html

cc @eklitzke

Hello!

Yesterday I was working on setting up a bridge between Discord and IRC. It uses a Discord bot account, and an IRC account which is connected 24/7 to "relay" the messages. I set the message replay option to 100 messages in ergo, so new users connecting could understand the context.

However whenever the bot reconnects to the server, all of the 100 messages get sent to the relay bot, which starts briding the messages to Discord.

I connected to ergo's irc server yesterday, and asked if there is a command to disable this behavior for a specific user, but it seems like there isn't one implemented currently. This would be my feature request.

Thank you for reading.

When requesting the who list, using the o (oper only) parameter from rfc1459 results in returning all nicks.

C: WHO * o

If the "o" parameter is passed only operators are returned according to the name mask supplied [rfc1459]

Hi,

tl;dr Oragono could have multiple password backends, incl. PAM on UNIXes, libsasl2, or it could talk to LDAP. PAM and libsasl2 are very customizable, but just LDAP would be enough.

PAM and libsasl2 probably require CGo to be acceptable, but hiding this code behind a build-tag is an option.

It would be great if username+password could be checked on a backend separate from the rest.

I run a Samba4 server to serve as a single store of user accounts (both for passwords, and for other generic user account information such as real name).

This is, on my side, used for:

• accounts in Prosody for XMPP,
• accounts in Dovecot for IMAP,
• accounts in Postfix for SMTP,
• provide username+password portion handling for an OAuth2 server,
• log into a Windows with it,
• log into Gerrit
• etc

How?

• Mostly things go straight into checking password via a direct LDAP bind,
• sometimes it's LDAP bind+username lookup+actual LDAP bind for password check
• sometimes things go through PAM towards LDAP,
• sometimes libsasl2 + LDAP (though it could be libsasl2 + PAM + LDAP., not sure).

Gecos fields are also populated from LDAP.

Adding IRC to the mix would be great.

I have no strong opinions about prioritization.

Cloaks should:

• Be integrated with the account registration system
• Have no effect on server operators
• Optionally require a server operator to create?

It would be great to add the option to define a default cloak for every users, which would replace their real hostname. If I am not mistaken, this is similar to the vhost parameter for opers (?). Being able to attribute a custom cloak to an user would be even better.

From #oragono:

What's the expected behaviour when you send a @draft/label tag on a message that doesn't generate a reply (like CAP END or PONG)? The spec implies the server will send an empty batch, but Ora just ignores it.

It's a bit nonsensical to label those, but it's a lot easier to just label all outgoing messages than figure out which are sensible things and which aren't...

I patched out DanielOaks/irc-stress-test#4 for testing purposes and observed that:

1. connectflood scales almost linearly, which is nice
2. Somewhere between 1024 and 4096 clients, chanflood starts to thrash on regenerateMembersCache.

This situation may not be completely avoidable; if there are n consecutive JOINs to the same channel, we actually do have to send O(n^2) JOIN messages. But, worth looking into.

With the nick eskimo registered and esk1mo as a grouped nick that that account, I can't sasl using esk1mo as the username.

Shouldn't any grouped nick also work? I'm fairly certain most networks allow this.

Include a couple more commented-out example opers in the config file, to make it clear how real oper blocks look and how to add more, etc. Doesn't need to be anything too in-depth, just e.g.:

opers:
    # operator named 'admin'; log in with /OPER admin [password]
    admin:
        # which capabilities this oper has access to
        class: "server-admin"

        # custom whois line
        whois-line: is a server admin

        # custom hostname
        vhost: "staff"

        # normally, operator status is visible to unprivileged users in WHO and WHOIS
        # responses. this can be disabled with 'hidden'. ('hidden' also causes the
        # 'vhost' line above to be ignored.)
        hidden: false

        # modes are modes to auto-set upon opering-up. uncomment this to automatically
        # enable snomasks ("server notification masks" that alert you to server events;
        # see `/quote help snomasks` while opered-up for more information):
        #modes: +is acjknoqtuxv

        # operators can be authenticated either by password (with the /OPER command),
        # or by certificate fingerprint, or both. if a password hash is set, then a
        # password is required to oper up (e.g., /OPER dan mypassword). to generate
        # the hash, use `oragono genpasswd`.
        password: "$2a$04$0123456789abcdef0123456789abcdef0123456789abcdef01234"

        # if a SHA-256 certificate fingerprint is configured here, then it will be
        # required to /OPER. if you comment out the password hash above, then you can
        # /OPER without a password.
        #certfp: "abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789"
        # if 'auto' is set (and no password hash is set), operator permissions will be
        # granted automatically as soon as you connect with the right fingerprint.
        #auto: true

    # oper named 'alice': /OPER alice [password]
    #alice:
    #    class: "network-oper"
    #    vhost: "staff/alice"
    #    password: "$2a$04$0123456789abcdef0123456789abcdef0123456789abcdef01234"

    # oper named 'dan': /OPER dan [password]
    #dan:
    #    class: "server-admin"
    #    vhost: "staff/dan"
    #    modes: +is acjknoqtuxv
    #    password: "$2a$04$0123456789abcdef0123456789abcdef0123456789abcdef01234"

Fixes #2020

Calling /msg histserv delete #wrongchan returns spurrious success message. Calling /msg histserv delete returns similar message.

These would lead to the pointer hist == nil, and server.historyDB.DeleteMsgid() would return nil.

Returns errNoSuchChannel or errInvalidTarget if channel or client == nil

Just checked that this works on v2.11.0-rc1

msg histserv delete returns the success message no matter what the two parameters are (it does correctly throw an error if not enough or two many parameters are given).

On latest ergo, the following should all return the same message

msg histserv delete #<channel> <wrong msgid> msg histserv delete #<nonexistent channel> <some msgid> msg histserv delete first second

We got some interest in a config switch that would turn off fakelag for all registered users. This is not safe for most use cases, but would be pretty easy to implement for those operators willing to take the risk.

See #955 for some context. Bouncer reattach that mixes secure and insecure connections has been disallowed ever since the functionality was first built (in c2faeed4b515033a6e1029572b55315f45f010f2). The following year (998ac6928b904f6cab64aec4b8881dd9327fd0ab) we removed the plaintext listener by default.

Ever since, it seems like most errors due to mixing secure and insecure connections are spurious: the connection is actually secure, but is being transported over an incorrectly configured reverse proxy (e.g. WEBIRC is being sent without the secure flag, or a websocket is being proxied without adding X-Forwarded-Proto: https). It may be time to delete this check; we are already pushing operators hard to disable plaintext, and it's not clear what purpose it serves if plaintext is enabled nonetheless (the SASL PLAIN handshake is still being transmitted and acknowledged in plaintext, we just don't allow the reattach).

https://wiki.znc.in/Detaching

Let's investigate how hard this would be. It seems like it should be per-session (but is that how ZNC does it?). One challenge is disconnecting while detached and then reconnecting: you should receive the messages that were played on that channel while you were detached, but your lastseen timestamp will be ahead of this. (Is there a way to do this without maintaining per-channel, per-session lastseen timestamps?)

https://emersion.fr/blog/2022/irc-and-oauth2/

In terms of ergo, all we need to do is:

1. Add a config option (to the auth-script block?) to enable advertising the OAUTHBEARER mechanism
2. Modify authenticateHandler to process OAUTHBEARER by forwarding it to an auth-script
3. Extend the auth-script protocol to take an additional oauthbearer field in the input (the output type is already sufficiently expressive)