nips
nips copied to clipboard
nostr-protocol
Deprecates NIP-26
Quite useful. Isnt it in use. And it's a simple way to do delegation, which is needed. What other way is there to do delegation?
Most relays and clients don't implement it and those who did are removing it.
I am not sure delegation is necessary.
The deprecation makes a statement that people are looking for a better/less cumbersome way to do this.
A few people are removing it and therefore its deprecated? I'm still adding it to nostrdb and am looking to add it to strfry soon.
I am not sure delegation is necessary.
delegation is quite useful for things like a twitter crossposter: give a service a signed delegation and they can create posts on your behalf. This is much simpler than alternative approaches like nsecbunker which requires it to be "online".
A few people are removing it and therefore its deprecated?
Yep, if people don't want to use it, there is no point in keeping it. I also checked nostr.wine's massive database and it looks like the last non-test delegated event was signed last September. Meaning, that no one is using this. Maybe @nostrband can give us more info.
I thought strfry had support for it. Since it doesn't, it reinforces the idea that no one is actually using it and should be deprecated or at least turned into a PR back again.
This is much simpler than alternative approaches like nsecbunker which requires it to be "online".
Sure but today's model requires every client and relay to implement it otherwise no one will see your crosspost. Since we can't control all clients, most users immediately see that as a deal breaker and go for an nsecbunker solution. Brands are particularly inclined to just use the nsecbunker instead of NIP26.
We kind of like NIP-26 too, although some type of provably derived key is probably a better solution.
If a single letter indexed tag was used to label the pubkey of the delegator, couldn’t clients implement the spec without relay cooperation except for deletion of the delegatee events by the delegator? We could move the conditions/delegation token to a separate tag for client side validation since that doesn’t need to be indexed.
I also checked nostr.wine's massive database and it looks like the last non-test delegated event was signed last September.
As far as I can remember the delegation event was created to support minds.com's nostr integration. They are most likely still producing events that use it
As far as I can remember the delegation event was created to support minds.com's nostr integration. They are most likely still producing events that use it
Can you find these events? I think users realized that even if these events have been created, very few clients and relays implement this NIP which means no one is seeing their posts.
I couldn't find anyone using this lately. But maybe they have their own relays and clients that work with it and have a separate nostr community somewhere.
Can you find these events?
They have a relay (wss://relay.minds.com/nostr/v1/ws) mentioned in their developer docs. We might find some there
I also thought NIP-26 was dying but I agree it could be good if relays and clients supported it.
delegation is quite useful for things like a twitter crossposter: give a service a signed delegation and they can create posts on your behalf. This is much simpler than alternative approaches like nsecbunker which requires it to be "online".
Imo the worse about nsecbunker is that in practice most of them will be custodial. Shared nostr accounts, like from companies, could have their privkey leaked by the nsecbunker provider.
The bad thing about NIP-26 is that a token can't be revoked, for example, when an employee gets fired. Though it could be less of a problem if using very narrow created_at limits.
Imo the worse about nsecbunker is that in practice most of them will be custodial.
I intend to create a standalone Bunker Android app that receives kind:24133 via push notification. It wouldn't work well for decrypting chat messages (too many requests via push will get you blocked), but simple singing and encrypting works. Then all you need is a trustless server to send those 24133 events via Push. The key is on the phone.
Maybe that's @pablof7z's vision for the nsec bunker as well. The key doesn't need to be online. There is no need to build a trusted server. Or maybe @greenart7c3 can add a NIP-46 signing module to Amber. Amber would then require Internet Permissions but It might make sense.
The bad thing about NIP-26 is that a token can't be revoked
Yep. NIP-26 essentially grants full signing control for a given time window forever.
I think we should keep this. It's simple, and even if it's not well-supported, it could prove useful.
It's simple, and even if it's not well-supported, it could prove useful.
I don't think it is that simple of a scheme. Its simplicity is misleading.
Imagine having to deal with delegated keys signing for NWC payments on behalf of the NWC key. Or Group admins delegating control over the group admin key to others. Bunkers with delegated keys for both the local keys and the main key.
Also, DMs from delegated keys should be merged with the main user's conversation. But which key do you encrypt the reply to? Both? What if there are 5 delegatees in the same "chat room"? Do we confuse users by putting all messages in the same room or by creating separate rooms whose names are the exact same (the main key) while the main key is actually not seeing the conversation? What do we do on GiftWraps?
On Wed, Feb 21, 2024 at 12:21:25PM -0800, Vitor Pamplona wrote:
The bad thing about NIP-26 is that a token can't be revoked
Yep. NIP-26 essentially grants full signing control for a given time window forever.
this is not true. you would almost always have an expiring delegation condition.
unless you're referring to sending backdated posts but that would easily be preventable using a bit of code.
Imagine having to deal with delegated keys signing for NWC payments [...] Or Group admins delegating control over the group admin key to others. Bunkers with delegated keys for both the local keys and the main key.
Yeah some use cases are hard to implement and probably won't be supported. I think the two use cases that make sense the most are loading delegated events on feed/user profile and DMs.
Also, DMs from delegated keys should be merged with the main user's conversation. But which key do you encrypt the reply to?
I think clients could present delegated DMs clearly as coming from a specific delegatee. Like on websites with embedded chat widgets where you talk to Alice, representing Brand XYZ and if you refresh the page maybe you will end up talking with John, still representing the same Brand XYZ. (edit: so not try to merge messages from delegator and delegatee)
All these suggestions look good but without actual implementations, we wouldn't know if they work or if they just create more problems.
These suggestions highlight my point that this NIP is poorly defined and should not be implemented as is.
I am still trying to find people actually using it.
We have a 2+ clients rule here. If no one is using it as it is defined, we should deprecate it.
Somebody else can then send a PR with the fixes and wait for 2 clients and relays to properly implement it before merging again.
They have a relay (wss://relay.minds.com/nostr/v1/ws) mentioned in their developer docs. We might find some there
This relay either doesn't have any posts or is broken because it simply does not respond to any requests, not even error messages.
Halt. I think all ya'll are moving too fast for this new Nostr ecosystem where adopting developers are just starting to come online.
I am building an X to Nostr crossposter and NIP-26 is the only solution I have found where I don't have to custody the user's nsec. I'd like to teach good practice of nsec self-custody and I as a service provider want to get permissions to create kind:1 events on the user's behalf for something like 30 days at a time. This way I custody a delegated child key, but not the master key which I know I should never have access to.
NIP-26 solves my problem today. NIP-46 doesn't solve my problem at all, because I cannot use it to create an automated solution that can publish Nostr events.
There is no NIP-26 alternative for automated, non-custodial event publishing and therefore I do not think it should be deprecated.
The expiration dates don't work because as soon as you delegate the key, the sub key can always post in the approved period forever (people can post in the past).
And no one ever wants that. They want a revocation mechanism that actually revokes privileges.
Also, there is no relay implementation that supports nip 26, so there is no "this works for me today".
Don't get fooled that this NIP actually works. It doesn't. It never did. It only makes the nsec unsafe.
@vitorpamplona i've never understood this criticism, all we would need to do is spec a max post in the past duration. is this your only concern?
There's other issues like clients can't filter for delegation tags. All clients and relays must implement this nip for it to be usable. When I was trying to implement it there's was only 1 or 2 relays with delegation support. Only gossip had delegation support, so only people that used gossip could see with who they were talking to. If people really want nip 26 we should change it to use 1 letter tag, but we still have to change all clients, relays, paid relays and file storage services
I've never understood this criticism, all we would need to do is spec a max post in the past duration.
I can only judge what's written. Some folks suggested specific changes but proposals presented as PRs also do not work in my mind.
is this your only concern?
No, I think delegation will never work until we figure out how to share encrypt/decrypt with both keys.
Besides that, I have several questions on what to do when the NIP-26 is used in tandem with other nips.
- Can the sub key kind:5 delete the posts of the main account?
- Can a delegated key send a NWC payment on behalf of the main key?
- What happens when a zap split names a sub account, should we search for the root key's ln address before paying?
- Should we allow delegations on NIP-98?
- Can NIP-29 groups be managed by sub keys?
- Do sub-keys automatically get access to all NIP-42 relays as the main account?
- When assembling Wiki pages do you consider delegated keys as the same?
- Can the sub key change NIP-51 lists of the main account? If so, what encryption should it use?
- Should the main account see the subaccount's drafts with delegation? Which encryption should we use for that?
- Should delegated keys also get access to the health data which is encrypted to the main account?
Delegation requires custom code in almost every NIP, which is terrible in my opinion.
I am building an X to Nostr crossposter and NIP-26 is the only solution I have found where I don't have to custody the user's nsec.
Use nip-46 - connect to user's key store and talk to it whenever a signature is needed, if it's offline - retry later.
