> We are providing the majority of hosting for nostr
There's your problem. Are you building a web hosting company, or a solution to censorship-resistant content hosting? It seems more like the former, based on your focus on platform-specific features like content moderation and image search.
Don't get me wrong, nostr.build is a great service to nostr in these early days, but what if a state actor comes to you and asks you to take something down? You'll do it, as would I. Making nostr.build's source code FOSS doesn't really solve that problem on its own.
NIP 96 is a great start to creating an open solution, but much of the spec is concerned with accommodating the needs of image hosts wrt image optimization and transformation. Also, in practice, files are usually referred to by url, not hash. People are excited about blossom because it forces users to refer to files by hash, and doesn't include server-side transforms. It's just a more purist architecture, that makes the benefits of content-addressability clear. NIP 96 isn't necessarily broken, but conventions around its use need to change. Also, serving a transformed file in response to an `ox` prevents users from verifying that the file is authentic, which breaks the guarantees content-addressing gets you.
Pushing content replication based on hash does of course conflict with content moderation for CSAM, which is a great service, and important to the health of nostr for users, operators, and nostr's public image. But it's inherently centralizing. I don't know what the solution to that problem is.
Here's what I would personally like to see from someone focused on image hosting:
- More robust content-addressing, including a referentially transparent mapping between hash and returned file, and better conventions for using these hashes in nostr notes.
- A story for replication of content between servers, including self-hosted ones. Also better discovery of where a particular file is hosted. Blossom has this, in theory if not in practice.
- Decentralized/redundant CSAM scanning, and propagation of reports across servers (without making the reports public, somehow? I know it's extremely hard to manage hash tables in a way that doesn't allow attackers to circumvent them, see https://securitycryptographywhatever.com/2021/08/27/apple-s-csam-detection-with-matthew-green/)
Just my own personal 2 sats.
hodlbod /
npub1jlr…ynqn
2024-06-25 20:11:45
in reply to nevent1q…eef4
Author Public Key
npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqnPublished at
2024-06-25 20:11:45Event JSON
{
"id": "f3cd0eb4aa6a2b790cf8b16c175146db993ca52068fb9c13bfbe5a53d907716c",
"pubkey": "97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322",
"created_at": 1719339105,
"kind": 1,
"tags": [
[
"p",
"8fb140b4e8ddef97ce4b821d247278a1a4353362623f64021484b372f948000c",
"wss://relay.momostr.pink/",
"fishcake"
],
[
"p",
"9989500413fb756d8437912cc32be0730dbe1bfc6b5d2eef759e1456c239f905",
"wss://nos.lol/",
"nostr.build"
],
[
"p",
"df173277182f3155d37b330211ba1de4a81500c02d195e964f91be774ec96708",
"wss://nos.lol/",
"Mutiny Wallet"
],
[
"p",
"460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c",
"wss://vitor.nostr1.com/",
"Vitor Pamplona"
],
[
"p",
"958b754a1d3de5b5eca0fe31d2d555f451325f8498a83da1997b7fcd5c39e88c",
"wss://relay.stoner.com/",
"𝓢𝓮𝓻 𝓢𝓵𝓮𝓮𝓹𝔂"
],
[
"p",
"726a1e261cc6474674e8285e3951b3bb139be9a773d1acf49dc868db861a1c11",
"wss://relay.damus.io/",
"franzap"
],
[
"p",
"a96a35a224402b8075c4da20f0477896afcc3395b6fad63e30a648a8222a6a69",
"wss://theforest.nostr1.com/",
"Low Information Voter"
],
[
"e",
"b70adc2767a68ce47016d3053a4469223fc4eaaaec5ce767a31256058ca20535",
"wss://nos.lol/",
"root"
],
[
"e",
"bf1784a790c07ec2b341f515c277857813d242a567a7c162d57b822b72e7df85",
"",
"mention"
],
[
"e",
"05a89feac13a7884ac6ea30a1d150164d4dc2de864ff91661d650f2ee4078f6d",
"wss://nos.lol/",
"reply",
"9989500413fb756d8437912cc32be0730dbe1bfc6b5d2eef759e1456c239f905"
],
[
"client",
"Coracle",
"31990:97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322:1685968093690"
]
],
"content": "\u003e We are providing the majority of hosting for nostr\n\nThere's your problem. Are you building a web hosting company, or a solution to censorship-resistant content hosting? It seems more like the former, based on your focus on platform-specific features like content moderation and image search.\n\nDon't get me wrong, nostr.build is a great service to nostr in these early days, but what if a state actor comes to you and asks you to take something down? You'll do it, as would I. Making nostr.build's source code FOSS doesn't really solve that problem on its own.\n\nNIP 96 is a great start to creating an open solution, but much of the spec is concerned with accommodating the needs of image hosts wrt image optimization and transformation. Also, in practice, files are usually referred to by url, not hash. People are excited about blossom because it forces users to refer to files by hash, and doesn't include server-side transforms. It's just a more purist architecture, that makes the benefits of content-addressability clear. NIP 96 isn't necessarily broken, but conventions around its use need to change. Also, serving a transformed file in response to an `ox` prevents users from verifying that the file is authentic, which breaks the guarantees content-addressing gets you.\n\nPushing content replication based on hash does of course conflict with content moderation for CSAM, which is a great service, and important to the health of nostr for users, operators, and nostr's public image. But it's inherently centralizing. I don't know what the solution to that problem is.\n\nHere's what I would personally like to see from someone focused on image hosting:\n\n- More robust content-addressing, including a referentially transparent mapping between hash and returned file, and better conventions for using these hashes in nostr notes.\n- A story for replication of content between servers, including self-hosted ones. Also better discovery of where a particular file is hosted. Blossom has this, in theory if not in practice.\n- Decentralized/redundant CSAM scanning, and propagation of reports across servers (without making the reports public, somehow? I know it's extremely hard to manage hash tables in a way that doesn't allow attackers to circumvent them, see https://securitycryptographywhatever.com/2021/08/27/apple-s-csam-detection-with-matthew-green/)\n\nJust my own personal 2 sats.",
"sig": "adcf592c5bd437993abead9f85f211ad23900c02e4eb505d6281a23551a78020edfa11c237c4b3b3e7279df0a38bc395cece1f34ccc88b4fe657e59278b96c21"
}