hifi / heisenbridge Goto Github PK

As per pip repository, asyncio is now part of the stdlib and thus shouldn't be needed as a dependency.

Disconnect command doesn't know how to cancel the reconnection attempt.

Mostly when in ERROR reconnection loop like being throttled and the connection is closed.

1. Invalidate room
2. Remove puppets (slowly, we're not in a hurry)
3. Leave room
4. Forget room
5. Profit!

This process can be restarted/continued on bridge startup as an invalid room will always be eligible for garbage collection, we just need to avoid leaving it ourselves until all puppets have been kicked.

Hi,

Thanks for Heisenbridge!

The AUTOCMD -h output includes:

Example: AUTOCMD msg [email protected] :auth foo bar

This is a bit confusing, and the msg syntax wasn't working for me. I had to use this for a Nickserv network:

AUTOCMD PRIVMSG nickserv :identify mynick mypassword

So, PRIVMSG instead of msg, and no @... as part of the nick.

Seems the irc library generates a ctcp and action event from actions and we only handle the ctcp one.

Possibly prepend the message with the original sender so it looks somewhat follow-able on IRC?

It's a bit of a mystery how connection cleanup should be done in all of the cases a connection is being closed.

Needs to be investigated.

Some networks like QuakeNet really dislike a lot of connection attempts at the same time and start to throttle. Currently there is no backoff for ERROR disconnects and it will reconnect in 10 seconds

Implement backoff and some randomization so all bridge users won't connect at the same time.

Need a per connection queue with a timer and a penalty system to allow bursting but not so much to cause an excess flood.

Priority commands should be possible to LIFO.

I would like to have Heisenbridge automatically giving ops (or voices in some cases) to users whose hostmasks I specify especially in IRCnet where there is no ChanServ. I think it should have option for width to either do it on specific channels or in case the hostmask belongs to user themself on all channels.

This removes the need to add or remove puppets from the member list list prematurely which should fix ghosting.

I don't have exact raw IRC logs but I've seen people who have joined and left and then rejoined immediately again or changed nicks may have been left out.

This may be that the members of a room are inconsistently managed by hand and not reacted to Matrix events, possibly.

It seems the underlying IRC library does not do its own PING/PONG if the connection is idle. This inhibits an unwanted behavior of the socket disconnecting only when the user initiates an action that sends something over the socket.

This should probably be part of either HeisenConnection or HeisenReactor.

ZWSP is a zero-width space and having it in the messages sent by the relaybot would avoid pinging users on IRC when they have the same nick on both sides. E.g. on the main room I am @mikaela:feneas.org and on LiberaChat I am Mikaela so I get pinged whenever I say something at Matrix.

I would like the bot to refer to me as @mZWSPikaela:fZWSPeneas.org, so I wouldn't get pinged even if my MXID contained my domain (I would likely be @mikaela:mikaela.info if I was running my own homeserver and such MXIDs aren't uncommon).

We know our own sockets well enough we can actually work as an identd service.

It will increase throughput while preserving order where it matters.

This makes it more inline with IRC clients like irssi and weechat where messages from all networks are shown in the status window.

This is a major refactor but doable.

It would look a lot better if everyone who are on a channel show up "online" rather than "unavailable". We can update the presence status to "offline" if we see a client quit but it's really a best effort as it's only visible to you if that happens on a channel you're in.

The very least we should set all users online that we know are currently on a channel. This can be flushed through a slow background queue.

Sometimes the server rejects the reply. Need to investigate why.

If our requests to HS start failing in numbers redo the initial connection dance and send NAMES to all channels once we have reconnected.

This ensures we are in sync between IRC and Matrix.

Example modes: +ntk foo

On some networks, for instance, I'd send MODE mynick +R to prevent myself from getting spam. It would be great to be able to send more than one command on connect (beyond just the one to identify to nickserv). Thanks!

Group rooms into spaces

It'd be nice to have a way to silence stuff like this on a per channel basis:

Heisenbridge MrLees changed the topic
Heisenbridge xeeder_ is changing nick to xeeder
Heisenbridge blahbot set modes +v l3uddz

thanks!

I know that @hifi has mentioned he wants things to stabilize a bit before this.

