Nostr Web Client

So there appears to be much confusion about how mentions should work and I think it comes from

* some clients implementing their own thing

* two nips around how to encode mentions in events

Events should either notify the mentioned or not. That's where the two standards differ.

If no notification is desired, the event.content should just contain the bech32 encoded reference.

If notification is desired, a tag should contain what is referenced and the event.content should only reference the respective tag.

When authoring TextNotes, the editor should not expect the user to know the difference. Opening a list of people when pressing the "@" symbol is convenient but does not mean that the symbol has to be part of the Note's serialization.

I would suggest to add some bell icon 🔔🔕 next to every reference which would allow the user to switch the notification on and off.

Advanced clients should allow notifications without references in the content.

#[0] #[1] #[2] #[3]

Ironically I do not know now if the references to four client devs above will trigger notifications as irisTo renders them as @npub

Reply to this note

Please Login to reply.

Discussion

unclebobmartin 2y ago

In more-speech if you use @ the reference is tagged. If you use nostr: it does not.

Leo Wandersleb 2y ago

That's an ok-approach for technical users but the fact that these details are little known to even client devs should show that some further abstraction would be good.

Vitor Pamplona 2y ago

Good idea on the bell icon.

fiatjaf 2y ago

I'm hoping NIP-08 will die and everybody will implement just NIP-27.

Leo Wandersleb 2y ago

So a profile referenced in a p-tag would be exclusively for notifications and in the content for display. Slightly more bytes than keeping nip-08 alive but simpler and complete for sure.

Should we mark nip-08 as obsoleted by nip-27 or are there any strong objections? Clients will probably forever want to render these first text notes correctly but maybe if clients stopped authoring them, it could be a lower priority task in every new client.

unclebobmartin 2y ago

I do not understand the reasoning for wanting to deprecate NIP-08.

The advantage of NIP-08 is that the format of references is strictly in the domain of the client. A client can interpret and render a reference any way it desires, because the reference is always transmitted as #[n] with a "p" tag.

The existence of the "p" tag allows clients to query relays for notes that refer to certain authors. That's a valuable feature. I want to be able to query relays to see who is publicly referring to me, or to you.

The disadvantage of NIP-08 is that people can query relays to see who is mentioned in a DM. That's bad. DMs need to be private. My solution to that would be to add a "dm-tags" field with encrypted "p" tags to the kind-4 (DM) event. The client could decrypt it and render the references as usual. That's not a hard thing to do.

The advantage to NIP-27 is that it creates a new url prefix `nostr:` for all manner of uses.

Using NIP-27 for mentions prevents the creation of "p" tags. That's good for DMs, but it also allows authors to publicly gossip about other authors without alerting the subjects of that gossip. i.e. NIP-27 references support sub-tweeting (sub-noting).

My strategy in more-speech so far is to make NIP-08 references convenient by allowing the user to type @; while making untagged references inconvenient by forcing the user to type `nostr:`. I will render the former as @ and the latter as `nostr:` so that readers will know that the author is sub-noting.

>From: Giszmo at 04/23/23 16:41:49 on wss://relay.nostriches.org

>---------------

>So a profile referenced in a p-tag would be exclusively for notifications and in the content for display. Slightly more bytes than keeping nip-08 alive but simpler and complete for sure.

>Should we mark nip-08 as obsoleted by nip-27 or are there any strong objections? Clients will probably forever want to render these first text notes correctly but maybe if clients stopped authoring them, it could be a lower priority task in every new client.

unclebobmartin 2y ago

Having looked over the NIPS again, I do not see where the nostr: is not included in the "p" tags. Yet I believe it was #[9], along with others, who said that the nostr: format is being used to prevent "p" tags from leaking "p" tags in DMs.

Or maybe I'm just very confused.

jb55 2y ago

It provides the option. You can add it or not.

unclebobmartin 2y ago

OK. I see that now.

So. Clients can leak DM mentions if they want to.

I'll stick to both NIP-08 and NIP-27 in more-speech for the time being. I like the idea that my users can choose whether or not to leak, or sub-note as they choose; and that readers will be able to tell which they are doing.

>From: jb55 at 04/24/23 09:48:03 on wss://relay.nostriches.org

>---------------

>It provides the option. You can add it or not.

Leo Wandersleb 2y ago

Nip-27 is strictly more flexible than nip-08.

nip-08 entangles tags with content. While not terrible as both are available at the same time, it was lacking as it did not allow to reference a profile without also including a such tag. As you mentioned, this is particularly important when "gossipping" about third parties in DMs but users might decide to not notify somebody simply because for them it would only be spam. Fiatjaf or Jack for example - you know which Jack but to be unambiguous, I could "mention" him - can't consume all their notifications as they get notified all the time. By cutting back on the notifications, their experience would improve.

* #[] **always** notifies, conveys profile/event and where to find it

* nostr:... conveys profile/event and where to find it (in the "profile" variant, not the "npub"). Notification is optional.

In nip-27 the notification p-tag would not need to duplicate the relay information but would duplicate the pub key or event ID part, which is some extra bytes but that is acceptable in nostr where we care about being simple to work with. Maybe in a far future where all the world uses nostr, we will optimize this again but it should be easy to compress into a binary format to keep the optimization to the transport and persistence layer and away from the client devs.

unclebobmartin 2y ago

>From: Giszmo at 04/24/23 10:19:25 on wss://relay.nostriches.org

>---------------

>Nip-27 is strictly more flexible than nip-08.

Yes and no. NIP-27 gives the client the option to notify. Some clients might. Some clients might not. Some clients might not notify on DMs. Some clients might provide a checkbox, or a parameter or God knows what. As the author of a note, I hope I know how my client works, and how I can convince it to notify or not.

Authors have always had the option to not notify. You, Giszmo, just did it below with "jack". If you want to notify, use the gesture that invokes NIP-08. If you don't want to notify just use the author's name without adornment. Some clients could provide a special gesture for providing a picklist that inserts the author's name without adornment and therefore avoid notifying.

But whatever. Now we have three ways to mention people, two of which can notify. NIP-08 notifies. NIP-27 Might notify. The unadorned name never notifies. Great.

>nip-08 entangles tags with content. While not terrible as both are available at the same time, it was lacking as it did not allow to reference a profile without also including a such tag. As you mentioned, this is particularly important when "gossipping" about third parties in DMs but users might decide to not notify somebody simply because for them it would only be spam. Fiatjaf or Jack for example - you know which Jack but to be unambiguous, I could "mention" him - can't consume all their notifications as they get notified all the time. By cutting back on the notifications, their experience would improve.

>* #[] **always** notifies, conveys profile/event and where to find it

>* nostr:... conveys profile/event and where to find it (in the "profile" variant, not the "npub"). Notification is optional.

>In nip-27 the notification p-tag would not need to duplicate the relay information but would duplicate the pub key or event ID part, which is some extra bytes but that is acceptable in nostr where we care about being simple to work with. Maybe in a far future where all the world uses nostr, we will optimize this again but it should be easy to compress into a binary format to keep the optimization to the transport and persistence layer and away from the client devs.

s3x_jay 2y ago

FYI… NIP-27 says it’s a “draft”. While NIP-08 says it’s “final” (instead of “deprecated”).

unclebobmartin 2y ago

>From: fiatjaf at 04/23/23 16:19:20 on wss://relay.nostriches.org

>---------------

>I'm hoping NIP-08 will die and everybody will implement just NIP-27.