tf on Nostr: I haven't thought this through much but This could make NIP-65 more useful as a ...
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
Mazin (npub18kz…x5sz) PABLOF7z (npub1l2v…ajft) hodlbod (npub1jlr…ynqn) dunno is that nonsense?
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?
quoting nevent1q…0cfaVitor Pamplona (npub1gcx…nj5z) 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
nevent1q…k8fm