It would be especially helpful for packagers. For example, NixOS currently has the version set to unstable-2021-05-23 (https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/heisenbridge/default.nix#L5)

And add WHOIS command.

identd response doesn't work for federated users.

Don't complain about everything, use more strict addressing

From Matrix to IRC It depends on the client what the unformatted message field contains. Element puts in the display name of the target and FluffyChat the Matrix ID. We need to try to find all Matrix ID refs and replace them with the IRC nick that was intended by the user.

From IRC to Matrix we need to at least map IRC->IRC mentions automatically for readability and IRC->Matrix made configurable.

https://matrix.org/docs/spec/appendices#mapping-from-other-character-sets

Related to mxid's such as @irc_libera.chat_peetz1r`:c.glitch.im and @irc_libera.chat_peetz1r[m]:c.glitch.im when someone on IRC is named Peetz1r` or Peetz1r[m] or such.

Synapse supports registering new puppets with historical id's but Conduit does not.

When using znc to act as the intermediary to the actual IRC network, if you type something from one of the other connected actual IRC clients to znc, the message shows back in heisenbridge/matrix fine but shows up as coming from username![email protected] instead of "me" or a virtual user shortname

On other clients it ends up filling in as having come from "me"

This is really just a cosmetic fix, as the message does come back and it's obvious in matrix that something was written on another connection on znc.

Currently only network room has this enabled, it needs to be per-source so if for example you get a flood from a user or a service (like NickServ) it gets nicely bundled up in bigger chunks that are faster to send over-the-wire than individual messages. It will still preserve order so it works great.

Current bundle time is hardcoded to 200ms but it could be configurable by the bridge owner to fine tune bulk performance and reponsiveness.

I'm not 100% certain this is the case why some room states were lost on the lab instance before but I suspect room and appservice save() needs to do a few things:

• use an async lock to have only one save in-flight, wait for the lock, saving multiple times isn't too bad but losing data is
• initiate save (PUT account data) and capture exceptions/errors
• retry if we get any error, there is no condition where failing to save would be okay
• load back what we saved
• compare it with what we have, save again if it's off, log the issue

It does a request to /_synapse/admin/v1/users/@heisenbridge:c.glitch.im/admin here which looks like it should work fine when that call fails.

But in reality, when the call is done against Conduit, it tries anyway for half an hour because of this loop

May 28 00:07:28 niks systemd[1]: Started heisenbridge.service.
May 28 00:07:31 niks python[11225]: DEBUG:asyncio:Using selector: EpollSelector
May 28 00:07:31 niks python[11225]: INFO:root:We are @heisenbridge:c.glitch.im
May 28 00:07:31 niks python[11225]: DEBUG:root:Default config: {'networks': {}, 'owner': None, 'allow': {}}
May 28 00:07:31 niks python[11225]: WARNING:root:Request to HS failed, assuming it is down, retry 1/60...
May 28 00:08:01 niks python[11225]: WARNING:root:Request to HS failed, assuming it is down, retry 2/60...
May 28 00:08:31 niks python[11225]: WARNING:root:Request to HS failed, assuming it is down, retry 3/60...
May 28 00:09:01 niks python[11225]: WARNING:root:Request to HS failed, assuming it is down, retry 4/60...

(I will keep this running for another 28 minutes and see what happens)

No default

Currently Heisenbridge (or the lab) doesn't seem to be running an identd so networks that care about it prefix an ~ in front of the username.

I think it should support getting/sending responses through oidentd forwarding for a couple of reasons:

• Oidentd is a well known service that is easy to setup and runs on the ident port 113 without the need or figuring out how to give Heisenbridge access to a privileged port.
• Traditional IRC networks generally care about ident and require it to exist and be unchanging before granting out connection limit increases or I-lines or whatever you wish to call them as.
  • Last, but not least, even without those, IRC networks generally grant more connections to hosts that have identd running, for example Solanum IRCd which Libera.Chat uses and IRCnet (judging by some of their MOTDs).

I have no idea how ident works other than using TCP port 113 and particularly IRCnet letting you faster in if you either have it or block it by rejecting traffic to it in firewall, but maybe some of these links could be of help:

• oidentd homepage: https://oidentd.janikrabe.com/
  • documentation on forwarding: https://janikrabe.com/projects/oidentd/docs/nat/forwarding/
• TheLounge (webIRC client) documentation on this: https://thelounge.chat/docs/guides/identd-and-oidentd#using-oidentd-to-forward-requests-to-the-built-in-server
• TheLounge PR bringing their feature in: https://github.com/thelounge/thelounge/pull/804/files (warning: it may be more recent in the actual codebase and is in NodeJS which I don't speak)

Some people may want different prefixes than @irc_, so it shouldn't be hardcoded. Parsing the regex from the registration file (e.g. user id prefix = text before .+ or .* in regex) is probably the best solution if you don't want to add any other config.

Currently it's possible to throw a connection error which will cause a lot more issues.

Properly and not linking to a text file

When using conduit, the bridge needs to register itself, if it doesn't the /whoami will fail with M_FORBIDDEN

I worked around this by manually registering like this:

curl -v -H 'Authorization: Bearer (the as_token)' 'http://[::1]:6167/_matrix/client/r0/register' -d '{"type": "m.login.application_service", "username": "heisenbridge"}'

But the bridge should do this before the whoami call.