fiatjaf on Nostr: ...
gossip/outbox/etc was “added” to the protocol after most clients had already become accustomed to read/write to all relays. this is what happens when you iterate on protocols after they’ve been released in the wild.
it will sort itself out in time, but it may not be what you envision.
The "outbox model" was not a modification of the protocol nor a new invention, nor it is a new optional NIP.
hodlbod (npub1jlr…ynqn) once said about the idea, "this is just the Nostr model, it is how Nostr has to work if it can ever scale" (
https://t.me/gossipclient/605). Minutes after he came up with the name "outbox model" just so we could refer to this thing that Nostr clients should be doing but only Gossip was doing at the time.
The initial description of Nostr (nostr:naddr1qqzkummnw3eqzythwden5te0ve5kzar2v9nzucm0d5pzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqvzqqqr4gusz7vna) said: "you write a post, sign it with your key and send it to multiple relays (servers hosted by someone else, or yourself)" and under the "censorship-resistance" section it said "there will always be some Russian server willing to take your money in exchange for serving your posts".
Since you were supposed to write "to your own relay" or "to some Russian server" shouldn't it be reasonable to assume clients would be connecting to these relays to read your posts and the entire promise of censorship-resistance of Nostr rests on that possibility?
Implementation details were never specified because I think there are many ways to approach that and hoped clients would each have their own creative way of implementing it. Having the user manually specify a list of relays and then flood all relays in the list with queries for all people you're following was part of a very quick proof-of-concept I've implemented in (what was supposed to be the first version of) Branle in December 2022, but it should be obvious it's not a very user-friendly or scalable design, right?
Published at
2024-06-17 12:31:08Event JSON
{
"id": "05cb37f6c6211bedf48d55854141bf08df52ffb08cc9178cf5bac451d0c4fed0",
"pubkey": "3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d",
"created_at": 1718620268,
"kind": 1,
"tags": [
[
"client",
"gossip"
],
[
"q",
"28932d88e9fa4046e53fd15f6154eb0b7715799aadbd53e3b72fd08327a88c00",
"wss://a.nos.lol/"
],
[
"p",
"97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322"
],
[
"a",
"30023:3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d:nostr",
"wss://fiatjaf.com",
"mention"
]
],
"content": "nostr:nevent1qqsz3yed3r5l5szxu5lazhmp2n4skac40xd2m02nuwmjl5yry75gcqqpzpmhxue69uhkztnwdaejumr0dshsz9mhwden5te0vf5hgcm0d9hx2u3wwdhkx6tpdshsz8thwden5te0vfhhxarj9e3xjarrda5kuarcda4k7tnrdakj7pm2gnh\n\nThe \"outbox model\" was not a modification of the protocol nor a new invention, nor it is a new optional NIP. nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn once said about the idea, \"this is just the Nostr model, it is how Nostr has to work if it can ever scale\" (https://t.me/gossipclient/605). Minutes after he came up with the name \"outbox model\" just so we could refer to this thing that Nostr clients should be doing but only Gossip was doing at the time.\n\nThe initial description of Nostr (nostr:naddr1qqzkummnw3eqzythwden5te0ve5kzar2v9nzucm0d5pzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqvzqqqr4gusz7vna) said: \"you write a post, sign it with your key and send it to multiple relays (servers hosted by someone else, or yourself)\" and under the \"censorship-resistance\" section it said \"there will always be some Russian server willing to take your money in exchange for serving your posts\".\n\nSince you were supposed to write \"to your own relay\" or \"to some Russian server\" shouldn't it be reasonable to assume clients would be connecting to these relays to read your posts and the entire promise of censorship-resistance of Nostr rests on that possibility?\n\nImplementation details were never specified because I think there are many ways to approach that and hoped clients would each have their own creative way of implementing it. Having the user manually specify a list of relays and then flood all relays in the list with queries for all people you're following was part of a very quick proof-of-concept I've implemented in (what was supposed to be the first version of) Branle in December 2022, but it should be obvious it's not a very user-friendly or scalable design, right?",
"sig": "0e15ff74c14a93afa818879ac30b1ebcdf22ea61f5ac65351210cdafa394485e61df7f40dac5d9188939db461761a827b54402c66ad8d5e714be310703ab8f09"
}
