refactor: rename extension identity to spirekeeper

Fork of satmachineadmin's v2-bitspire line into its own repo. Renames
both identifiers so this extension is fully independent of the original
satmachineadmin install (which remains in service):

  - extension id   satmachineadmin -> spirekeeper
    (router prefix, static path/static_url_for, module symbols, task
     names, templates dir, config/manifest paths)
  - database name  satoshimachine  -> spirekeeper
    (Database(ext_spirekeeper), all schema-qualified table refs)

Also resets versioning to 0.1.0, sets the display name + manifest to
spirekeeper/aiolabs, and fixes the placeholder pyproject description.
Historical aiolabs/satmachineadmin#N issue references in comments are
left pointing at the original repo where those issues live.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Padreug 2026-06-13 22:30:05 +02:00
commit a059e3f596
22 changed files with 242 additions and 242 deletions

View file

@ -11,7 +11,7 @@ on a match.
The hook is registered with lnbits' `nostr_transport` at extension-init
time via `register_with_lnbits()`. Until the lnbits side ships
`lnbits.core.services.nostr_transport.register_roster_resolver`, the
registration call lazily-imports + soft-fails so satmachineadmin keeps
registration call lazily-imports + soft-fails so spirekeeper keeps
loading cleanly on any lnbits version.
When the lnbits implementation lands + the satmachine instance has
@ -37,7 +37,7 @@ from loguru import logger
from .crud import get_machine_by_atm_pubkey_hex
_SOURCE_EXTENSION = "satmachineadmin"
_SOURCE_EXTENSION = "spirekeeper"
@dataclass(frozen=True)
@ -111,11 +111,11 @@ def register_with_lnbits() -> bool:
Returns True if the registration landed (lnbits surface available
+ call succeeded), False if soft-failed because lnbits hasn't
shipped `register_roster_resolver` yet that's the expected
state until the path-B lnbits PR lands. Either way satmachineadmin
state until the path-B lnbits PR lands. Either way spirekeeper
boots cleanly; only the routing-via-roster behavior is gated on
the lnbits side being present.
Called once from `satmachineadmin_start()`. Idempotent on the
Called once from `spirekeeper_start()`. Idempotent on the
lnbits side per their 15:15Z spec ("re-registration on extension
reload replaces cleanly").
"""
@ -125,7 +125,7 @@ def register_with_lnbits() -> bool:
)
except ImportError:
logger.info(
"satmachineadmin: nostr-transport roster-resolver hook not "
"spirekeeper: nostr-transport roster-resolver hook not "
"available on this lnbits version (pre-path-B); ATM-npub "
"routing falls through to lnbits' default auto-account-from-"
"npub behaviour. See aiolabs/satmachineadmin#20 / coord-log "
@ -134,7 +134,7 @@ def register_with_lnbits() -> bool:
return False
register_roster_resolver(_SOURCE_EXTENSION, resolve)
logger.info(
f"satmachineadmin: registered '{_SOURCE_EXTENSION}' roster "
f"spirekeeper: registered '{_SOURCE_EXTENSION}' roster "
"resolver with lnbits nostr-transport — inbound kind-21000 "
"from a registered ATM npub will route to the operator's wallet "
"directly. (Behavior gated server-side by "