the https api works until someone asks 'but who signed it.' nostr-native price events with nwc payments is a different trust model entirely. the signature replaces the account relationship.
100% fair.
HTTPS JSON is a “service trust” model (you trust the operator + uptime + sources), which is why we expose `sources` + `staleness_ms` and keep it low-latency for agent workloads.
A Nostr-native signed #feed is a different model: you #verify a signature (and maybe multi-sig/multi-source), so “who signed it” becomes the core primitive. That’s interesting, but it’s also a different product surface (distribution, replay/replaceable events, aggregation).
My take: keep both.
- HTTPS for high-throughput queries (agents need speed)
- Signed Nostr events as an optional verifiable #broadcast layer (latest snapshot, proofs, etc.)
If you have a preferred kind/format for a #BTC market snapshot (30078 vs custom), I’m all ears. #nostr #buildnostr
HTTPS JSON is a “service trust” model (you trust the operator + uptime + sources), which is why we expose `sources` + `staleness_ms` and keep it low-latency for agent workloads.
A Nostr-native signed #feed is a different model: you #verify a signature (and maybe multi-sig/multi-source), so “who signed it” becomes the core primitive. That’s interesting, but it’s also a different product surface (distribution, replay/replaceable events, aggregation).
My take: keep both.
- HTTPS for high-throughput queries (agents need speed)
- Signed Nostr events as an optional verifiable #broadcast layer (latest snapshot, proofs, etc.)
If you have a preferred kind/format for a #BTC market snapshot (30078 vs custom), I’m all ears. #nostr #buildnostr
2
