Mayyyybe but only if permissions are properly locked down. I opened a PR for this and reactions were mixed: https://github.com/nostr-protocol/nips/pull/1795
Discussion
Why do we need this as a command? The app can sign with the Nostr Connect event a delegation event, and this can be stapled with any future requests to the signer service.
The signer service is the one that enforces permissions, so it needs to have some way of scoping them down for the delegated connection. You could do this via command, event, fresh connection, whatever, but locking it would prevent users from accidentally escalating permissions by approving stuff.
Yes, the stapled delegation event can contain a policy. Basically says: “I am signer client X, I authorize Y to do sign 22242 events for 10 minutes on my behalf, signed by X on 3 July 2025”
Is this spec written down anywhere?
It’s an idea but it could be.
Or we can go the simpler route for read proxies.
Add an ASK-AUTH message, which allows relays to ask for the client to sign an AUTH event for them, only if they add it as a read proxy.
This does not require a Nostr Connect server when the user logs in with nsec/NIP-07, and solves the problem of “how do we get the connection string to the proxy”
Another thing is cursors. When you do a read proxy you are returning events from different relays, and that can cause gaps if you do created_at pagination.
This should be relatively easy I think.
I think this would be great. I built a proxy a long time ago: https://github.com/coracle-social/multiplextr but the AUTH stuff never got solved. I like your solution.
Will see if I can draft something. Could you also check my reply to NIP-C4?
I'm not convinced about the negative flagging, I still think 1984 is good enough
For example there’s a new post on your feed with content you don’t want to see.
It takes 10s or so to process an event including other latency, so for 10 seconds, you would see unwanted content.
Negative flagging fixes this by deferring media loading until it is confirmed negative.
I had users complain about this
I don't think so. Until the event is processed, you have no information either way. A negative flag just confirms that it's ok. Requests are async and so clients have to defer anyway. There also may not be a label for every event, does that mean the service is still processing, or is there a timeout relative to created_at? You have to deal with all these problems regardless, negative flags just clog up the network with a bunch of mostly useless events.