Go MessageBox Server v1.6.0 Adds Purchase Verification for Custom Handles

Wallets & Identity / Developer Tools

In Brief

Go MessageBox Server has released version 1.6.0 with optional App Store and Google Play subscription verification for custom wallet handles.

The update lets a server confirm a purchase with the store, associate one subscription with one held handle, and release handles after subscriptions lapse. Enforcement is disabled by default, while handles matching the wallet’s generated-name pattern remain free.

News Report

The project published v1.6.0 on October 24, 2026, at 03:52 UTC as a regular GitHub release. Its principal feature, introduced through pull request #55, adds purchase verification and subscription management to the server’s existing handle registry.

Go MessageBox Server stores and delivers messages between BSV identity keys. Its optional paymail profile service maps an address such as handle@domain to an identity key and a self-signed profile certificate. The new subscription checks govern registration of custom names within that service.

Store Confirmation Before Registration

When purchase enforcement is enabled, a new custom-handle registration must include purchase information alongside the signed profile certificate. The server checks the transaction or purchase token with Apple’s or Google’s server API, including whether the subscription belongs to the configured application and grants access.

The verified product must also match the handle’s length tier. The implementation defines separate tiers for one through six characters, with a seventh tier covering seven or more. Version 1.6.0 expands permitted handle lengths from 3–32 to 1–32 characters, retaining the registry’s other naming restrictions.

Names matching the wallet’s adjective–animal–two-digit pattern, such as ableotter07, remain available without a subscription. Updating or releasing a handle already held by the same identity key does not require another purchase submission.

A subscription can pay for only one held handle at a time. It can be reassigned after the identity key no longer holds the previous handle. The server returns distinct errors for missing or inactive subscriptions, mismatched tiers, purchases already in use and an unavailable store service.

Renewals and Lapsed Handles

Apple and Google subscription notifications prompt the server to retrieve the subscription’s current state from the store. The notification itself does not determine whether access continues.

An hourly process also rechecks subscriptions before releasing lapsed handles. By default, a handle becomes eligible for release when its subscription’s expiry is more than 14 days in the past and the store no longer grants access. Operators can configure that interval.

The store’s own billing grace period preserves access while it remains active. The server’s 14-day interval counts from subscription expiry, rather than being added after the store’s grace period ends. Canceling renewal still leaves access in place through the paid period.

If the store cannot be reached during a lapse check, the server defers release. Once a handle is released for a lapsed subscription, there is no additional reservation period: the former holder or another user can claim it again.

Optional Deployment, With Store Testing Outstanding

Operators must explicitly enable purchase enforcement and configure the paymail registry, MongoDB storage and at least one supported store. Installing the release alone does not activate paid-handle requirements.

The developer reports automated tests covering purchase acceptance and rejection, receipt reuse, handle changes, notifications and expiry handling, including tests against real MongoDB storage. Store responses in the purchase tests use simulated APIs and fixture receipts.

The pull request explicitly records that end-to-end sandbox purchases against the real Apple and Google APIs were not performed. The published release establishes the availability of the server implementation; it does not establish that a hosted wallet service has enabled it.

BSV TIMES Read

The change gives operators a way to connect custom-name registration with billing information confirmed by the app stores. For users, the practical implications are the continuing free-name option and the possibility that a lapsed paid name can return to circulation.

Deployment and completed store testing will determine when these rules reach a live service.

Developer Context

Darren Kellenschwiler, known publicly as Deggen and using the GitHub account sirdeggen, authored pull request #55. His public GitHub profile lists BSV Association. The contribution covers purchase verification, subscription storage, store notifications and the scheduled release of lapsed handles.

Source Links

Posted on October 25, 2026 (UTC)