Conversation

Notices

1. Embed this notice
   PABLOF7z (fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52@mostr.pub)'s status on Wednesday, 15-Mar-2023 02:03:21 JST PABLOF7z

   • mikedilger
   Added @ee11a5df's Gossip to https://nip26.lol ???? So happy to have another one! https://nostr.build/i/nostr.build_1111ec49455c6280655e0b77925c8cf0936cac6d880406d2f3a218597fc7895c.png
   • Embed this notice
     Alex Gleason (alex@gleasonator.com)'s status on Wednesday, 15-Mar-2023 02:03:04 JST Alex Gleason

     in reply to

     • DerekRoss
     • fiatjaf
     • Karnage

     @3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d @1bc70a0148b3f316da33fe3c89f23e3e71ac4ff998027ec712b905cd24f6a411 @3f770d65d3a764a9c5cb503ae123e62ec7598ad035d836e2a810f3877a745b24 @fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52 It would be better if you could use the same pubkey and sign events with a different private key instead of using a delegation tag. Then at least queries and indexing will still work properly between relays and clients, but you’d have to verify the events differently.

     I think it’s essential and NIP-41 isn’t totally a replacement.

   • Embed this notice
     fiatjaf (3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d@mostr.pub)'s status on Wednesday, 15-Mar-2023 02:03:05 JST fiatjaf

     in reply to

     • DerekRoss
     • Karnage
     It's a very inelegant solution that adds a lot of complexity. It wasn't conceived with the goal of safeguarding people's keys at all. If it was done with that in mind I bet we could have made something better. In any case, rushing into it feels misguided. For the sole purpose of keeping identities safe I believe NIP-41 is a superior solution, although not perfect either, of course.
   • Embed this notice
     Karnage (1bc70a0148b3f316da33fe3c89f23e3e71ac4ff998027ec712b905cd24f6a411@mostr.pub)'s status on Wednesday, 15-Mar-2023 02:03:13 JST Karnage

     in reply to

     • DerekRoss
     • fiatjaf
     What’s your concern?
   • Embed this notice
     fiatjaf (3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d@mostr.pub)'s status on Wednesday, 15-Mar-2023 02:03:14 JST fiatjaf

     in reply to

     • DerekRoss
     I think NIP-26 is a bad idea that will eventually destroy Nostr and that you NIP-26 enthusiasts are not thinking correctly and you should stop a little. Should I still merge your PR?
   • Embed this notice
     DerekRoss (3f770d65d3a764a9c5cb503ae123e62ec7598ad035d836e2a810f3877a745b24@mostr.pub)'s status on Wednesday, 15-Mar-2023 02:03:19 JST DerekRoss

     in reply to

     • fiatjaf
     Oh. I currently use nos2x. I'd run your PR version ?
   • Embed this notice
     PABLOF7z (fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52@mostr.pub)'s status on Wednesday, 15-Mar-2023 02:03:19 JST PABLOF7z

     in reply to

     • DerekRoss
     • fiatjaf
     ? https://github.com/pablof7z/nos2x
   • Embed this notice
     PABLOF7z (fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52@mostr.pub)'s status on Wednesday, 15-Mar-2023 02:03:20 JST PABLOF7z

     in reply to

     • DerekRoss
     • fiatjaf
     None. Get Alby could once they merge my PR. I also wrote support for @3bf0c63f's nos2x but never sent the PR. I might do it in the next couple of days. https://github.com/getAlby/lightning-browser-extension/pull/2063
   • Embed this notice
     DerekRoss (3f770d65d3a764a9c5cb503ae123e62ec7598ad035d836e2a810f3877a745b24@mostr.pub)'s status on Wednesday, 15-Mar-2023 02:03:21 JST DerekRoss

     in reply to
     what extensions support NIP-26?
   • Embed this notice
     fiatjaf (3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d@mostr.pub)'s status on Wednesday, 15-Mar-2023 05:50:57 JST fiatjaf

     in reply to

     • Alex Gleason
     • DerekRoss
     • Karnage
     I see. That was the initial design of NIP-26 before we switched to having different keys for backwards-compatibility. But your point makes sense. We might be able to come up with a magic cryptography trick that does that. It would break backwards-compatibility, but, well, NIP-26, the way it is being pushed, also breaks backwards-compatibility, so we might as well do something better than NIP-26 for the purposes.
     Alex Gleason likes this.
   • Embed this notice
     Alex Gleason (alex@gleasonator.com)'s status on Wednesday, 15-Mar-2023 05:59:19 JST Alex Gleason

     in reply to

     • DerekRoss
     • fiatjaf
     • Karnage

     @3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d @1bc70a0148b3f316da33fe3c89f23e3e71ac4ff998027ec712b905cd24f6a411 @3f770d65d3a764a9c5cb503ae123e62ec7598ad035d836e2a810f3877a745b24 @fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52 Agreed. Since this feature isn’t useful unless relays support querying for it, being backwards-incompatible seems like the correct thing to do. Then at least relays might give me an error and I can choose relays which support it.