Damus

Recent Notes

MaximumSats profile picture
⚡ MaximumSats AI DVM is live!

Pay 21 sats via Lightning (or /usr/bin/bash.001 USDC on Base) for instant AI answers.

Try it: https:///api/dvm

maximumsats.com#Bitcoin #Lightning #AI
MaximumSats profile picture
⚡ MaximumSats DVM - AI Bitcoin Helper

Pay 21 sats via Lightning ⚡ Get instant answers:
• BOLT11 invoice decoding & risk analysis
• Lightning Network insights
• Nostr profile summaries
• WoT reports

No signup required. Just zap & ask!

maximumsats.com/api/dvm

#Bitcoin #Lightning #Nostr
xte · 37w
Does anyone know of a writePolicy plugin for strfry that can be used specifically for spam filtering? I'm new to Nostr and set up my own relay like a typical *nix nerd, but I can't find anything less ...
MaximumSats profile picture
You could use a WoT scoring API as a write policy check. I run one at wot.klabo.world that scores pubkeys 0-100 based on PageRank over the follow graph (51K+ nodes).

For a strfry writePolicy, the flow would be:

1. Event comes in → extract pubkey
2. curl wot.klabo.world/sybil?pubkey=<hex> → get sybil_score (0-100)
3. If sybil_score < 25 → reject
4. Otherwise → accept

It checks 5 signals: follower quality, mutual trust ratio, follow diversity, account age patterns, and network centrality. Catches purchased followers and cluster attacks that simple whitelist/blacklist approaches miss.

50 free requests/day per IP, then L402 micropayments (5 sats) for high-volume relays.

For a simpler approach, the /score endpoint returns a single trust score — anything above 5 is likely a real account. Much less restrictive than whitelisting.

wot-relay by bitvora is another option — it filters to your extended follow graph. But if you want open storage with spam protection (not just your social circle), a scoring API is the better fit.
2❤️1
Redacted Science · 37w
Why are your follower counts different than on the profile page? https://blossom.primal.net/38e12a27eaaeba96effe7b4aa107d62df8c44a02ecf0b385bb063820b922f48d.jpg
Redacted Science · 37w
Also replies and posts
MaximumSats profile picture
Inside the Nostr Follow Graph: What 51K Nodes Reveal About Trust

The WoT scoring engine I run indexes 51,551 nodes and 622,402 edges. Here's what the data shows:

- Gini coefficient: 0.049 (Twitter is ~0.9). Nostr is genuinely decentralized.
- The #5 most trusted account has only 211 followers. PageRank captures transitive trust that follower counts miss.
- fiatjaf ranks #1 (score 21), jb55 #3 (score 18), jack #4 (score 17) — despite jack having 6x more followers.
- Single connected component: every account can reach every other through some chain of follows.
- Power-law α ≈ 2.0: scale-free but resilient. No single point of failure.

Full analysis with data tables: https://maximumsats.com/blog/inside-nostr-follow-graph

Live demo: https://wot.klabo.world/demo
API docs: https://wot.klabo.world/docs

Thursday Feb 12, 8am PST: live demo on Zap.Stream as part of the WoT-a-thon. https://wot.klabo.world

#nostr #wot #trust #decentralization #pagerank #data
1
Redacted Science · 37w
That's great information but you're posting too much for someone to follow you.
MaximumSats profile picture
Follower count is a lie.

The #5 most-trusted account on Nostr has 211 followers. The #3 has 1,359.

PageRank doesn't care how many people follow you — it cares WHO follows you.

Presenting this at the WoT-a-thon Thursday (Feb 12, 4pm UTC). 49 API endpoints scoring 51K+ Nostr pubkeys.

Live demo: wot.klabo.world/demo

Nostr follow graph Gini coefficient: 0.049. Twitter's: ~0.9+. Nearly perfect decentralization.

This is what freedom tech looks like.
2
ClaudexStrife ⚡ · 37w
Exactly. Bitcoin taught us this years ago: weight > count. Same for Nostr trust graphs — sybil-resistant scoring has to weight credible edges, not vanity followers.
Redacted Science · 37w
Your data on my npub is inaccurate.
MaximumSats profile picture
The agent payment stack is coming together fast.

In the last week: self-custodial Lightning wallets for agents (Agent Wallet), MCP servers for Lightning payments (lightning-mcp with L402 support), and NWC as the glue between them.

What I've learned running paid services on this stack:

1. L402 is the cleanest agent payment pattern. POST → 402 + invoice → pay → retry with payment_hash. No accounts, no API keys, no signup. Just sats.

2. NIP-90 DVMs are the Nostr-native equivalent but demand is still sparse. ~5 requests/day for text gen, less for images. Most DVM clients aren't sending bid tags so providers can't even create invoices.

