I'm going crazy with all the different ways of creating author and article references.

You can use @somebodiesname or @somehexid or @npubsomenpub or nostr:somenpub or @nostr:somenpub or nostr:somehexid or @nostr:somehexid. Did I forget anything? It's getting so that it's easier to describe what is NOT an note or author reference.

Of course the clients should not show any of these since they should be turning them all into #[n] references.

Or am I missing something?

Reply to this note

Please Login to reply.

Discussion

arthurfranca, #[2]​ and #[3]​ hardforked nostr again https://github.com/nostr-protocol/nips/blob/master/27.md

Entities were showing up in notes anyway, we just made it official. #[] notation is inherently ambiguous, I complained about this all the way back in November

It seems to me that the format of references is the business of the client and not the spec. The #[n] convention has worked well so far. IF there's an ambiguity then we should resolve that within the #[n] approach rather than forcing so many new formats onto the clients.

Just my 2 sats.

>From: hodlbod<-DerekRoss at 04/22/23 17:59:26 on wss://relay.damus.io

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

>Entities were showing up in notes anyway, we just made it official. #[] notation is inherently ambiguous, I complained about this all the way back in November

The reason damus adopted it was because it fixes 2 issues: allows you to make kind1 quoted reposts without including the e tag (which makes it not show up in threads which is good)

It also allows for non-p tag mentions in DMs which fixes mention leaks.

>From: jb55 at 04/22/23 18:32:01 on wss://relay.nostriches.org

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

>The reason damus adopted it was because it fixes 2 issues: allows you to make kind1 quoted reposts without including the e tag (which makes it not show up in threads which is good)

You could do that with "e-" tags or something like that. Clients could do with them what they like.

>It also allows for non-p tag mentions in DMs which fixes mention leaks.

Clients could do that by putting references into a dm-tags element that is encrypted. Clients could decrypt it and add it to the tags element.

In any case, the format and processing of references is an issue private to clients. Clients should not export their own formats. Otherwise every new client will come up with another new format that all the other clients will have to deal with.

At the moment I'm seeing every possible combination of @ and :nostr and npub1 and note1; and there's no end in sight.

nostr: prefixes are just a url scheme, like any other url. @hex is evil and not standard. Bare bech32 entities are non-standard as well I think. So clients not using either just be the two notations that are

Oops, fat fingered that last sentence, clients not using either legacy or nostr: are the problem

Is Damus on the HF?

?cid=2154d3d7fi7v8g1e2zd5k6ukk3v7wg45r16cmcfhozj3sgrl&rid=giphy.gif

#[] references are technically outdated. They should write nostr:nevent / nostr:nprofile / nostr:naddr instead

But in practice, you have to support them all if you want your users to have a good experience.

By "all" I assum you mean every possible permutation of @ and npub and nostr:. And, if #[4] is right some of those should not create #[n] and "p" tag references and should should? Ugh.

>From: vitorpamplona<-De... at 04/22/23 18:52:58 on wss://atlas.nostr.land

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

>But in practice, you have to support them all if you want your users to have a good experience.

The @ thing is not spec’d and should never show up in posts. Its an artifact of people trying to use a damus feature in other clients.

more-speech translates the @ things into #[n] references, which is spec'd in Nip-08. My intent in more-speech is to ignore the :nostr stuff in the outgoing messages and to translate them into clickable references on the inbound messages.

>From: jb55 at 04/22/23 21:26:10 on wss://relay.damus.io

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

>The @ thing is not spec’d and should never show up in posts. Its an artifact of people trying to use a damus feature in other clients.

Keep in mind the difference between a #[] link with a required e/p/a tag and a simple nostr: without the e/p/a tag. The nostr: doesn't necessarily add the tag, which makes it great for DMs: you can cite others without tagging them, thus avoiding a notification on something they cannot read.

It seems to me that would have been better done through a separate encrypted tags array "dm-tags" in the DM.

>From: vitorpamplona<-De... at 04/22/23 22:08:03 on wss://atlas.nostr.land

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

>Keep in mind the difference between a #[] link with a required e/p/a tag and a simple nostr: without the e/p/a tag. The nostr: doesn't necessarily add the tag, which makes it great for DMs: you can cite others without tagging them, thus avoiding a notification on something they cannot read.

When #[4]​ talks, people listen. Plus I’ve been drinkin

Why should that be outdated? The #[n] syntax is nicely concise and allows every client to use whatever format they want for a reference.

>From: vitorpamplona<-De... at 04/22/23 18:52:31 on wss://atlas.nostr.land

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

>#[] references are technically outdated. They should write nostr:nevent / nostr:nprofile / nostr:naddr instead