Good morning ☀️

If they are who they say they are and reverse their decision to onboard human rights activists this will be the biggest own-goal yet seen on nostr

Kicking things off with an insult isn't how to encourage debate of ideas

Now they have "cIa" comment spam in their threads, good for my block list not much else

Hopefully they will ignore the noise and stick around

The more things change...

Watching nostr's overgrown child undermine growing nostr among it's most natural demographic 🤦

Some of their members are political dissidents with real skin in the game, perhaps more so than anyone here

One would hope we could debate ideas instead of labels

Yes!

If you want to

Great article

The first time I've seen anyone elucidate general principles for developing social networks

The principle of least interference

The principle of relativity in cyberspace

The principle of natural patterns

Pipellia applies those principles to come up with interesting solutions...

nostr:naddr1qq3yuctkd9nkzarfdenj6argv5khxmmrd9skctt8wfshq6pd8yunzmpedcqsqq3q76p7sup477k5738qhxx0hk2n0cty2k5je5uvalzvkvwmw4tltmeqxpqqqp65wr6v6zx

1) oh dear Lord

2) you took your time

3) hmmmmmmmmmmmmmm

"it has to understand you and be grounded in your personal context, like your routine, your relationships, your communications, and more"

"some of the heavy lifting needs to be done off device in the cloud"

nostr:nevent1qqsz353k5uhhlkqr44easqdl25909uglk2aa0ut26ra42m824h0ye3spzemhxue69uhhyetvv9ujumt0wd68ytnsw43z7q3qcp2rxt39auw2plhte4vqvgnp80kcrlkrreql2te85ezvny7dv7hqxpqqqqqqz2pymlm

If I ever release an LP the title will be

"Purple ostriches swimming in gravy"

For now it's jus a DVM prompt / future cover artwork

nostr:nevent1qqsznehjmksx5r2mg2udet2w3gaflcl5wp3ux44zutnde4rjmwctrqqpz3mhxw309akx7cmpd35x7um58g6rsd3e9upzq6q7e8qrw2urkz2r3p35py4lf0udpygvgvhghp7204ezetl83d88qvzqqqqqqyku824t

My top two reasons would be

1) freedom of speech

2) meaningful and healthy social relations

Everything else is gravy, and we're swimming in it

nostr:nevent1qqs9vtu3xuz08ep488c08mjdn8xlc8le55gy4mmezsqynle0r5ccd2gpz9mhxue69uhkummnw3ezuamfdejj7q3qzl9whkrnjlfgg9q0k39r4tymu4ty3r5uy6tgxqdnd7f6xxcf8dmsxpqqqqdnjtzzkeg

Seems that Wikipedia would like editors to not insert their own interpretations, at least not directly, and that's being applied overzealously

Test

Don't rely on the official GitHub definition of the protocol, rely on ... newspapers (!)

Lol Wikipedia

Coracle is highly sexy on mobile

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"

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

🌍 : good morning Eliza!

Freedom of speech

Mastodon server admins: let's talk about the governance of intersectional federated communities in the context of white supremacy

Bluesky: maybe some day

X: not for the poors

Nostr: now

Thanks 👍

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

nostr:nevent1qqsf4rsntrtg904wdyefspjpsxm0p8q262mma5j84m4fnh0zvh27guspz3mhxw309akx7cmpd35x7um58g6rsd3e9upzq6q7e8qrw2urkz2r3p35py4lf0udpygvgvhghp7204ezetl83d88qvzqqqqqqykss3d6