nostr:nprofile1qqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgspr9mhxue69uhkscnj9e3k7unpvdkx2tnnda3kjctv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcppemhxue69uhkummn9ekx7mp0g4rts7 is it possible to disable outbox model in Coracle?

Reply to this note

Please Login to reply.

Discussion

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.

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.

And this is why you use a dedicated relay for these. But that’s fine.

Yeah, don't let me stop you

Why not just a set of read/search/discovery relays that will be saved only as "app" relays and not tied to your outbox model? Like many other apps do.

I used to have this option on my client but I removed to be outbox only, as your inbox/outbox relays aren't necessarily the same as the people you follow for the main feed, and when browsing specific relay feeds, you might not find kind 0 events in that relay feed

Yeah but if I pay for an aggregator it should, right? In an ideal situation I should be able to connect to *one* relay if I wanted to

Yes, but clients should implement that and allow you to input a relay aggregator in the settings and then only connect to that relay, I am not sure if there's any client that has it, I would love to implement that as it would save *a lot* of bandwidth, is there any relay aggregator implementation out there? (one that does all the outbox stuff for each subscription filter)

Sort of. Nostr.land reads from every relay right now, including personal ones.

To add full read outbox support I’m not sure.

I remember this project from a while ago and it's version 2 in golang, but don't know the implementation details https://github.com/Yonle/bostr

Why not?

Because if you already read from all relays, what will outbox help with?

The event kind support on aggr is limited for now. Currently working on the NFDB2 rewrite to address some issues before allowing that

If "all" includes all my following's latest write relays, sure