nostr-protocol · frbitten · Mar 10, 2023 · Mar 10, 2023 · Mar 10, 2023 · Mar 17, 2023
diff --git a/95.md b/95.md
@@ -0,0 +1,88 @@
+NIP-95 - Storage and Shared File
+======
+`draft` `optional` `author:frbitten` 
+
+This NIP allows users to send binary data to be stored in the relay. This data can be small pieces of information or even large files.
+
+The intention is to combine the ease of NOSTR, with many clients being developed and a common communication protocol between all. To enable decentralized file sharing. NOSTR communication must work together with other protocols to get the best out of each technology. For lay users to be able to publish their photo, file, audio on several servers in a simple and easy way.
+
+Nostr event
+------------------
+This NIP specifies the use of the `1064` event type, having in `content` the binary data that you want to be stored in Base64 format.
+* `type` a string indicating the data type of the file. The MIME types format must be used (https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types)
+* `decrypt` (optional) If the file is encrypted, you must indicate in the first value the algorithm used to encrypt the file and in the second value the parameters that allow the decryption of the file
+
+This event must not be returned in generic searches. It should only be returned if specifically requested by your ID. This avoids bandwidth consumption and unnecessary overload on the relay and client.
+
+```json
+{
+  "id": <32-bytes lowercase hex-encoded sha256 of the the serialized event data>,
+  "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
+  "created_at": <unix timestamp in seconds>,
+  "kind": 1064,
+  "tags": [
+    ["decrypt",<algorithm>,<Decryption Params>],
+    ["p", <32-bytes hex of a pubkey>, <recommended relay URL>],
+  ],
+  "content": <string with base64 data>,
+  "sig": <64-bytes hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
+}
+```
+
+Another defined event is the `1065` which is used as a header for the data contained in an event 1064. This way the data can be disclosed without overloading the communications when sending a large amount of data.
+
+```json
+{
+  "id": <32-bytes lowercase hex-encoded sha256 of the the serialized event data>,
+  "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
+  "created_at": <unix timestamp in seconds>,
+  "kind": 1065,
+  "tags": [
+    ["e",<event id 1064 you want to disclose>],
+    ["m", <MIME type>],
+    ["x",<Hash SHA-256>],
+    ["size", <size of data in bytes>],
+    ["dim", <size of data in pixels>],
+    ["thumb", <event id that contains the data for thumb>],
+    ["summary", <excerpt>],
+    ["alt", <description>]
+  ],
+  "content": <description>,
+  "sig": <64-bytes hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
+}
+````
+* `e` event id 1064 you want to disclose
+* `m` a string indicating the data type of the file. The [MIME types](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types) format must be used, and they should be lowercase.
+* `x` containing the SHA-256 hexencoded string of data.
+* `size` (optional) size of data in bytes
+* `dim` (optional) size of data in pixels in the form `<width>x<height>`
+* `thumb` (optional) event id that contains the data for thumb, which can be an event 1063 or 1064
+* `summary` (optional) text excerpt
+* `alt` (optional) description for accessibility
+
+Relay Behavior
+---------------
+Relays that use a relational database may have more difficulty implementing this NIP, but a possible solution is for this NIP not to be recorded in the database, but on disk, the file name being the event id. So it can be easily found and searched. And because it is not in the database, it does not interfere with the indexing of common events.
+
+Another solution is for Relays that want to implement this functionality and use a No-SQL database with mongodb that already supports large documents without harming performance.
+
+Client Behavior
+---------------
+The client can use this event for any type of storage it wants. The functionality of uploading an image directly through the client's interface and including it in the note that is being created is a very useful facility for the end user. In this case, 3 events would be created. Kind 1064 with the file converted to base64, Kind 1065 which is the header of this file for dissemination and Kind 1 with the post and the image.
+
+Also, it allows the app to create image galleries (memes, animations) that can be reused countless times in different notes. As it exists in whatsapp, tegegran, etc.
+
+Example: <https://ibb.co/Fnj5TMg>. 
+
+To do this, just select the image from the gallery (events NIP-94) and include the URL of the selected image
+
+Suggested Use Cases
+-------------------
+* Provide file storage service that is quickly integrable with nostr clients.
+* Create an application similar to pinterest without the need for other protocols.
+
+References
+---------------
+* https://www.mongodb.com/developer/products/mongodb/storing-large-objects-and-files/
+* https://www.mongodb.com/docs/manual/core/gridfs/
+* https://www.linkedin.com/pulse/do-store-files-your-database-mongodbs-gridfs-thinks-otherwise-gordon/