CraysSparky Hub
Sparky Hub shows how an app-facing NWC wallet service can sit on top of Spark, while its own README makes clear that it is a prototype for tiny experiments, not a production wallet.
A wallet service prototype, not a consumer wallet
Sparky Hub is best understood as a builder-facing prototype. The repository describes it as a multi-user Nostr Wallet Connect wallet service using Spark, with the goal of letting each user have their own keys. That is a specific technical idea: one web service can host many user accounts, each account can initialize a Spark wallet backend, and each account can create NWC connections for apps that want to receive or spend through that wallet.
The project is not presented like a polished wallet brand. Its README opens with a direct warning that it is an Alby experimental hackday project. That warning shapes the entire page. Sparky Hub is useful because it exposes a pattern that may matter for Nostr payments. It is risky because the same repository tells users not to trust it with meaningful funds.
A reader looking for a daily zap wallet should start elsewhere. A developer trying to understand how a Spark-backed service could answer NIP-47 requests will find Sparky Hub more interesting. The difference is not cosmetic. The public promise of the project is exploration, not safe custody, uptime, support or long-term wallet maintenance.
What Sparky Hub actually does
At the product level, Sparky Hub is a simple web bitcoin wallet that connects to apps. The front end has login, signup, connected-app management, QR code display and a security screen for the wallet recovery phrase. The app connection screen asks the user for a name, creates a new NWC connection, then shows a QR code and a copyable connection secret.
Behind that small interface is a clear wallet-service pattern. A user signs up with a username and password. The server generates a BIP39 mnemonic, initializes a Spark wallet from it, stores user state in SQLite through Prisma, and caches a Spark backend instance for the signed-in user. When the user creates an app connection, the backend generates fresh Nostr keys and returns a `nostr+walletconnect` URI.
That URI is the handoff. A Nostr client, web app or payment tool can scan or paste it and then talk to Sparky Hub over Nostr Wallet Connect. The app does not receive the Spark mnemonic. It receives a NWC secret that authorizes requests to this service. In a safer production system, that kind of separation can be powerful. In this repository, it is a prototype with explicit limits.
The Alby context matters
Sparky Hub lives under the getAlby GitHub organization. Alby has been one of the main teams pushing Nostr Wallet Connect from a developer idea into usable wallet integrations. Alby Hub, Alby Go, Alby Extension, Alby Account and Alby NWC Relay all sit around the same question: how can apps request wallet actions without becoming wallets themselves?
Sparky Hub fits that history as a lab bench. It is not Alby Hub. It does not offer the same maturity, documentation surface or product posture. It is a compact codebase that tries one design: connect NWC to Spark and let multiple users create app-specific wallet links from a browser.
That makes the project valuable even if a reader never runs it. It shows what Alby was testing around Spark, NWC wallet services and hosted multi-user payment surfaces. It also shows the hard parts that a real product must solve before the pattern can be trusted: key storage, recovery, app permissions, withdrawal guarantees, operational reliability and safe defaults.
The README warning is the starting point
The README is unusually frank. It says Spark was very unstable at the time and had almost daily breaking changes. It says Spark had not implemented unilateral withdrawal yet. It says mnemonics were stored as plaintext. It says security was not the focus during the hackday. It tells users not to put more than 100 sats into the wallet because there is no guarantee that funds will always be accessible.
Those statements should not be softened. They are the most important part of the project for a non-developer reader. Sparky Hub may demonstrate a useful architecture, but the repository itself says the architecture was not ready for normal funds at that snapshot. The right mental model is a test rig on mainnet with a tiny balance ceiling, not a savings account or a replacement for a maintained wallet.
This also makes Sparky Hub a good teaching example. Many wallet projects hide their unfinished risk behind friendly copy. Sparky Hub does the opposite. The danger signs are visible in the README and in the code. A reader learns more from that honesty than from a generic wallet page that only says payments are easy.
Spark is the wallet backend
The Lightning backend in Sparky Hub is `SparkLNBackend`. It imports `SparkWallet` from `@buildonspark/spark-sdk`, initializes a wallet from a mnemonic or seed, and sets the network to mainnet. That choice is important. Sparky Hub is not just mocking a wallet. It is wired to a real Spark SDK interface and uses real Lightning receive and send calls through that backend.
Spark matters because it aims to give developers a Bitcoin-native payment layer with fast transfers and a wallet abstraction that can be embedded in applications. In Sparky Hub, Spark is the component that creates Lightning invoices, pays Lightning invoices, returns balances and looks up send or receive request status. NWC is the app-facing language. Spark is the money-moving backend behind that language.
The README warning keeps the reader from overreading the design. Spark itself may evolve, and the current Spark documentation should be checked before anyone makes product decisions. Sparky Hub captures a moment in that evolution: an Alby experiment that tried to see whether Spark could power a multi-user NWC service.
NWC is the app-facing surface
Nostr Wallet Connect, described in NIP-47 and on nwc.dev, lets an app ask a wallet for payment-related actions over Nostr relays. Instead of embedding wallet code into every app, the app sends encrypted requests to a wallet service. The wallet service answers with results or errors. The user gives the app a connection string that contains the information needed to reach and authenticate that wallet service.
Sparky Hub implements that idea with Alby's SDK. The wallet service publishes a wallet service information event, creates a key pair for the app connection, subscribes to the Alby relay, and hands incoming NWC requests to a request handler. The app never needs to know that Spark is behind the service. It only needs the NWC URI and the methods the service supports.
That abstraction is the point. If it works, a Nostr client can show a zap button, a payment tool can ask for invoice payment, and a web app can check balance or invoice status without becoming a Lightning node. The hard part is not the message format. The hard part is controlling what each connection is allowed to do and how much risk the user is accepting.
The generated connection string
The app route shows the connection string clearly. When a signed-in user creates a new app connection, Sparky Hub generates a wallet service secret key, derives a wallet service public key, generates a client secret key, derives a client public key, and returns a URI that starts with `nostr+walletconnect://`. The URI includes the wallet service public key, the relay URL and the client secret.
The relay in the code is `wss://relay.getalby.com/v1`. That means app requests are routed through Alby's relay endpoint, while Sparky Hub remains the wallet service that decrypts and answers the NWC request. The database stores the client public key and the wallet service secret key for the app connection, linked to the user.
The sensitive piece is the secret inside the NWC URI. Anyone who gets a spend-capable NWC string may be able to ask the wallet service to pay. In a production wallet, users expect budgets, expirations, labels, revocation and clear permission controls. Sparky Hub shows the basic connection creation path. Its own code still marks deletion and richer app management as future work.
Supported NWC methods
The Spark backend reports support for `get_info`, `make_invoice`, `pay_invoice`, `get_balance`, `lookup_invoice` and `list_transactions`. That set covers the core loop that many apps need. An app can ask what the wallet supports, create a receive invoice, pay a Lightning invoice, read the current balance, check whether a payment settled, and request a transaction list.
`make_invoice` uses Spark to create a Lightning invoice for a requested amount and description, then parses the invoice with Alby's Lightning tools. `pay_invoice` asks Spark for a fee estimate, rejects zero-amount invoices, pays the invoice, stores the Spark request ID and polls for a preimage. `get_balance` asks the Spark wallet for its balance and returns millisatoshis.
The transaction story is partly complete and partly revealing. Incoming and outgoing records are stored in Prisma models with invoice, payment hash, preimage, amount, fees, state and Spark request ID. The list endpoint reads from the database, not directly from Spark. That is a normal design direction for a wallet service, but in this prototype it should be read as a trace of the intended architecture, not as a guarantee of polished accounting.
User accounts are ordinary web accounts
Sparky Hub does not use a Nostr key as the user login. The backend has username and password signup, bcrypt password hashing, JWT tokens and protected routes. On signup, the backend generates a 128-bit BIP39 mnemonic, initializes a Spark backend from that mnemonic, creates the user record, stores the mnemonic, caches the backend and returns a token.
That account model is familiar to web developers, but it is unusual enough to call out in a Nostr wallet context. The Nostr key is not the money key. The app connection uses NWC keys. The wallet backend is derived from a mnemonic. The browser account is protected by a password and token. Those layers can be sensible if they are implemented carefully, but each layer adds recovery and security responsibilities.
For Sparky Hub, the most important fact is not the login style. It is what happens to the mnemonic after login. The project stores the recovery phrase in the database and gives authenticated users a route to retrieve it. That may be convenient for a prototype. It is also exactly why the README says security was not the focus.
Plaintext mnemonics are the loudest risk
The Prisma schema says the user mnemonic is stored as a string and includes a comment saying it should later be encrypted. That is the central custody warning. A mnemonic is not harmless metadata. It is the recovery material for the underlying wallet. If a server stores it in plaintext, anyone with database access, a server compromise, a backup leak or an insider path may be able to take funds.
The front end also has a security page that can show the current recovery phrase, reveal individual words, copy the phrase and import a new twelve- or twenty-four-word mnemonic. That makes sense for a hackday project where users need to inspect what was generated. It is not the posture readers should expect from a wallet that wants to hold meaningful value.
This is why the 100-sat warning matters. A small test balance lets a developer observe NWC behavior without pretending that the key-storage model is safe. Any article or directory listing that omits plaintext mnemonic storage would mislead the reader. It is not a small footnote. It is the main reason Sparky Hub should be treated as a code example.
App permissions are still thin
The app manager lets the user create a named connection and lists connected apps by name and public key. That is enough to demonstrate the NWC onboarding flow. It is not enough to manage real wallet permissions. The code does not show per-app budgets, per-method approvals, spending limits, expiration dates, confirmation prompts or a finished delete route for app connections.
The backend itself contains a TODO for deleting apps and another TODO around cleaning up an app record if subscription fails. Those are normal gaps in a prototype, but they are major gaps for real wallet use. A user must be able to revoke an app, understand what it can do, and see whether the service is actively listening for that app.
NWC turns app permissions into money permissions. A connection string that can pay invoices is much more sensitive than a connection string that can only receive invoices or read metadata. Sparky Hub demonstrates how to issue a connection. It does not yet demonstrate the full safety interface readers should demand before trusting a wallet service with everyday spending.
The relay path is simple and centralized
Sparky Hub uses the Alby relay URL directly in the wallet service code and in the generated NWC URI. That keeps the prototype small. The wallet service knows where to publish service information and where to subscribe for app requests. The app receives the same relay in the URI and can use it as the rendezvous point for the wallet connection.
For a prototype, that simplicity is helpful. For a production wallet, relay choice affects availability, privacy and support behavior. If the relay is unavailable, the app and wallet service may not exchange requests. If all connections use the same relay, traffic patterns become easier to reason about from the outside. If the relay policy changes, the wallet service has to adapt.
The code even marks the relay as something to make configurable. That is the right instinct. NWC can work over relays, but wallets should not treat relay configuration as a throwaway detail. Readers comparing Sparky Hub with mature wallet products should ask whether relay choice, fallback behavior and connection health are visible to the user.
The database shows the intended wallet ledger
The database schema has three main models: user, app and transaction. A user has a username, password hash, mnemonic, app records and transactions. An app has a name, client public key, wallet service secret key and user link. A transaction stores user, app, type, state, invoice, payment hash, preimage, amount, fees, description, settlement time, expiry and Spark request ID.
That structure is practical. A wallet service needs to remember which app created or paid what, whether a payment is pending or settled, which invoice belongs to which request, and how to map Spark-side request identifiers back into an app-facing NWC response. Sparky Hub has the skeleton of that ledger.
The implementation also exposes unfinished edges. The request handler notes that payment retries can fail because of a unique payment-hash constraint. Invoice creation logs database errors but still returns the successful invoice result. Those choices may be fine for a lab project. A production wallet needs stricter accounting guarantees, clearer error handling and migration discipline.
The front end is deliberately small
The front end is a React and Vite app with a compact route structure. Public routes handle login and signup. Protected routes show the app manager and the security page. The header describes the product as a simple web bitcoin wallet that connects to apps. A warning banner tells the user that the service is for experimental use only.
The app manager is the main NWC screen. It creates a connection by name, shows the most recently created NWC URL, renders it as a QR code and lets the user copy it. Existing app connections are listed as cards. That is enough to test the essential user motion: create a connection, hand it to another app, and watch NWC requests arrive.
The security screen is more troubling, as it should be. It lets a user import a mnemonic and show the current recovery phrase. The copy button even labels the action as dangerous. A developer can see how recovery material moves through the prototype. A normal user should see a strong reason not to keep real money there.
Deployment clues point to a lab service
The repository includes a Fly.io configuration generated for an app named `spark-nwc`. It sets a Frankfurt primary region, serves the backend on port 3001, uses a SQLite database file under `/data`, enables HTTPS, and defines a simple health check at `/ping`. A GitHub Actions workflow deploys from the master branch to Fly when configured with a Fly API token.
Those files are useful because they show how the experiment was meant to run. The front end can build into static files served by the backend. The backend can hold a SQLite database on a mounted volume. The public README links to a demo endpoint, but the repository remains the more reliable reference for understanding behavior because prototype demos may be intermittent.
A production wallet service would need a much broader operations story. It would need backups, database migration practices, monitoring, incident response, key handling, withdrawal fallbacks, user support, terms, privacy posture and a maintained release process. Sparky Hub gives enough deployment scaffolding to run a test. It does not claim the rest.
Spark withdrawal assumptions need caution
The README says Spark had not implemented unilateral withdrawal at the time of the project. That line is important because unilateral withdrawal is one of the ways a user can reason about exit rights in a payment system. If a wallet backend cannot yet offer the exit behavior a user expects, then the user's effective risk is higher than the interface may suggest.
Readers should check the current Spark documentation before drawing conclusions about Spark as it exists today. Sparky Hub is tied to a particular repository snapshot and package version. Spark may have changed since then, and current Spark products may not share the same limitations. The article should not freeze Spark in time because one hackday project captured an early state.
The correct conclusion is narrower. At the Sparky Hub snapshot, the authors themselves believed Spark instability and missing unilateral withdrawal made the project unsafe for meaningful funds. That is enough to determine how to treat this page. Use Sparky Hub to understand an integration pattern. Do not use it as proof that a Spark-backed NWC wallet service is automatically safe.
How it differs from Alby Hub
Alby Hub is a serious wallet-control product. It is built for people who want to connect apps, manage permissions and use Lightning through a maintained system. Sparky Hub sits in a different lane. It shares NWC vocabulary and Alby DNA, but it is a small experiment around Spark and multi-user service design.
That distinction helps readers avoid category mistakes. If someone wants to connect an app to their own Lightning setup, Alby Hub is the natural comparison point. If someone wants to study how a wallet service can be wired together from a React front end, Fastify backend, Prisma database, Alby SDK and Spark SDK, Sparky Hub is the more interesting artifact.
The two projects also expose a product truth. NWC is only one layer. A good wallet needs permission design, key management, recovery, clear spending limits and operational maturity. Sparky Hub demonstrates the message path. Alby Hub is closer to the user product that must absorb all the messy safety work around that path.
How it differs from hosted browser wallets
Sparky Hub can look similar to a hosted browser wallet because it has accounts, a web interface and app connections. That resemblance is shallow. A hosted browser wallet such as Rizful presents itself as a usable service with docs, account safety guidance and NWC flows for common Nostr clients. Sparky Hub presents itself as an experiment with a sharp funds limit.
The difference is not whether the wallet is in a browser. The difference is product readiness. A browser wallet can be legitimate if it is clear about custody, account recovery, withdrawal paths, fees, app permissions, support and legal terms. A browser prototype can be useful for developers while still being wrong for normal use.
Sparky Hub belongs in the Nostr wallet map because it shows an NWC wallet-service design. It should be introduced with its warning label intact. The reader should not leave with the impression that every app listed beside mature wallets has the same trust profile.
Who should open the repository
The best reader for Sparky Hub is a developer who wants to learn how NWC wallet services are assembled. The repository is small enough to follow. The backend routes show signup, login, mnemonic update, app connection creation and app listing. The NWC classes show service publication, subscription and request handling. The Spark backend shows invoice creation, invoice payment, balance lookup and status checks.
A second useful reader is a product designer working on wallet permissions. Sparky Hub makes the missing pieces obvious. What should the user see before giving an app spend access? How should a wallet display the methods an app can call? How should revocation work? How should connection strings be named, expired and limited? The prototype is a good prompt because it exposes the minimum flow.
A third reader is a security reviewer. Plaintext mnemonics, mainnet Spark use, thin app management, unique-constraint payment retry issues and reachable recovery routes create a compact list of topics to inspect. The project is not hiding them. That makes it a useful teaching object for wallet threat modeling.
Who should not fund it
A normal Nostr user should not fund Sparky Hub with meaningful sats. The README tells users not to put more than 100 sats into the wallet. That is not a marketing phrase. It is a risk boundary from the maintainers. If a user wants a wallet for zaps, tips or app payments, they should choose a maintained wallet that explains custody, withdrawal, permissions and support.
A builder should also avoid treating the code as production boilerplate. The project is useful as a reference, but the README says security was not the focus. Copying the connection flow without redesigning key storage, encryption, permissions and recovery would reproduce the most dangerous parts of the prototype.
The safest use is tiny-value experimentation. Create a local setup, read the code, observe how NWC requests move through the service, and keep the balance small enough that losing it would not matter. Sparky Hub teaches architecture. It should not be asked to provide custody confidence it never promised.
What to verify before reusing the idea
A team inspired by Sparky Hub should begin with the key model. Where is the mnemonic generated? Is it encrypted before storage? Who can decrypt it? Can the server spend without the user? What happens if the database leaks? Can the user rotate or export safely? Does account recovery create a second path to the funds?
The next question is app control. Each NWC connection should have visible permissions, spending limits, expiration, revoke behavior, audit logs and clear naming. A user should understand whether an app can pay invoices, create invoices, read balance, read transactions or only receive zaps. NWC is powerful precisely because it separates apps from wallets; the wallet must preserve that separation in the interface.
The final question is exit. A wallet backend should explain how a user withdraws, what happens if the service disappears, how network fees are handled, what trust is placed in the backend and what operational promises are realistic. Sparky Hub's README says those answers were not ready. Any production descendant would have to make them ready before asking readers for trust.
Why Sparky Hub still belongs in the map
Sparky Hub is not important because many people should use it. It is important because it captures a real design pressure in Nostr payments. Apps want simple wallet connections. Users do not want every app to hold their keys. Wallets want a way to serve many app connections without rebuilding custom integrations one by one. NWC is the protocol answer to that pressure.
Spark adds another layer to the question. If a backend such as Spark can make Lightning-like payment behavior easier to embed, then wallet services may become easier to build. Sparky Hub tests that shape. It takes a Spark wallet, wraps it in NWC, and lets apps talk to it through a relay. The code is small, but the idea is large enough to track.
The honest conclusion is balanced. Sparky Hub is a useful NWC and Spark artifact, a readable Alby experiment and a strong reminder that wallet UX cannot outrun wallet safety. The most useful thing it gives the reader is not confidence. It gives a concrete mental model for how app payments can be routed through Nostr, and a concrete list of problems that must be solved before that model is safe.
Sources worth opening
Open the Sparky Hub repository and README first, then the backend code for users, app connections, NWC handling and Spark calls. Compare that with NIP-47, nwc.dev, Spark documentation and the Alby SDK resources.
- Sparky Hub GitHub repository
- Sparky Hub README
- Sparky Hub backend package
- Sparky Hub frontend package
- Sparky Hub Prisma schema
- Sparky Hub wallet service code
- Sparky Hub NWC request handler
- Sparky Hub Spark backend
- Sparky Hub app routes
- Sparky Hub user routes
- Sparky Hub app manager component
- Sparky Hub mnemonic manager component
- Sparky Hub warning banner component
- Sparky Hub main app component
- Sparky Hub Fly configuration
- Sparky Hub Fly deploy workflow
- nwc.dev Nostr Wallet Connect
- NIP-47 Nostr Wallet Connect
- NIP-57 zaps
- Nostr protocol NIPs repository
- Alby SDK repository
- Alby NWC examples and ecosystem
- Alby developer documentation
- Alby main site
- Spark documentation
- Spark main site
- Build on Spark GitHub organization
- Spark SDK package
- nostr-tools package
- Fastify documentation
- Prisma SQLite documentation
- BIP39 package used by Sparky Hub
