726a1 - 16d
nostr:nprofile1qqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgspr9mhxue69uhkscnj9e3k7unpvdkx2tnnda3kjctv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcppemhxue69uhkummn9ekx7mp0g4rts7 is it possible to disable outbox model in Coracle?
97c70 - 16d
No, coracle's relay selection is coracle's relay selection. I'd like to improve on this but it's pretty locked in. You hoping to use read proxies or something?
Wanted to test between more decentralized (outbox hitting all relays, slower) vs more centralized (paid relay, faster). At least in theory. I actually have no idea what I am paying a premium relay for.
Yeah, premium relays and outbox don't play well together on the read side. Paying your outbox relays for content retention does make sense, but read proxies need to be specified some other way.
semisol @semisol - 16d
Ideally for read proxies there would be a way to “label” events. Like is this paid content, possibly spam, etc.
Yeah, and read proxies have limits as a result of auth-protected relays
This can be solved with Nostr Connect-based delegation.
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
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.
It just seems like a different way of doing the same thing
This has the benefit the signer does not need additional state to track.
I see what you mean, not a bad idea
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.
