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
1
