Thanks, this is exactly the kind of review I was hoping for; not harsh at all.
pid: agreed. The app already uses a CSPRNG. It is now a MUST. The watcher accepts only the first intent per (recipient, pid) so a predictable pid would let someone front-run an intent and claim another person's payment. I kept random pids rather than HMAC derivation, since the intent is public anyway and fresh randomness is the simplest thing to get right.
type tag: it's display-only, so clients can count a tip that was coupled to a like or repost on that button instead of listing it as a separate tip. A missing tag now means tip. App and watcher still always write it, so older versions don't break.
Both changes are done (spec v0.3) and will ship with the next release.
Personal watchers / pubkey instead of domain: this is the strongest point and I think you're right. Running a watcher shouldn't need a domain, TLS and an HTTP API. ["watcher", "<pubkey>", "<relay>"] plus encrypted Nostr messages for registration would let anyone run one on a home box and an optional tag fits that model too. That's a bigger change to spec, watcher and app, so it won't be in the next release. I want to design it properly first, but it's now at the top of the protocol list.
Thanks, this is exactly the kind of review I was hoping for; not harsh at all.
pid: agreed. The app already uses a CSPRNG. It is now a MUST. The watcher accepts only the first intent per (recipient, pid) so a predictable pid would let someone front-run an intent and claim another person's payment. I kept random pids rather than HMAC derivation, since the intent is public anyway and fresh randomness is the simplest thing to get right.
type tag: it's display-only, so clients can count a tip that was coupled to a like or repost on that button instead of listing it as a separate tip. A missing tag now means tip. App and watcher still always write it, so older versions don't break.
Both changes are done (spec v0.3) and will ship with the next release.
Personal watchers / pubkey instead of domain: this is the strongest point and I think you're right. Running a watcher shouldn't need a domain, TLS and an HTTP API. ["watcher", "<pubkey>", "<relay>"] plus encrypted Nostr messages for registration would let anyone run one on a home box and an optional tag fits that model too. That's a bigger change to spec, watcher and app, so it won't be in the next release. I want to design it properly first, but it's now at the top of the protocol list.
No txid: glad we agree.