Nostr Web Client

It depends on where you would expect the note to "belong". In most cases, you would encode the nevent with 3-5 of the author's "write" relays, pulled from their NIP 65 10002 event. In some cases, an event might "belong" elsewhere, for example with NIP 29 communities, where a note is posted to a community relay.

For the examples you mentioned, the second example includes a hint for finding the e-tagged event, not the cited event itself. The hint is also not ideal, because it uses the event author's relay, not one of nostr:nprofile1qy88wumn8ghj7mn0wvhxcmmv9uq3jamnwvaz7tmjv4kxz7fwwdhx7un59eek7cmfv9kz7qguwaehxw309aex2mrp0yhxy6t5vdhkjmnsv9exktnrdakj7qg4waehxw309aex2mrp0yhxgctdw4eju6t09uq3wamnwvaz7tmjv4kxz7fwwd6x7mn9wghxxmmd9uqzq3e0gs8jnmued6f2rp4c6vs07xqvs4vs8zpwt82smcdch4txjvq765gqlc's relays (he doesn't have relay.primal.net in his 10002), but it does work because primal happens to have the note in question.

The first example doesn't make any sense, I don't know what `r` tags mean when applied to kind 1. NIP 65 only defines `r` tags applied to kind 10002, not any other event.

Dikaios1517 7mo ago 💬 1

For asknostr.site, I don't think there's going to be much risk that the notes would "belong" somewhere other than the author's outbox relays, so I don't think nostr:npub132ns73pnz2w6mdcnxzkgna3t2dx25gq2nulwxjdq7jj4jvrn6xnqup8cn4 has to worry about that. I definitely see where that would come into play for Flotilla, though.

nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z mentioned that Amethyst encodes the first 3 outbox relays from the author's 10002, if they have one that can be found, or the first 3 relays the app received the note from, if no 10002 can be found.

I wonder if it would be better to do something like, encode the first 3 outbox(write) relays from the author's 10002, so long as they have one AND the note in question can be confirmed to be available from those relays, otherwise encode the first 3 random relays that the app received the note from.

Reply to this note

Please Login to reply.

Discussion

hodlbod 7mo ago 💬 2

That would be ideal, but it's probably more of a job for clients helping users pick their relays. I've wanted to build a relay management client for a long time that checks relay availability, specs, policy, etc (directly and via nip 66), as well as probing the relay for user access. Then, warning the user if a relay goes down or misbehaves, and migrating notes back and forth when selections change. Clients shouldn't duct-tape the network together with broken heuristics if users can't be bothered to make good relay selections.

Dikaios1517 7mo ago

That's the thing, right? Users have no idea what relays they should choose, or why they might want to choose one relay over another, and there are so many relays out there that it becomes paralyzing to try and figure out which ones are "good."

Nostr.watch is cool, but I'd really like to see a relay selection tool that asks the user some basic, multiple choice questions about what they will be using the relay for, then displays a list of relays that would work for the user's intended purpose, ranking them by a few uptime and availability stats, and indicating if the relay has any restrictions for read or write access, such as paid or PoW relays.

hodlbod 7mo ago

Agreed, such a thing is desperately needed

𝐒𝐧@𝐱 7mo ago 💬 1

nostr:nprofile1qyghwumn8ghj7mn0wd68ytnhd9hx2tcpt3mhxue69uhhqun00pujumn0wd68yttjv4kxz7fwv9c8qtenxajrgcenxd3rveryxyck2vf4x5ekxvmyxaskzcnzv4jrydrzvdjnjcf4xpnxxdejvcmnzdpkx3jrxwtx8pnr2vnrv5urxcn9vdnrsqpqkun5628raxpm7usdkj62z2337hr77f3ryrg9cf0vjpyf4jvk9r9sgmztcn on the first question you asked to be able to copy the event id. Did you even mean NEvent? Or just the event id (hex)?

Generating a useful 'NEvent` according to the comments requires me to jump through some hoops (getting author 10002 event) so I wonder if it's even worth the effort?

I always thought that a NEvent (from NIP19 docs) is built from the original event only. Because even if you do the extra effort of including the first 3 outbox relays there is no guarantee that that event can be found on those relays. So geeking out on the idea of checking if that event is there before i include that relay. I'm feel like i'm going down the rabbit hole with this one.

From the NIP-19 docs:

So optional. A simpler implementation would be to either:

- only include the relay hint if it was hinted in the e-tag

- include the relay i got the event from (which I'm currently not storing)

Letting this sit for a few days to think about it. I secretly hope you just needed the event id 😃

Dikaios1517 7mo ago

Nah, I wanted the nevent. Sorry.

Reason is, asknostr.site can't (and shouldn't) display all event kinds that might have been quoted in the original question, or in some of the responses. If users can snag the nevent and paste it into another client, that client will have a much easier time finding and displaying the note with the relay hints than if they search with just the note ID alone.

I don't think e tags would be the route to go. My understanding of them from NIP-10 is that they are referring to some other event that the event in which they are found is referencing, because it is a reply to the tagged event. Therefore, the relay hint found in an e tag is not a relay hint for the event containing the tag, but a hint for finding the event that is being referenced.

I think if you encode the relay that you received the event from into an nevent, that would be sufficient in most cases.

I still think best practice would be to encode the author's outbox relays if the event can be found on them, since that is what the author has proactively indicated to be where they want their notes to be fetched from, and only encode the relay(s) you received the event from if it isn't available from their outbox relays, or they have no 10002. But, there is the ideal practice, and there is what is practical and straightforward to implement and that will do the job in most circumstances, right? 😂