Go MessageBox Server v1.5.2 Reduces Identifying Data in Notification Logs

Developer Tools

In Brief

Go MessageBox Server has released version 1.5.2, removing identity keys, message identifiers and device-token fragments from several notification and message-handling logs.

The update reduces the identifying information copied into operational logs while preserving push delivery and useful status information. The developer also documents remaining logging paths that need separate attention.

News Report

Go MessageBox Server v1.5.2 was published on October 20, 2026, at 21:21 UTC. Its release notes include the logging correction merged earlier that evening and a privacy notice added to the project documentation on October 16, 2026 (UTC).

The server stores and delivers messages between BSV identity keys. Its capabilities include authenticated requests, paid delivery and Firebase Cloud Messaging notifications to registered devices, supporting wallet and application services using BSV Blockchain.

How Delivery Logs Could Connect Activity

The previous notification routine logged recipient identity keys and a payload containing message identifiers and sender and recipient information. It also recorded the final ten characters of device-notification tokens.

These identity keys are public identifiers. Recording them alongside delivery events can connect a pseudonymous identity with payment timing. A repeated device-token fragment can provide another way to link activity.

The contribution reports that a production deployment retained the default development setting, enabling informational entries labeled as debugging output. Some identifying entries also used error-level logging, which remained active in production mode.

According to the developer’s account, these logs passed through container and cluster logging into a third-party log store.

What the Release Changes

The updated notification routine removes the recipient and payload debug entries, recipient attributes and token fragments. It retains message-box names, device counts, delivery success and failure counts, and error information.

Message identifiers are also removed from duplicate-message rejection and stored-body encoding-error logs.

The change preserves the notification recipients and payloads. Its practical effect is to reduce the identifying data recorded during delivery.

New regression tests exercise successful and failed notifications, missing devices and device-lookup failures. They check that operational logs still appear while the supplied identity keys, message identifier and device token are absent. Additional tests cover duplicate-message handling and administrator actions.

The contributor reports passing build, test and race checks. Tests requiring live MongoDB and PostgreSQL databases were skipped in that local run.

Remaining Privacy Boundaries

The contribution explicitly leaves two further issues for follow-up: authentication middleware can log a caller’s identity key after certain failures, and a rare MongoDB device-registration error can include an identity key and notification token in its error text.

The default development setting is also unchanged. Version 1.5.2 therefore addresses specific logging paths; it does not establish that every server log is free of identifying information.

The accompanying privacy notice explains a separate boundary. Message content must be encrypted by the sending client. The server stores submitted bodies, including plaintext when clients send plaintext. Operators can still see delivery metadata such as timing, message size and the identity keys exchanging messages.

The published changes do not establish removal of previously retained logs or confirm adoption by every hosted service.

BSV TIMES Read

Operational logs deserve the same privacy scrutiny as an application’s main database. Repeated identifiers can make activity linkable even when message content is encrypted.

This release makes a concrete improvement by removing several unnecessary identifiers while retaining information needed to diagnose delivery failures.

The documented follow-up issues give operators a clearer basis for assessing the remaining work. The benefit depends on services adopting the release and reviewing the wider logging and retention arrangements around their deployment.

Developer Context

Darren Kellenschwiler, known publicly as Deggen and using the GitHub account sirdeggen, submitted both the logging correction and the privacy-notice contribution. His public GitHub profile lists the BSV Association.

His earlier standards work includes coauthoring BRC-85, Proven Identity Key Exchange (PIKE), with Damian Orzepowski.

Source Links

Posted on October 21, 2026 (UTC)