nostr:npub108pv4cg5ag52nq082kd5leu9ffrn2gdg6g4xdwatn73y36uzplmq9uyev6 nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr nostr:npub18kzz4lkdtc5n729kvfunxuz287uvu9f64ywhjz43ra482t2y5sks0mx5sz

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 nostr:npub12rv5lskctqxxs2c8rf2zlzc7xx3qpvzs3w4etgemauy9thegr43sf485vg )

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?

nostr:nevent1qqsf4rsntrtg904wdyefspjpsxm0p8q262mma5j84m4fnh0zvh27guspz3mhxw309akx7cmpd35x7um58g6rsd3e9upzq6q7e8qrw2urkz2r3p35py4lf0udpygvgvhghp7204ezetl83d88qvzqqqqqqykss3d6