Nostr Web Client

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

nostr:nevent1qqs2c32nxt7z00g9ytcenuez5mc9m83x58mluhe8au0hr057y9j8tsgpz3mhxw309akx7cmpd35x7um58g6rsd3e9upzq6q7e8qrw2urkz2r3p35py4lf0udpygvgvhghp7204ezetl83d88qvzqqqqqqypgk8fm

tf 1y ago

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?

nostr:nevent1qqsf0m2xuacn8n4zs95wmxs0kxjkgsl2gxv6ggza9frkg772mu3wggspz3mhxw309akx7cmpd35x7um58g6rsd3e9upzq6q7e8qrw2urkz2r3p35py4lf0udpygvgvhghp7204ezetl83d88qvzqqqqqqyz30cfa

Reply to this note

Please Login to reply.

Discussion

tf 1y ago

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

hodlbod 1y ago

Great points. This applies to local relays as well, which can't be configured without asking the universe to deal with them as well. I could see the following categories being useful:

- Read - I read notes _for me_ from this relay

- Write - I publish notes _from me_ to this relay

- Indexer - read relays used for kind 0/3/10002 (e.g. purplepag.es)

- Default - fallbacks when the outbox model fails to find a working connection for a pubkey's read relay (e.g. relay.damus.io)

- Local - read+write, for this device only (should be published somehow, but hard to scope to a single device)

- Read proxy - don't use my other selections, only use these "smart" relays

- Write proxy - ditto

tf 1y ago

What I meant to write

"most clients rely entirely on NIP-65 kind 10002 for relay configuration

E.g. a relay that is open-to-read & auth-to-write will be configured as a NIP-65 inbox & outbox by these clients, but can't be written to except by the author"