>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.