Answer "Why doesn't Async Payjoin use Nostr" FAQ

[DanGould]

write up an FAQ answer to this ever so frequent question

[ConorOkus]

Just adding some more context from Discord discussions.

• Considering lightning for async payjoin directories via onion routing https://damus.io/nevent1qqst9efnnsvf64397d0cjc0ft7mtp95vv7hqsmtx0z5nfslrmt5fhlg2dljlg

cc @nyonson @nothingmuch

[nyonson]

If (and this is a big if) nostr relays supported some sort of BIP157/158 filter protocol, would that mitigate concerns to use nostr as a channel? I haven't convinced myself client privacy is preserved, but this is the pie-in-the-sky thinking:

1. Payjoin parties agree on some nostr relays to coordinate over.
2. Parties listen for mythical "nostr filters" from these relays.
3. When one of the parties posts to a relay, the other should then pull down a chunk of notes which would contain the given post.

I think there are still issues with the above. Like as far as I know, nostr doesn't "gossip" notes between relays, so a relay could probably still connect both party IP addresses to an event. At the very least this thought experiment may help explain why nostr isn't great for this use case?

[DanGould]

There is a strong argument for choosing Nostr: Many relays exist already. One might assume that other nostr messages would be indistinguishable with payjoin messages, providing privacy, and that censorship would therefore be difficult for a relay operator. Even if you could, it'd be hard to justify censoring payjoins from nostr relays since it's really no different from a mail server that forwards messages on behalf of its users.

But in practice a Nostr relay used for payjoin would probably have distinguishable messages by length and by traffic pattern. And to support backwards compatibility with v1, you'd have to explicitly add support for HTTP-to-Nostr conversion on supporting relays. Finally, since Nostr relies on WebSocket, and WebSocket is basically a raw TCP connection, it's hard to prevent IP leaks from clients to relays with simple solutions like Oblivious HTTP.

The lack of ability to address the privacy leak at the IP layer is the biggest reason not to build Payjoin with Nostr. Oblivious HTTP doesn't work with WebSocket because WebSocket isn't semantically HTTP, it just uses HTTP to bootstrap a TCP connection. In order to preserve privacy at higher messaging layers, it's critical that each lower layer also preserves privacy otherwise lower layer leaks can be used to obviate higher layer privacy.

There's a couple significant nostr demos that encode relays in Bitcoin URIs for discovery even a draft spec. I think @nyonson's discovery idea would work too.

[nyonson]

The websocket requirement is a bit of sticking point, but I did find a proposed NIP which I think brings OHTTP-like functionality to nostr, although it looks dormant. Just some food for thought: nostr-protocol/nips#430