create draft NIP 94 and 95

2 files changed, 78 insertions, 0 deletions

diff --git a/94.md b/94.md
new file mode 100644
index 0000000..06b03c8
--- /dev/null
+++ b/94.md
@@ -0,0 +1,43 @@
+NIP-94 - File Header
+======
+`draft` `optional` `author:frbitten` 
+
+The purpose of this NIP is to allow an organization and classification of shared files. So that relays can filter and organize in any way that is of interest.
+Also the goal is to create a base on the protocol for this bountsr "Filesharing App" (https://bountsr.org/p2p-filesharing/) to be implemented.
+
+Nostr event
+------------------
+This NIP specifies the use of the `30063` event type (parameterized replaceable event), having in `content` a description of the file content, and a list of tags described below:
+* `d` containing the name of the shared file to allow it to be overwritten in the future.
+* `url` the url to download the file
+* `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 information (the key) that allow the decryption of the file
+
+```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": 30063,
+  "tags": [
+    ["d", <string with name of file>],
+    ["url",<string with URL of file>],
+    ["decrypt",<algorithm>,<key>],
+    ["p", <32-bytes hex of a pubkey>, <recommended relay URL>],
+  ],
+  "content": "A beautiful picture of a wild toucan",
+  "sig": <64-bytes hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
+}
+
+Client Behavior
+---------------
+The client can use this event as they see fit. Either showing events in the same feed as kind 1 events or creating a specific feed for file listings
+It allows the app to create image galleries (memes, animations) that can be reused countless times in different notes. As it exists in whatsapp, telegram, etc. Exemple: <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
+-------------------
+* A relay for indexing shared files. For example to promote torrents
+* A Pinterest-like relay and app where people can share their portfolio and inspire others.
+* A simple way to distribute configurations and software updates.
+* Specialized relays can provide collections of emojis, memes and animated gifs to be used in notes.
diff --git a/95.md b/95.md
new file mode 100644
index 0000000..680496c
--- /dev/null
+++ b/95.md
@@ -0,0 +1,35 @@
+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 information (the key) 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.
+
+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.Exemple: <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.