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
quotingI haven't thought this through much but
nevent1q…s3d6
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
Mazin (npub18kz…x5sz) PABLOF7z (npub1l2v…ajft) hodlbod (npub1jlr…ynqn) dunno is that nonsense?
nevent1q…0cfa