The reading half of this landed in #358: an nevent1 or nprofile1 that names relays now gets those relays asked, bounded, when the thing it points at is not on the reader's own.
The writing half is untouched, and it is the same gap pointing outwards.
copy_nevent encodes with no relays at all. encodeNevent(fba.allocator(), note.event_id, &.{}, note.pubkey, 1). So an address Plaza puts on the clipboard asks every other client to solve exactly the problem #259 described, and hands them nothing to solve it with. Plaza knows where it got the note: it came off a socket in the pool, and the author's write relays are in the outbox tables the feed is already routed by.
contentTags decodes an nevent and drops its relays too. When Plaza writes a note that quotes another, the e tag it builds has an empty relay field. NIP-10 and NIP-22 both put a relay hint there precisely so the next reader does not have to guess.
copy_npub has the same shape, with nprofile1 as the richer form.
Why this is its own issue and not part of #358
It changes what Plaza publishes, rather than what it reads. That needs its own decisions:
- Which relay to name. The one it arrived on is not always the one to publish: a note read from a relay the reader happens to use is a worse hint than the author's own write relay, and the outbox tables know the difference.
- How many. One is the convention in the tag; the clipboard form can hold more.
- What to do when there is no good answer. An empty hint is honest and is what ships today. A wrong hint is worse than none, because it costs every reader a socket to a relay that does not have it.
None of that blocks anything. It is worth doing because the reading half only helps Plaza's readers if other clients do it too, and Plaza is currently a client that asks for hints and emits none.
Done
An address Plaza copies, and an e tag Plaza writes, carry a relay hint chosen from what Plaza actually knows about where the thing lives, or carry none and say why in the code rather than by omission.
The reading half of this landed in #358: an
nevent1ornprofile1that names relays now gets those relays asked, bounded, when the thing it points at is not on the reader's own.The writing half is untouched, and it is the same gap pointing outwards.
copy_neventencodes with no relays at all.encodeNevent(fba.allocator(), note.event_id, &.{}, note.pubkey, 1). So an address Plaza puts on the clipboard asks every other client to solve exactly the problem #259 described, and hands them nothing to solve it with. Plaza knows where it got the note: it came off a socket in the pool, and the author's write relays are in the outbox tables the feed is already routed by.contentTagsdecodes anneventand drops its relays too. When Plaza writes a note that quotes another, theetag it builds has an empty relay field. NIP-10 and NIP-22 both put a relay hint there precisely so the next reader does not have to guess.copy_npubhas the same shape, withnprofile1as the richer form.Why this is its own issue and not part of #358
It changes what Plaza publishes, rather than what it reads. That needs its own decisions:
None of that blocks anything. It is worth doing because the reading half only helps Plaza's readers if other clients do it too, and Plaza is currently a client that asks for hints and emits none.
Done
An address Plaza copies, and an
etag Plaza writes, carry a relay hint chosen from what Plaza actually knows about where the thing lives, or carry none and say why in the code rather than by omission.