So the convention I am adopting in more-speech is to allow users to type @
Upon receiving a note from a relay more-speech will render #[n] references with "p" tags by looking up the profile of the user and replacing the #[n] with @
More speech will also look for "nostr:
Since more-speech also displays a tree list of the received notes, along with one line of abbreviated contents, it will translate any "nostr:
So there.
Shall we parse #[6] together?
https://imgix.ranker.com/user_node_img/57/1125580/original/hannibal-lecter-photo-u28
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.
#[1]
#[2] #[3]
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.
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.
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
>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.
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
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?
npub19mun7qwdyjf7qs3456u8kyxncjn5u2n7klpu4utgy68k4aenzj6synjnft
buq 'oH Nostr bolaD!
Nip-47. Once a majority of wallets support it, it'll be great.
>From: bumi<-DerekRoss at 04/21/23 12:11:08 on wss://relay.damus.io
>---------------
>What are your thoughts on Nostr Wallet Connect. which allows nostr clients to connect to lightning wallets and trigger payments through the NIP47 spec?
>The goal is to completely remove the friction to zap and make it simple to implement for clients as it is just another event.
We somehow have to get this kind:0 stuff under control; or at least provide a way so that my kind:0 events don't overwrite extra fields in your kind:0 events and vice versa.
>From: jb55 at 04/21/23 11:50:59 on wss://relay.nostriches.org
>---------------
>Just sets {reactions:false} on your kind0
1. If someone wants to put `Only-Zaps` into their client, and if their users want to turn it on, it's a free nostr.
2. I like likes. I'll continue to support them in more-speech, and continue to send them. It's a free nostr.
3. Bandwidth:
a. If every event causes Nl likes, then total bandwidth is E*(Nl+1). That could get high.
b. If every event causes Nz zap receipts, then total bandwidth is E*(Nz+1). Still high.
c. If Nz ~= Nl then there is no savings in throughput.
d. Zap receipts can be more expensive to process than likes. (e.g. more-speech does not signature check kind:7)
3. Bandwidth solutions: If we are really concerned about the bandwidth of kind:7 (likes), then we could invent some kind of piggyback scheme in which likes are held by the client and tacked on to the next outgoing note. e.g. a "likes" tag that takes an array of liked event ids. Clients could even limit these to once per hour or so. -- IF we were worried about bandwidth.
Do you know if that works for WoS?
>From: cameri at 04/21/23 11:41:02 on wss://atlas.nostr.land
>---------------
>I believe Amethyst and Alby implemented Wallet Connect, which let you zap with a single tap. With that on most clients I assume more people will be inclined just to try it.
Zapping is a multi-step process so I'm not inclined. I'm also not inclined to spend real money for something I simply want to acknowledge.
One way to acknowledge is to send +1 or 💯 replies. Such replies are even more expensive than reactions. Killing reactions will increase those kinds of replies.
>From: cameri at 04/20/23 21:18:17 on wss://atlas.nostr.land
>---------------
>Now that some people have #OnlyZaps do you feel more inclined to ignore, zap or reply a message you otherwise would have liked?
Yeah, actually the spec recommends a content of + or -, but allows for just about any kind of content in the reaction event. more-speech has 👍🏻 nd 👎🏻 buttons. When you hover over the reactions on a note, it lists all of them, who sent them, and what their content was. 🤙 is the most common because it comes from Damus. But you'll also see lots of + reactions from other clients.
I've never seen a - in actual use (except when testing.)
>From: JackDorsey at 04/20/23 17:06:44 on wss://relay.damus.io
>---------------
>There are dislikes?
The thing about reactions (likes and dislikes) is that they are currently about a third of events.