nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn is there a way to configure relays in Coracle to work with both NIP-65 inbox/outbox *and* paid relays?
So for nostr.wine which is free-to-read & pay-to-write I have
*But* I also want to read from nostr.wine
If I enable read others will try to write to it as my inbox (I think)
Similarly for filter.nostr.wine which is pay-to-read and pay-to-write, I don't want others to treat it as my inbox/outbox
Nostrudel & Amethyst work around this with app-specific relay settings
Tbf because NIP-65 ventures into this territory...
"When broadcasting an event, Clients SHOULD:
Broadcast the event to the WRITE relays of the author"
I think perhaps it needs more flexibility to cover client configuration with paid relays
So relays defined in kind 10002 could have separate read and write values for the author vs all others
nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z slight issue configuring relays for filter.nostr.wine
The relay is pay-to-read and pay-to-write and it broadcasts notes to public free-to-read relays
If I put it in Home which is outbox (I think) then others will try to read from it
So another section, home-but-not-outbox?
Wondering if NIP-65 needs more flexibility
I haven't thought this through much but
This could make NIP-65 more useful as a global relay configuration standard that could configure proxy and aggregating relays with support for the inbox/outbox model
Disambiguate read/write values in kind 10002 relay tags:
aread - author reads from this relay
awrite - author writes to this relay
oread - others read from this relay (outbox)
owrite - others write to this relay (inbox)
So if I have a relay filter.nostr.wine that aggregates from nos.lol and relay.nostr.band and doesn't allow direct writes from unauthorized users, kind 10002 relays would be
nos.lol
owrite
relay.nostr.band
owrite
filter.nostr.wine
aread
If I also use filter.nostr.wine as a proxy relay that broadcasts to nos.lol and offchain.pub:
nos.lol
oread
owrite
relay.nostr.band
owrite
offchain.pub
oread
filter.nostr.wine
aread
awrite
And if as well as reading and writing to filter.nostr.wine I read and write to relay.damus.io in a standard inbox/outbox way:
relay.damus.io
aread
awrite
oread
owrite
nos.lol
oread
owrite
relay.nostr.band
owrite
offchain.pub
oread
filter.nostr.wine
aread
awrite
This way there's no need to put things which are by nature global configuration into client-specific settings
From a UX pov the configuration for each relay is relatively easy: do I read from this? do I write to this? do I want others to read from this? do I want others to write to this?
I feel the current NIP-65 overloading of read/write values with different author/other client behavior will create more problems
And I don't agree with the nudging of clients away from using NIP-65 for global configuration beyond inbox/outbox model:
"kind:10002 events should primarily be used to advertise the user's preferred relays to others. A user's own client may use other heuristics for selecting relays for fetching data."
Nostr is a constellation of compatible apps, it's helpful for the user that everything that is by nature global configuration is supported
nostr:npub18kzz4lkdtc5n729kvfunxuz287uvu9f64ywhjz43ra482t2y5sks0mx5sz nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn dunno is that nonsense?
Put it on general for now :(
We are still figuring out how to place this one.
Thanks 👍
If Amethyst can be configured to work with filter.nostr.wine as intended, i.e. it's the only relay Amethyst reads from and writes to, this contradicts NIP-65
"When broadcasting an event, Clients SHOULD:
Broadcast the event to the WRITE relays of the author"
So the client choice is either
a) ignore the recommendation and support proxy/aggregating relays
b) follow the recommendation and break the use case
Clients making different choices will make global configuration impossible
=> seems NIP-65 is broken, can't work with aggregating/proxy relays and can't support global configuration of paid-for (auth-to-write, open-to-read) relays
