Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nip 94 - File Header #337

Merged
merged 20 commits into from
Apr 20, 2023
44 changes: 44 additions & 0 deletions 94.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
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.
frbitten marked this conversation as resolved.
Show resolved Hide resolved
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.
frbitten marked this conversation as resolved.
Show resolved Hide resolved
* `url` the url to download the file
frbitten marked this conversation as resolved.
Show resolved Hide resolved
* `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)
staab marked this conversation as resolved.
Show resolved Hide resolved
* `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
frbitten marked this conversation as resolved.
Show resolved Hide resolved

frbitten marked this conversation as resolved.
Show resolved Hide resolved
```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>],
frbitten marked this conversation as resolved.
Show resolved Hide resolved
["url",<string with URL of file>],
frbitten marked this conversation as resolved.
Show resolved Hide resolved
["decrypt",<algorithm>,<key>],
["p", <32-bytes hex of a pubkey>, <recommended relay URL>],
frbitten marked this conversation as resolved.
Show resolved Hide resolved
["hash",< SHA256 hexencoded string of the file>
frbitten marked this conversation as resolved.
Show resolved Hide resolved
],
"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>
}

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.
51 changes: 51 additions & 0 deletions 95.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,51 @@
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.

```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>,<key>],
["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.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.