znc.in/self-message not working #975

New Issue

2026-10-05T04:56:36+02:00

adam commented

2026-10-05 04:56:36 +02:00

I've ran into a slight issue with znc.in/self-message.

Lately, I've noticed that I'm failing to get messages from myself when I'm receiving playback using the clientbuffer mod. Originally, I noticed this bug because the feature documented here: https://wiki.znc.in/Query_buffers does not work at all on IRC networks running Oragono as an ircd. In addition, something lately has made it so the feature no longer works on Snoonet, but it works on Freenode.

I've tested this using znc 1.8.2 on macOS Mojave, Ubuntu and Fedora with Textual and Palaver as my clients (both of which are listed to support znc.in/self-message)

Steps to reproduce:

Make a fresh ZNC installation (I've chosen 1.8.2 from Ubuntu repositories)
Set up a network (I've chosen Snoonet)
Disable the auto clearing of queries and buffers
Install the clientbuffer mod and configure 2 clients (Mine are Textual and Textual2)
Chat normally on client 1
Connect client 2 and fail to see your own messages

I've ran into a slight issue with znc.in/self-message. Lately, I've noticed that I'm failing to get messages from myself when I'm receiving playback using the clientbuffer mod. Originally, I noticed this bug because the feature documented here: https://wiki.znc.in/Query_buffers does not work at all on IRC networks running Oragono as an ircd. In addition, something lately has made it so the feature no longer works on Snoonet, but it works on Freenode. I've tested this using znc 1.8.2 on macOS Mojave, Ubuntu and Fedora with Textual and Palaver as my clients (both of which are listed to support znc.in/self-message) Steps to reproduce: 1. Make a fresh ZNC installation (I've chosen 1.8.2 from Ubuntu repositories) 2. Set up a network (I've chosen Snoonet) 3. Disable the auto clearing of queries and buffers 4. Install the clientbuffer mod and configure 2 clients (Mine are `Textual` and `Textual2`) 5. Chat normally on client 1 6. Connect client 2 and fail to see your own messages

adam closed this issue

2026-10-05 04:56:36 +02:00

adam commented

2026-10-05 04:56:38 +02:00

Can you show output of znc -D?

пн, 28 дек. 2020 г. в 16:28, AndroidKitKat notifications@github.com:

I've ran into a slight issue with znc.in/self-message.

Lately, I've noticed that I'm failing to get messages from myself when I'm
receiving playback using the clientbuffer mod. Originally, I noticed this
bug because the feature documented here: https://wiki.znc.in/Query_buffers
does not work at all on IRC networks running Oragono as an ircd. In
addition, something lately has made it so the feature no longer works on
Snoonet, but it works on Freenode.

I've tested this using znc 1.8.2 on macOS Mojave, Ubuntu and Fedora with
Textual and Palaver as my clients (both of which are listed to support
znc.in/self-message)

Steps to reproduce:

Make a fresh ZNC installation (I've chosen 1.8.2 from Ubuntu
repositories)

Set up a network (I've chosen Snoonet)

Install the clientbuffer mod and configure 2 clients (Mine are
Textual and Textual2)

Chat normally on client 1

Connect client 2 and fail to see your own messages

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/znc/znc/issues/1773, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACPLZG6Q4IPL4RKE3I3RSLSXCW4HANCNFSM4VMG2HJA
.

Can you show output of `znc -D`? пн, 28 дек. 2020 г. в 16:28, AndroidKitKat <notifications@github.com>: > I've ran into a slight issue with znc.in/self-message. > > Lately, I've noticed that I'm failing to get messages from myself when I'm > receiving playback using the clientbuffer mod. Originally, I noticed this > bug because the feature documented here: https://wiki.znc.in/Query_buffers > does not work at all on IRC networks running Oragono as an ircd. In > addition, something lately has made it so the feature no longer works on > Snoonet, but it works on Freenode. > > I've tested this using znc 1.8.2 on macOS Mojave, Ubuntu and Fedora with > Textual and Palaver as my clients (both of which are listed to support > znc.in/self-message) > > Steps to reproduce: > > 1. Make a fresh ZNC installation (I've chosen 1.8.2 from Ubuntu > repositories) > 2. Set up a network (I've chosen Snoonet) > 3. Install the clientbuffer mod and configure 2 clients (Mine are > Textual and Textual2) > 4. Chat normally on client 1 > 5. Connect client 2 and fail to see your own messages > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <https://github.com/znc/znc/issues/1773>, or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AACPLZG6Q4IPL4RKE3I3RSLSXCW4HANCNFSM4VMG2HJA> > . >

adam commented

2026-10-05 04:56:38 +02:00

@AndroidKitKat you should immediatelly change all your passwords...

@AndroidKitKat you should immediatelly change all your passwords...

adam commented

2026-10-05 04:56:39 +02:00

I see only a single client in that log - textual

I see only a single client in that log - `textual`

adam commented

2026-10-05 04:56:40 +02:00

Haha, I left a ton of sensitive information in there. Thanks for the heads up.

I'm not sure what the issue is, in Clientbuffer, I've got textual and palaver, I guess just in that debug log only Textual connected, not Palaver on my phone. However, I assure you that the issue is happening. How could I get you debug logs that don't accidentally leak my passwords?

Haha, I left a ton of sensitive information in there. Thanks for the heads up. I'm not sure what the issue is, in Clientbuffer, I've got `textual` and `palaver`, I guess just in that debug log only Textual connected, not Palaver on my phone. However, I assure you that the issue is happening. How could I get you debug logs that don't accidentally leak my passwords?

adam commented

2026-10-05 04:56:40 +02:00

How could I get you debug logs that don't accidentally leak my passwords?

By sanitizing your debug output before providing it here. I.E. checking it for your passwords and removing them from the output. There's no way to do a debug log dump without including the passwords, so it's up to you to sanitize your debug logs first before posting them here on GH.

> How could I get you debug logs that don't accidentally leak my passwords? By sanitizing your debug output before providing it here. I.E. checking it for your passwords and removing them from the output. There's no way to do a debug log dump without including the passwords, so it's up to you to sanitize your debug logs first before posting them here on GH.

adam commented

2026-10-05 04:56:41 +02:00

Replace parameters of PASS and AUTHENTICATE with "hunter2"

сб, 2 янв. 2021 г. в 02:58, Thomas Ward notifications@github.com:

How could I get you debug logs that don't accidentally leak my passwords?

By sanitizing your debug output before providing it here. I.E. checking it for your passwords and removing them from the output. There's no way to do a debug log dump without including the passwords, so it's up to you to sanitize your debug logs first before posting them here on GH.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

Replace parameters of PASS and AUTHENTICATE with "hunter2" сб, 2 янв. 2021 г. в 02:58, Thomas Ward <notifications@github.com>: > > How could I get you debug logs that don't accidentally leak my passwords? > > By sanitizing your debug output before providing it here. I.E. checking it for your passwords and removing them from the output. There's no way to do a debug log dump without including the passwords, so it's up to you to sanitize your debug logs first before posting them here on GH. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub, or unsubscribe.

adam commented

2026-10-05 04:56:42 +02:00

I am also experiencing this issue, and have recreated it with znc 1.8.2 compiled from source. I compiled and installed the latest version of the clientbuffer module. While testing I observed:

Clients which express the znc.in/self-message capability receive each others messages reliably when connected
Clients which are offline when a message is sent receive messages from others on reconnect, but not self messages
While testing I was only able to reproduce the issue once on two tests, and had to add a third client to recreate it, this may be related to the problem. The issue always occurs on my primary setup which does have three clients defined.

In this test I exchange a very limited number of messages; the user johnfznctest is connected through the test znc instance, johnf|znc is another user. The client1 user of the johnfznctest user remains connected at all times as does johnf|znc.

07:50 <@johnfznctest> message from client1
07:50 <@johnfznctest> message from client2
07:50 <@johnfznctest> message from client1 after client2 has disconnected
07:51 < johnf|znc> message from a different user
07:54 <@johnfznctest> Message from mobile client
07:55 <@johnfznctest> message from client1 with both client2 and mobile disconnected
07:55 < johnf|znc> message from a different user prior to reconnection

These are the messages as seen by client2 with connect/disconnect messages removed:

07:49 -!- Irssi: Join to #znctest was synced in 7 secs
07:49 -!- johnf|znc [~johnf@155.248.228.224] has joined #znctest
07:50 <@johnfznctest> message from client1
07:50 <@johnfznctest> message from client2
07:50 <@johnfznctest> message from client1 after client2 has disconnected
07:51 < johnf|znc> message from a different user
07:51 -!- Channel #znctest created Sun Dec 18 07:46:21 2022
07:51 -!- Irssi: Join to #znctest was synced in 7 secs
07:54 <@johnfznctest> Message from mobile client
07:55 < johnf|znc> message from a different user prior to reconnection
07:55 -!- Channel #znctest created Sun Dec 18 07:46:21 2022
07:55 -!- Irssi: Join to #znctest was synced in 7 secs

The mobile client, added during the test shortly before "Message from mobile client", only sees the < johnf|znc> message from a different user prior to reconnection.

In these logs we can see the first offline self message being delivered:

[2022-12-18 07:51:18.305809] (admin@client2/libera) ZNC -> CLI [@time=2022-12-18T12:50:53.836Z :johnfznctest!~admin@bras-base-mtrlpq4706w-grc-07-174-93-163-142.dsl.bell.ca PRIVMSG #znctest :message from client1 after client2 has disconnected]
[2022-12-18 07:51:18.305900] (admin@client2/libera) ZNC -> CLI [@time=2022-12-18T12:51:02.951Z :johnf|znc!~johnf@155.248.228.224 PRIVMSG #znctest :message from a different user]

But not the second:

[2022-12-18 07:55:32.308539] (admin@mobile/libera) ZNC -> CLI [@time=2022-12-18T12:55:32.308Z :znc.in BATCH +35d057f0d8693d0528f543abd0f8a1e1 znc.in/playback #znctest]
[2022-12-18 07:55:32.309031] (admin@mobile/libera) ZNC -> CLI [@batch=35d057f0d8693d0528f543abd0f8a1e1;time=2022-12-18T12:55:26.763Z :johnf|znc!~johnf@155.248.228.224 PRIVMSG #znctest :message from a different user prior to reconnection]
[2022-12-18 07:55:32.309196] (admin@mobile/libera) ZNC -> CLI [@time=2022-12-18T12:55:32.309Z :znc.in BATCH -35d057f0d8693d0528f543abd0f8a1e1]

Here's the complete znc-debug-logs.txt; I'm ready to conduct any other tests required to resolve the issue. Thanks in advance for your help!

I am also experiencing this issue, and have recreated it with znc 1.8.2 compiled from source. I compiled and installed the latest version of the [clientbuffer](https://github.com/CyberShadow/znc-clientbuffer.git) module. While testing I observed: - Clients which express the znc.in/self-message capability receive each others messages reliably when connected - Clients which are offline when a message is sent receive messages from others on reconnect, but not self messages - While testing I was only able to reproduce the issue once on two tests, and had to add a third client to recreate it, this may be related to the problem. The issue always occurs on my primary setup which does have three clients defined. In this test I exchange a very limited number of messages; the user johnfznctest is connected through the test znc instance, johnf|znc is another user. The client1 user of the johnfznctest user remains connected at all times as does johnf|znc. ``` 07:50 <@johnfznctest> message from client1 07:50 <@johnfznctest> message from client2 07:50 <@johnfznctest> message from client1 after client2 has disconnected 07:51 < johnf|znc> message from a different user 07:54 <@johnfznctest> Message from mobile client 07:55 <@johnfznctest> message from client1 with both client2 and mobile disconnected 07:55 < johnf|znc> message from a different user prior to reconnection ``` These are the messages as seen by client2 with connect/disconnect messages removed: ``` 07:49 -!- Irssi: Join to #znctest was synced in 7 secs 07:49 -!- johnf|znc [~johnf@155.248.228.224] has joined #znctest 07:50 <@johnfznctest> message from client1 07:50 <@johnfznctest> message from client2 07:50 <@johnfznctest> message from client1 after client2 has disconnected 07:51 < johnf|znc> message from a different user 07:51 -!- Channel #znctest created Sun Dec 18 07:46:21 2022 07:51 -!- Irssi: Join to #znctest was synced in 7 secs 07:54 <@johnfznctest> Message from mobile client 07:55 < johnf|znc> message from a different user prior to reconnection 07:55 -!- Channel #znctest created Sun Dec 18 07:46:21 2022 07:55 -!- Irssi: Join to #znctest was synced in 7 secs ``` The mobile client, added during the test shortly before "Message from mobile client", only sees the < johnf|znc> message from a different user prior to reconnection. In these logs we can see the first offline self message being delivered: ``` [2022-12-18 07:51:18.305809] (admin@client2/libera) ZNC -> CLI [@time=2022-12-18T12:50:53.836Z :johnfznctest!~admin@bras-base-mtrlpq4706w-grc-07-174-93-163-142.dsl.bell.ca PRIVMSG #znctest :message from client1 after client2 has disconnected] [2022-12-18 07:51:18.305900] (admin@client2/libera) ZNC -> CLI [@time=2022-12-18T12:51:02.951Z :johnf|znc!~johnf@155.248.228.224 PRIVMSG #znctest :message from a different user] ``` But not the second: ``` [2022-12-18 07:55:32.308539] (admin@mobile/libera) ZNC -> CLI [@time=2022-12-18T12:55:32.308Z :znc.in BATCH +35d057f0d8693d0528f543abd0f8a1e1 znc.in/playback #znctest] [2022-12-18 07:55:32.309031] (admin@mobile/libera) ZNC -> CLI [@batch=35d057f0d8693d0528f543abd0f8a1e1;time=2022-12-18T12:55:26.763Z :johnf|znc!~johnf@155.248.228.224 PRIVMSG #znctest :message from a different user prior to reconnection] [2022-12-18 07:55:32.309196] (admin@mobile/libera) ZNC -> CLI [@time=2022-12-18T12:55:32.309Z :znc.in BATCH -35d057f0d8693d0528f543abd0f8a1e1] ``` Here's the complete [znc-debug-logs.txt](https://github.com/znc/znc/files/10253956/znc-debug-logs.txt); I'm ready to conduct any other tests required to resolve the issue. Thanks in advance for your help!

adam commented

2026-10-05 04:56:42 +02:00

It's also possible to work around this issue by running znc in the UTC timezone.

If you are using systemd to run znc you can add and Environment setting to the [Service] section of the following to your unit file to adjust the timezone for znc:

[Service]
Environment=TZ=UTC

You'll also need to remove the timestamps from your registry files in your znc settings (look for files named like moddata/clientbuffer/.registry in your znc data directory and remove the entries which aren't the bare names of clients:

mobile
mobile%2f; 1673176082%2e;670472
mobile%2f;%23;linux 1673182342%2e;224166

You can also wait until your local time "catches up" with UTC and then you should start to receive self-messages when clients reconnect.

It's also possible to work around this issue by running znc in the UTC timezone. If you are using systemd to run znc you can add and Environment setting to the `[Service]` section of the following to your unit file to adjust the timezone for znc: ``` [Service] Environment=TZ=UTC ``` You'll also need to remove the timestamps from your registry files in your znc settings (look for files named like `moddata/clientbuffer/.registry` in your znc data directory and remove the entries which aren't the bare names of clients: ``` mobile mobile%2f; 1673176082%2e;670472 mobile%2f;%23;linux 1673182342%2e;224166 ``` You can also wait until your local time "catches up" with UTC and then you should start to receive self-messages when clients reconnect.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#975