nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-09-19 22:35:50 -04:00
Code Issues Actions Packages Projects Releases Wiki Activity

Create 68.md

Browse Source
This commit is contained in:
kinakuta-co 2023-02-13 21:06:54 +00:00 committed by GitHub
parent c80cb09e80
commit d6ac56e307
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 28 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
68.md Normal file
View File

@ -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