Nostr Web Client

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.

Reply to this note

Please Login to reply.

Discussion

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.