In your DM code you will now be able to have a different render_blocks() function that makes the mentions inline and doesn’t put them into the tags field without it looking any different to the user

Haha, one reason is to make it optional when you mention someone if you want it to notify the person or not. Clients can decide whether they place mentions into the tags field or if they leave them inline. And particularly for DMs to avoid the mentions being leaked to the public they should stay inline

Created a PR on Damus to start extending support for NIP-27 (#[0], arthurfrance, #[1])

It adds the necessary parsing code to detect nostr: bech32 entities and represent them as regular mentions. nostr:naddr and nostr:nrelay get parsed but don’t have any special UI as of yet.

With this functionality, DMs are one step away from not leaking mentions any longer. Instead of converting mentions to #[idx] they could be converted to nostr:npub… and not added to the tags field.

Any feedback is welcomed!

https://github.com/damus-io/damus/pull/837

#[2]

More testing…. nostr:note1dnlr8kxchf8vd0plnu97t7c7z4jfe7k98htmz9ja53ztr0xlr3sqhrmp9l

Done! Hope that helps whoever’s building the video player :)

With Apple HLS support?

Oooh seems dope

Ahaha it supports it but they parsed my invalid prefixes

I wonder which clients are supporting this currently? Working on extending support of nostr:note1 and nostr:npub1 to Damus. Is this working in your client?

Pick me! Pick me!!

Thanks everybody for taking part in the #Nostropical hackathon vote, and congratulations to Felix and his project Nostr Follower!

#[1]

There’s an existing protocol called XMTP that seems to use the same kind of system of sending an invitation to generate keys secretly. It’s in the alt-coin space and appears to be completely centralised for the moment, but we can certainly borrow some ideas from them https://xmtp.org/docs/dev-concepts/invitation-and-message-encryption

Agreed. Would open up a lot of options. Our temporary solution is to generate a new private key that we encrypt and store in a replaceable event, which permits us to derive any keys we want. It helps on the author side, but for recipients we still can’t derive their keys, so still need some sort of invite

Yes, we considered this, but to derive keys from your private key would require direct access to your key which isn’t supported through window.nostr and would require support from signing devices. Not impossible but a little harder.

And further more, if you never send invites it’ll be harder for clients to find open conversations. You’ll have to query a bunch of keys of people you follow to find conversations. So each variant comes with its own set of compromises

Done! ❤️ all sats welcome

Like Vitor suggested, it could help for the wrapped DMs to use a different kind so the relays are able to treat them differently from regular DMs, and optimise accordingly.

Is this filtering happening on the client level? If so could the client accept DMs from unconnected pubkeys provided they contain a signed invite from someone in your network?

I’m working on a pull request for Damus that will stop it from leaking mentions. NIP-27 has been drafted to deprecate the old behaviour of pulling out mentions into tag fields. That’s the most egregious bug right now. After that we need to stop publicly addressing the sender and recipient on DMs to get rid of inbox peeking

Yep, I agree that a new kind would be better for wrapped DMs, allows relays to recognise them

This is a good idea! And shouldn’t be too hard as Damus has already integrated nostr.build uploads in the post page