Pluggable storage, so services on PostgreSQL or with several instances can embed satsettle

thesimplekid commented

2026-10-09 11:20:31 +00:00

Owner

Summary

Engine owns one local data directory (redb, plus SQLite for CDK), and a second open fails. Services that keep their state in PostgreSQL, or that run several instances, cannot adopt satsettle without a second source of truth. For a username purchase, the application's reservation and satsettle's capture decision then live in two databases, and the application has to reconcile them on startup, as the usernames example does with its own redb file.

Suggestion

Put the intent, hold, authorization, receipt and payout journals behind a storage trait, with the redb backend as the default. A PostgreSQL backend could then share the application's database, and ideally its transactions: reserving the resource and choosing the authorization could commit together.
Accept a caller-supplied Arc<cdk::Wallet>, or a CDK WalletDatabase, instead of always creating SQLite wallets, so CDK state can live in cdk-postgres too.
For several instances: replace in-process locks (operations, per-mint wallet locks) with storage-level leases where they guard shared state. Document which recovery steps are safe to run concurrently, given that CDK recovery can touch another instance's in-flight receive.

Without this, npub.cash (PostgreSQL, NixOS module, multiple instances supported) keeps its own implementation.

## Summary `Engine` owns one local data directory (redb, plus SQLite for CDK), and a second `open` fails. Services that keep their state in PostgreSQL, or that run several instances, cannot adopt satsettle without a second source of truth. For a username purchase, the application's reservation and satsettle's capture decision then live in two databases, and the application has to reconcile them on startup, as the `usernames` example does with its own redb file. ## Suggestion - Put the intent, hold, authorization, receipt and payout journals behind a storage trait, with the redb backend as the default. A PostgreSQL backend could then share the application's database, and ideally its transactions: reserving the resource and choosing the authorization could commit together. - Accept a caller-supplied `Arc<cdk::Wallet>`, or a CDK `WalletDatabase`, instead of always creating SQLite wallets, so CDK state can live in `cdk-postgres` too. - For several instances: replace in-process locks (`operations`, per-mint wallet locks) with storage-level leases where they guard shared state. Document which recovery steps are safe to run concurrently, given that CDK recovery can touch another instance's in-flight receive. Without this, npub.cash (PostgreSQL, NixOS module, multiple instances supported) keeps its own implementation.

thesimplekid referenced this issue

2026-10-09 11:20:44 +00:00

Embedding compatibility: CDK version pin and MSRV #9

thesimplekid commented

2026-10-09 11:20:54 +00:00

Author

Owner

Overlaps #1 (payment storage interface) and #2 (caller-managed wallets). This issue adds the multi-instance and PostgreSQL requirements: shared transactions with the application's reservation, and leases instead of in-process locks. Feel free to fold it into #1.