Magic Carpet · Phase 1for: David Strayhorn + agent

One trust step to finish the hands-off payout demo

From Nashville Automation (Matthias). This page has the single thing that needs your side — everything else (wallet, bounty, auto-pay) is already live on your instance.

What we're finishing

The Phase 1 demo from our meeting: a person adds an item to a "cities" DList bounty on magic-carpet.brainstorm.world and is paid ~100 sats automatically over Lightning — no one presses a button, trust score alone gates the payment. It's set up for two people: you and Matthias.

You already pass. Your key reads rank 100 on the instance, and your Lightning address is on file. The only gap: Matthias's payee key isn't in your web of trust yet, so the payer scores it 0 and skips it. It needs a real vouch from you — which is exactly how the grapevine is meant to work.

The one fact that sets this up

Your instance's owner and rank-author is you. GET /api/owner-info returns your pubkey (e5272de9…a102f), and your grapevine is the point-of-view the payer reads. So the trust that releases the payment is yours to grant. Matthias can't (and shouldn't) raise his own score — that's the whole point of the system.

The key to vouch

Matthias — payee

npub: npub1su7gycfdu75k3dsukdp7xndnmzxywavhyq6qvwf2qz4e2gtgf4ssqa0p2m

hex: 873c82612de7a968b61cb343e34db3d88c477597203406392a00ab9521684d61

This is the only value you need. The payout address is set on Matthias's side, and resolves automatically at pay time — nothing for you to enter.

How a payout flows (for context)

flowchart TD
  C["Matthias adds a list item
(claims with the key above)"] --> W["auto-pay watcher (30s)"] W --> R{"rank(you → Matthias's key) ≥ floor?"} R -- "0 today → skipped" --> X["no payment"] R -- "after your vouch → passes" --> P["pay ~100 sats to matthias@npub.cash"] P --> Z["kind-9735 receipt · shows paid"]

Your steps (you or your agent)

1 · Confirm your live rank-author

Signed in as owner, check which key your grapevine reads scores from (Settings, or GET /api/user-prefs while authenticated — it's 401 when logged out). Your account currently carries live scores under two points-of-view, so the recompute in step 3 must land Matthias's score under the same one the payer reads. If unsure, note the value and tell Matthias — he'll confirm it against the payer on the droplet.

2 · Add Matthias's key to your web of trust

Follow / vouch the payee key above from your key (a normal Nostr follow, or a trust edge in the Brainstorm UI). One vouch from you puts it at one hop from the top of your grapevine — comfortably above the payer's floor.

3 · Recompute and load your grapevine

Re-run your grapevine calculation, then run the per-user score load (the one keyed to your rank-author) so Matthias's key gets written under the same point-of-view the payer reads. A plain publish job alone can write the score under a different key's field that the payer won't look at — use the personalization load so it lands where it's read.

4 · Verify it took

From your point of view, Matthias's key should now read a rank of at least the floor (well above 2). Once it does, tell Matthias.

5 · Matthias runs the dry run

Matthias re-runs the on-droplet preflight to confirm the key passes, then does one laptop-closed payout to it and records it. Nothing further needed from you.

Please don't shortcut it

The value we're showing is a real trust-gated payment: you vouch, the grapevine computes, the payment releases. Writing a score in by hand would defeat the demo. The steps above are the genuine path.

Questions → Matthias. · Nashville Automation · Matthias Debernardini