William Casarin

> This is the best proposal I have in my mind now, it mixes in the best points of all proposals: I think this is it!

on the client side, I would just treat the pubkey as a calculated field, but otherwise no changes would be required! woot.

If we're switching to tags: ``` token = A_signature(sha256("nostr:delegation:kind=1&created_at>1660592348&created_at1660592348&created_at

Might be good to add some motivating examples. I don't know what I would use this for.

Should we just use the tag `t` (hashtag) or `r`? It seems like these have similar use cases. Thinking of the single-char economy here.

> The first use case is meant to make it so users can open their client -- or different clients -- in different devices and have their list of relays...

On Sat, Aug 13, 2022 at 08:20:18PM -0700, Ricardo Arturo Cabral Mejía wrote: >> I see this nip as benign but don't see the benefit yet. > ***@***.*** There's currently...

I like how simple this is. ACK. > Damus clients for example only talk to damus relay I think. Not true, damus uses relays in your profile and you can...

On Wed, Jul 20, 2022 at 06:51:37PM -0700, Semisol wrote: >ACK. Though, couldn't this be generalized to "client authentication" than just limiting kind 4 requests? how would this work? I'm...

pushed a rebased version of this here: [here]: https://github.com/jb55/nips/tree/nip-21-non-public-dms ``` git fetch [email protected]:jb55/nips nip-21-non-public-dms ``` ``` git range-diff origin/nip-21-non-public-dms...jb55/nip-21-non-public-dms ``` ```diff -: ------- > 1: 1b94488 nip16: small fix -:...