sultan on Nostr: Instead of trying to solve the difficult problem of decentralized file storage for ...
Instead of trying to solve the difficult problem of decentralized file storage for nostr images and assets, I propose a way of making cheap, plentiful centralized cloud storage more censorship resistant.
Introducing NIP-68: Nostr Blinded Assets - https://github.com/nostr-protocol/nips/pull/250
Concept:
A "filedump" is a simple cloud server that accepts anonymous file uploads on the condition that the file is an encrypted BLOB.
When a filedump is created, a kind 1000 event should be published with a content containing the filedump address. When a client sees this note, it will automatically add the filedump to its internal list of filedumps.
When the user uploads a file in their client, here is what happens:
- the client will choose a filedump at random
- the client will encrypt the file with AES-CBC
- the client will change the filename to any valid non-UUID name with at least 128 bits of entropy
- the client will POST (upload) the file to the filedump
- the client will put the decryption key and iv directly into the note in the following form:
file<initialization vector>ivk<key>https://<filedump>/<filename>;
When a client encounters a note referencing a file in this form:
- GET the file
- decrypt it
- display the file with the note as normal
Key features:
- Very little impact on UX. The average nostr user will not know the difference between a normal linked photo and a blinded asset except that blinded assets may take a few extra milliseconds to decrypt and display.
- The file is encrypted on the server but can be seen (decrypted) by anyone who sees the note because the decryption info is stored publicly in the note's content.
- The cloud provider will be unable to know what the file contains unless they have knowledge of the note that references it and bothers to decrypt it.
- Users will have no relationship to a single filedump. They use a random filedump for every file they upload. This makes it very hard to deplatform a specific user's files.
- The owner of the filedump has deniability for the content they are storing.
- All nostr users will be able to spin up a filedump with no technical knowledge thanks to one-click deployment recipes supported by most major cloud service providers. Ideally there will be tens of thousands of filedumps to choose from but even several dozen would work well.
- The more filedumps there are to choose from, the less content each will store and serve. This reduces the average operation costs for all filedump owners.
Click-to-deploy resources for different platforms:
- https://docs.aws.amazon.com/amplify/latest/userguide/one-click.html
- https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-resource-manager/templates/deploy-to-azure-button.md
- https://cloud.google.com/blog/products/serverless/introducing-cloud-run-button-click-to-deploy-your-git-repos-to-google-cloud
- https://devcenter.heroku.com/articles/heroku-button
Ideas to explore:
File durability and repair. NIP-68 could define a method of referencing multiple copies of a blinded asset across multiple filedumps such that the file can still be accessed even if the primary filedump is taken down by the host. Additional copies could be added to repair the asset's redundancy. Filedump announcements could contain the cloud provider (Microsoft, Google, Amazon, etc.) and clients could upload a single file to at least 3 different providers, making it very difficult to coordinate censorship.
Filedump protection. Anonymous uploads could be abused for non-nostr purposes. Require a pubkey, signature, POW, or zap to upload? If there are enough filedumps, each one could limit each user to only 1 lifetime upload and any given user would still likely never have trouble uploading.
Let me know your thoughts on this proposal.
🌴⚔️🌴
Introducing NIP-68: Nostr Blinded Assets - https://github.com/nostr-protocol/nips/pull/250
Concept:
A "filedump" is a simple cloud server that accepts anonymous file uploads on the condition that the file is an encrypted BLOB.
When a filedump is created, a kind 1000 event should be published with a content containing the filedump address. When a client sees this note, it will automatically add the filedump to its internal list of filedumps.
When the user uploads a file in their client, here is what happens:
- the client will choose a filedump at random
- the client will encrypt the file with AES-CBC
- the client will change the filename to any valid non-UUID name with at least 128 bits of entropy
- the client will POST (upload) the file to the filedump
- the client will put the decryption key and iv directly into the note in the following form:
file<initialization vector>ivk<key>https://<filedump>/<filename>;
When a client encounters a note referencing a file in this form:
- GET the file
- decrypt it
- display the file with the note as normal
Key features:
- Very little impact on UX. The average nostr user will not know the difference between a normal linked photo and a blinded asset except that blinded assets may take a few extra milliseconds to decrypt and display.
- The file is encrypted on the server but can be seen (decrypted) by anyone who sees the note because the decryption info is stored publicly in the note's content.
- The cloud provider will be unable to know what the file contains unless they have knowledge of the note that references it and bothers to decrypt it.
- Users will have no relationship to a single filedump. They use a random filedump for every file they upload. This makes it very hard to deplatform a specific user's files.
- The owner of the filedump has deniability for the content they are storing.
- All nostr users will be able to spin up a filedump with no technical knowledge thanks to one-click deployment recipes supported by most major cloud service providers. Ideally there will be tens of thousands of filedumps to choose from but even several dozen would work well.
- The more filedumps there are to choose from, the less content each will store and serve. This reduces the average operation costs for all filedump owners.
Click-to-deploy resources for different platforms:
- https://docs.aws.amazon.com/amplify/latest/userguide/one-click.html
- https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-resource-manager/templates/deploy-to-azure-button.md
- https://cloud.google.com/blog/products/serverless/introducing-cloud-run-button-click-to-deploy-your-git-repos-to-google-cloud
- https://devcenter.heroku.com/articles/heroku-button
Ideas to explore:
File durability and repair. NIP-68 could define a method of referencing multiple copies of a blinded asset across multiple filedumps such that the file can still be accessed even if the primary filedump is taken down by the host. Additional copies could be added to repair the asset's redundancy. Filedump announcements could contain the cloud provider (Microsoft, Google, Amazon, etc.) and clients could upload a single file to at least 3 different providers, making it very difficult to coordinate censorship.
Filedump protection. Anonymous uploads could be abused for non-nostr purposes. Require a pubkey, signature, POW, or zap to upload? If there are enough filedumps, each one could limit each user to only 1 lifetime upload and any given user would still likely never have trouble uploading.
Let me know your thoughts on this proposal.
🌴⚔️🌴