tf on Nostr: Alex Gleason hodlbod hzrd149 Mazin Sanity check please from ppl who actually know ...
Alex Gleason (npub108p…yev6) hodlbod (npub1jlr…ynqn) hzrd149 (npub1ye5…knpr) Mazin (npub18kz…x5sz)
Sanity check please from ppl who actually know this stuff before I make an ass on GitHub...
Outbox/inbox + NIP-65 is creating problems for users of paid or personal relays
Especially proxy/aggregating relays which can help with bandwidth and performance while still supporting inbox/outbox decentralization (cc calle 👁️⚡👁️ (npub12rv…85vg) )
Unless I'm greatly mistaken clients can't
* support proxy/aggregating relays without *either* breaking inbox/outbox *or* breaking NIP-65 as a global configuration with consistent behavior across clients
* equivalently, can't support inbox/outbox conforming to NIP-65 without breaking the proxy/aggregating use case
* can't support global configuration of standard paid-for or personal relays which require auth to read and/or write, making work for devs and users in implementing and maintaining per-client configurations for things which in practise are global configuration
TLDR;
As a simple pleb I can't configure most clients to work correctly with inbox/outbox and paid or personal relays (any relay that requires auth for read and/or write)
Because most clients rely entirely on NIP-65 kind 10002 for relay configuration
E.g. a relay that is auth-to-write will be configured as a NIP-65 inbox by these clients, but can't be written to except by the author
And I can't configure any client to work correctly with proxy/aggregating relays + inbox/outbox
This isn't a client issue it's a NIP-65 issue
===
Proxy/aggregating relays
filter.nostr.wine writes to the author's outbox relays and the inbox relays of tagged users, and reads from the author's inbox relays
The use case is the author's client only reads from and writes to filter.nostr.wine => one websocket connection and deduplicated events while still supporting inbox/outbox
How to configure this?
Putting filter.nostr.wine as the only kind 10002 relay supports the performance use case but breaks inbox/outbox and makes content undiscoverable (the relay is auth-to-read and auth-to-write)
Putting open relays into kind 10002 alongside filter.nostr.wine supports inbox/outbox but breaks the performance use case (if the author's client(s) support NIP-65 it reads from and writes to the open relays as well as filter.nostr.wine )
Creating client-specific configuration that the author's client reads/writes only from filter.nostr.wine would support the use case without breaking inbox/outbox (kind 10002 still advertises the outbox/inbox relays which filter.nostr.wine writes to/reads from), but it would contradict NIP-65
"When broadcasting an event, Clients SHOULD:
Broadcast the event to the WRITE relays of the author"
Clients making different choices to follow / ignore the above will break NIP-65 as global configuration
===
Standard paid and personal relays
Relays which require auth to read and/or write *can* be supported without breaking inbox/outbox + NIP-65 by specifying non-auth behavior in kind 10002 and auth-behavior in client-specific configuration
But forcing clients to implement and users to configure per-client what is naturally a global configuration sounds like a nostr anti-pattern
Many/most clients atm do not have client-specific configuration and so cannot support paid-for or personal relays that require auth without breaking inbox/outbox
===
=> seems the problem is NIP-65 overloading kind 10002 read/write behavior and over-specifying author client behavior?
So instead of just complaining, can this all be fixed by separate "author" and "other" read/write values?
Sanity check please from ppl who actually know this stuff before I make an ass on GitHub...
Outbox/inbox + NIP-65 is creating problems for users of paid or personal relays
Especially proxy/aggregating relays which can help with bandwidth and performance while still supporting inbox/outbox decentralization (cc calle 👁️⚡👁️ (npub12rv…85vg) )
Unless I'm greatly mistaken clients can't
* support proxy/aggregating relays without *either* breaking inbox/outbox *or* breaking NIP-65 as a global configuration with consistent behavior across clients
* equivalently, can't support inbox/outbox conforming to NIP-65 without breaking the proxy/aggregating use case
* can't support global configuration of standard paid-for or personal relays which require auth to read and/or write, making work for devs and users in implementing and maintaining per-client configurations for things which in practise are global configuration
TLDR;
As a simple pleb I can't configure most clients to work correctly with inbox/outbox and paid or personal relays (any relay that requires auth for read and/or write)
Because most clients rely entirely on NIP-65 kind 10002 for relay configuration
E.g. a relay that is auth-to-write will be configured as a NIP-65 inbox by these clients, but can't be written to except by the author
And I can't configure any client to work correctly with proxy/aggregating relays + inbox/outbox
This isn't a client issue it's a NIP-65 issue
===
Proxy/aggregating relays
filter.nostr.wine writes to the author's outbox relays and the inbox relays of tagged users, and reads from the author's inbox relays
The use case is the author's client only reads from and writes to filter.nostr.wine => one websocket connection and deduplicated events while still supporting inbox/outbox
How to configure this?
Putting filter.nostr.wine as the only kind 10002 relay supports the performance use case but breaks inbox/outbox and makes content undiscoverable (the relay is auth-to-read and auth-to-write)
Putting open relays into kind 10002 alongside filter.nostr.wine supports inbox/outbox but breaks the performance use case (if the author's client(s) support NIP-65 it reads from and writes to the open relays as well as filter.nostr.wine )
Creating client-specific configuration that the author's client reads/writes only from filter.nostr.wine would support the use case without breaking inbox/outbox (kind 10002 still advertises the outbox/inbox relays which filter.nostr.wine writes to/reads from), but it would contradict NIP-65
"When broadcasting an event, Clients SHOULD:
Broadcast the event to the WRITE relays of the author"
Clients making different choices to follow / ignore the above will break NIP-65 as global configuration
===
Standard paid and personal relays
Relays which require auth to read and/or write *can* be supported without breaking inbox/outbox + NIP-65 by specifying non-auth behavior in kind 10002 and auth-behavior in client-specific configuration
But forcing clients to implement and users to configure per-client what is naturally a global configuration sounds like a nostr anti-pattern
Many/most clients atm do not have client-specific configuration and so cannot support paid-for or personal relays that require auth without breaking inbox/outbox
===
=> seems the problem is NIP-65 overloading kind 10002 read/write behavior and over-specifying author client behavior?
So instead of just complaining, can this all be fixed by separate "author" and "other" read/write values?
quoting nevent1q…s3d6I 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?
nevent1q…0cfa