created a specific branch for the NIP-95

95.md

@@ -0,0 +1,56 @@
+NIP-95 Base64 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.
+
+Nostr event
+------------------
+This NIP specifies the use of the `30064` event type (parameterized replaceable event), having in `content` the binary data that you want to be stored in Base64 format.
+* `d` containing the name of the shared file to allow it to be overwritten in the future.
+* `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.
+
+The `NIP-94` can be used to broadcast the ID of that event, with the ` and ` tag referencing the event id, without having to send the full event which can be a lot 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": 30064,
+  "tags": [
+    ["d", <string with name of file>],
+    ["decrypt",<algorithm>,<Decryption Params>],
+    ["p", <32-bytes hex of a pubkey>, <recommended relay URL>],
+    ["hash",< SHA256 hexencoded string of the raw data>]
+  ],
+  "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>
+}
+```
+
+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.
+
+The relay can allow access to this data via URL, having its own URL pattern for these cases. And if you receive a `NIP-94` referring to a `NIP-95` you can include the URL in the proper `NIP-94` tag
+
+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 30064 with the file converted to base64, Kind 30063 which is the header of this file for dissemination and Kind 1 with the post and the image.
+
+Also, when used in conjunction with `NIP-94`, 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.