Artem Savkov

> Doesn't matter what workaround we use, none of us want to need it at all. It does. Without the debug logs it is hard to tell what went wrong...

The only place it can be done is client, irssi has the solution for it posted on its [tips'n'tricks page](https://irssi.org/documentation/tips/) ``` /ignore -channels #chan1,#chan2,#chan3 * JOINS PARTS QUITS NICKS /ignore...

bitlbee-discord has no control over what bitlbee returns in response to names requests.

I still think that this is just hiding the problem (frequent disconnects) under the rug, but if you are willing to invest your own time into this I wont stop...

Either irc client's or bouncer's `/ignore` would be my go-to. Neither bitlbee nor bitlbee-discord have filtering capabilities atm. The `block` command you mentioned is supposed to be used to send...

> But it also means the client does receive the message, presumably with some extra metadata to hide it. Too bad it won't work out of the box. If said...

bitlbee-discord doesn't break up messages, so it seems that it is either the irc client or bitlbee who does that. do you happen to know the limit after which the...

According to [RFC](https://tools.ietf.org/html/rfc1459#section-2.3) maximum message length is 510 characters (+CR-LF), bitlbee doesn't seem to split messages, just throws an error if max length is exceeded and it gives you [twice...

Looks like I'll have to implement a message queue and wait for each send to finish before starting the next.

IIRC it was a design decision. With deletes we don't get much new info, so if implemented the same way as edits are we will be just duplicating the message...