4.5 KiB
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.
typea 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.
{
"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.
{
"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>],
],
"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>
}
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 1064 with the file converted to base64, Kind 1063 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.