From d6ac56e307157b3820ab2d54a1395bef7d0f2c97 Mon Sep 17 00:00:00 2001
From: kinakuta-co <125303710+kinakuta-co@users.noreply.github.com>
Date: Mon, 13 Feb 2023 21:06:54 +0000
Subject: [PATCH] Create 68.md

---
 68.md | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)
 create mode 100644 68.md

diff --git a/68.md b/68.md
new file mode 100644
index 0000000..7d558f3
--- /dev/null
+++ b/68.md
@@ -0,0 +1,28 @@
+# NIP-068 Blinded Nostr Assets
+
+Centralized file storage (e.g. Amazon) is great for availability and speed but susceptible to censorship.
+
+Decentralized file hosting (for images, etc.) is a difficult problem to solve.
+
+Nostr thrives on simplicity, so I'd like to suggest a way of utilizing centralized file storage defensively so that hosts are less likely to censor or deplatform content.
+
+An image (or any file) can be encrypted with a password (maybe AES-256-CBC), given a random filename, and uploaded as a BLOB to a centralized host. The note that references the image URI will also contain the information necessary to decrypt the image. When a client loads a note referencing an encrypted image, it will fetch the BLOB and decrypt it locally to display it.
+
+Although this increases client load, it prevents the host from assessing the stored content without having knowledge of the particular note that holds the decryption information.
+
+This NIP is for defining how a file is encrypted and stored and how it is referenced, retrieved and decrypted in the client so that all clients can consistently recognize and handle blinded assets.
+
+The ubiquitous availability of cheap programmatic cloud hosting can be seen as a kind of decentralized mesh we can use to our advantage as long as the content hosted is uncensorable. If the host can't see the content they won't have a reason to censor it. Unless hosts begin to ban encrypted content, this seems fairly robust.
+
+If this made Amazon upset and they began to siphon notes from relays to index their blinded assets, we have another tool we can use: zaps https://github.com/nostr-protocol/nips/pull/224
+
+Consequently, if a lightning paywall is put up to prevent an angry host from indexing encrypted content, this also serves as a great generalized way for users to monetize their content.
+
+Simply: if enabled, you must zap a note to receive the decryption information to decrypt the media.
+
+There are many ways this paywall could be implemented. I'm looking to the nostr community for ideas.
+
+AES-256-CBC encryption references
+
+- https://stackoverflow.com/a/39412887
+- https://www.npmjs.com/package/aes-js