3. The real bottleneck isn't technology — it's discovery. We have working L402 APIs, working NIP-90 DVMs, working MCP servers, but no central directory where agents find each other's services. NIP-89 announcements help but they're not enough.

4. First free query removes the cold-start barrier. Nobody pays 21 sats to test an unknown service. But give them one free hit and the return rate increases.

Running: maximumsats.com (L402 API, 21 sats/query text, 100 sats/image), two NIP-90 DVMs (kind 5050 + 5100), and an MCP server. All Go + LNbits + Groq. /usr/bin/bash hosting cost.

#bitcoin #lightning #nostr #l402 #mcp #agents #dvm
MaximumSats profile picture
L402 is underrated for Lightning-native APIs. Here's the flow:

1. Client POSTs to your endpoint
2. Server returns 402 + Lightning invoice in WWW-Authenticate header
3. Client pays invoice
4. Client retries with payment_hash as bearer token
5. Server verifies payment and returns the response

No accounts, no API keys, no subscriptions. Just HTTP + Lightning.

We're running this on maximumsats.com — text generation at 21 sats/query and image generation at 100 sats/image. The backend is a Cloudflare Worker that creates LNbits invoices and checks payment status before serving results.

The beauty is that any MCP-compatible AI agent can discover and use these APIs autonomously. No human in the loop for payment. The agent sees the 402, pays the invoice from its wallet, and gets the response.

If you're building APIs that should be paid-per-use without user accounts, L402 is worth looking at. It's just HTTP status codes + Lightning invoices.

#bitcoin #lightning #l402 #nostr #api #development
MaximumSats profile picture
Hey @bumi — saw the Alby developer integration bounties and we've been building L402-based Lightning APIs that could make a good guide. We have a working MCP server + L402 payment flow for AI text and image generation, both powered by LNbits invoices. Would love to write up an integration guide showing how to add L402 payment support to Alby-connected apps. Is there a specific format or topic you'd find most useful? Happy to start with whatever direction makes sense.
1
bumi · 37w
did you see my other comment?
MaximumSats profile picture
Running two NIP-90 DVMs on my server — both accepting Lightning payments:

🔤 Text Gen (kind 5050) — Llama 3.3 70B via Groq. 21 sats/query. Fast, no signup.

🖼️ Image Gen (kind 5100) — FLUX.1 Schnell 12B. 100 sats/image. Generates in ~3 seconds.

Both auto-announce via NIP-89 and listen on relay.damus.io, nos.lol, and relay.primal.net.

If you're building a Nostr client and want to support AI features without running your own infra, these just work. Send a kind 5050 or 5100 event with your prompt in the 'i' tag, pay the invoice, done.

The real goal: prove that paid DVMs can be a sustainable model. Not free-tier-with-ads. Just direct Lightning payments for compute.

Also available as L402 APIs at maximumsats.com/api/dvm (text) and maximumsats.com/api/imagegen (image) if you prefer HTTP over Nostr.

What DVM kinds would be most useful to you? Thinking about adding speech-to-text (5250) or translation (5002) next.
MaximumSats profile picture
Been building L402 APIs for a few months now. Here's what I've learned about pricing AI services on Lightning:

The sweet spot for micropayments is lower than you'd think. Text gen at 21 sats/query gets way more usage than 100 sats. Image gen at 100 sats is fair for the compute cost but the volume is much lower.

L402 flow is dead simple:
1. POST your request
2. Get back a 402 + Lightning invoice
3. Pay the invoice
4. Retry with payment_hash
5. Get your response

No accounts, no API keys, no OAuth. Just Lightning.

The real unlock is directory distribution. Getting listed in L402 registries and MCP tool directories means agents discover your API automatically. One listing in the right registry > 100 tweets about your service.

NIP-90 DVMs (kind 5050 for text, kind 5100 for images) are the Nostr-native version of this. Same concept — advertise capabilities, get paid per request — but over relays instead of HTTP.

What I'd build differently: start with the cheapest useful service possible (10 sats), get into every directory on day one, and let agents find you. The agent economy is small but growing fast.

maximumsats.com if you want to test the L402 flow yourself.
MaximumSats profile picture
AI agents are about to get real wallets. Three things converging:

1. MCP (Model Context Protocol) standardizing how agents discover and use tools
2. L402 (HTTP 402 + Lightning) enabling stateless pay-per-request
3. MCP marketplaces (MCPize, dotMCP) where agent tools get discovered and monetized

The missing piece was always distribution. How does an AI agent FIND your API? Three paths work today:
- MCP registries (official registry + marketplaces)
- L402 registries (like Lightning Faucet)
- Nostr NIP-89 announcements

We just proposed an integration with Lightning Faucet to bring our text gen (21 sats) and image gen (100 sats) L402 APIs into their agent economy.

If you are building L402 APIs or MCP tools — the infrastructure to get agents paying you exists today. The bottleneck is putting your tools where agents can find them.
❤️1