To all client developers:
- Stop using note1 entities, or add e tags with hints when quoting stuff
- Add pubkey hints to e tags (https://github.com/nostr-protocol/nips/pull/1171)
- Publish kind 10002 relay selections so other clients can find your users' content
Coracle frequently has trouble loading quotes because some popular client or other is doing none of these things.
Hello, which specific other nostr apps are you aware of?
I have noted on damus 10002 https://github.com/damus-io/damus/issues/2120
is this why quotes and replies and photos don’t show up in nostr-bluesky Bridge? Interesting!
Thats a good question.
nostr:npub108pv4cg5ag52nq082kd5leu9ffrn2gdg6g4xdwatn73y36uzplmq9uyev6 nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s do yall know the root cause of quotes & replies not showing on nostr-bluesky bridge?
just posted that I noticed that to try to help understand the problem you described. there’s probably way more moving parts to that bridge so don’t take this as a request for devs to look into that specifically. I need to find more time to look at code myself.
Hard to say, but whatever client you're using (I assume damus?) is doing it. I'm able to find the parent note because it's tagging the user's pubkey, but there aren't any relay hints.
Is this why reply notes can’t show what they are actually replying to?
Like half of the thread will be missing?
Missing reply notes should be fixed post nip-10 marker update on damus
This has been implemented already right?
Because I don’t remember seeing missing replies for a while now.
I’ll keep an eye out in case I see any examples.
It depends heavily on your relay selections. If you use any of the more popular relays, you'll see most things, but there will still occasionally be missing notes that aren't on those relays.
Correct - there are still potential for missing parents notes, replies on damus post nip-10 marker update
In many cases, yes
I would really love seeing this resolved.
Sometimes I just ask the person to rebroadcast the note they are replying to.
But it would be nice if it just finds it.
It's very possible, but involves herding cats. Sometimes I wonder if I should just drop everything and go around submitting PRs for this kind of thing
Careful what you wish for. It’s an ungrateful, underappreciated full time job. Draft contributor description:
Yeah, I know haha
A few questions:
1) what exactly are you seeing?
2) what are you expecting to see that you are not seeing?
Can you provide screenshots?
Screenshot below — I'm able to find the embedded quote because my pubkey is tagged, and I know my 10002. But there are several issues with the note:
- My pubkey is tagged twice, with no relay hint
- The content contains a note1 entity rather than a nevent1 entity (which embeds relay hints)
- There are no mention `e` tags (NIP 10) or `q` tags (DIP 10) pointing to the quote
- When there are `e` tags, they don't include relay hints or pubkey hints (following a new PR to NIP 10: https://github.com/nostr-protocol/nips/pull/1171)
Note1 entities are more aesthetic than nevent1, so that doesn't necessarily need to be fixed. And I know Will has his eye on NIP 10, I just get the feeling that this problem is more widespread than just damus.
Thanks, added as comment to the issue
https://github.com/nostrability/nostrability/issues/40#issuecomment-2120993233
I dont see a screenshot included in your note.
Thanks for the detailed breakdown under the hood - this should be useful for yall galaxy brain devs to troubleshoot and find the solution(s).
Excuse my left curve product question:
from the perspective of the end user (assume they know nothing of what happens in JSON-land) what exactly is broken?
As a side note, it might be useful for NIP-56 reports and NIP-32 labels to be able to provably associate an e tag with a pubkey by providing the signature from the offending event.
NIP-56 requires a p tag for the event author, but the report author could have lied about the pubkey unless you fetch the (potentially illegal) event. But with (pubkey, event id, signature) you can be sure of authorship without ever fetching it.
(A side-side note: why does NIP-56 even exist separately from NIP-32? It seems like just a special case of NIP-32?)
I agree, I drafted NIP 32 as a response to 56 which I thought was too narrow. But backward compatibility being what it is, 56 is never going away. Which is ok, I've learned since then that use-case specific nips are normally better than highly generic ones. NIP 32 has good use cases, but more protocol-specific interoperable features deserve first-class support.
