From b0ee094870a4728aa1bd7a89b5687a3f98dd92d3 Mon Sep 17 00:00:00 2001 From: frbittencourt Date: Fri, 10 Mar 2023 11:08:16 +0000 Subject: [PATCH 1/8] created a specific branch for the NIP-95 --- 95.md | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 56 insertions(+) create mode 100644 95.md diff --git a/95.md b/95.md new file mode 100644 index 00000000..00132df1 --- /dev/null +++ b/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": , + "kind": 30064, + "tags": [ + ["d", ], + ["decrypt",,], + ["p", <32-bytes hex of a pubkey>, ], + ["hash",< SHA256 hexencoded string of the raw data>] + ], + "content": , + "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: . + +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. From 08cc3c6f7d47ed04536db129a5da6c9dfb91a97b Mon Sep 17 00:00:00 2001 From: frbittencourt Date: Fri, 10 Mar 2023 11:19:26 +0000 Subject: [PATCH 2/8] improved nip description --- 95.md | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/95.md b/95.md index 00132df1..988f9735 100644 --- a/95.md +++ b/95.md @@ -1,15 +1,18 @@ -NIP-95 Base64 File +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 `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 +* `format` ("Base64" or "BSON") Defines how the data is stored in the content. Having the option of being in base64 format or in BSON format. 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. @@ -25,7 +28,8 @@ The `NIP-94` can be used to broadcast the ID of that event, with the ` and ` tag ["d", ], ["decrypt",,], ["p", <32-bytes hex of a pubkey>, ], - ["hash",< SHA256 hexencoded string of the raw data>] + ["hash",< SHA256 hexencoded string of the raw data>], + ["format",<"Base64" or "BSON">] ], "content": , "sig": <64-bytes hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field> @@ -54,3 +58,9 @@ 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/ \ No newline at end of file From 8cfc828bea18e4c43ecf020decacc226fcae2767 Mon Sep 17 00:00:00 2001 From: frbittencourt Date: Fri, 10 Mar 2023 14:00:03 +0000 Subject: [PATCH 3/8] remove bson reference --- 95.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/95.md b/95.md index 988f9735..8ff6fb74 100644 --- a/95.md +++ b/95.md @@ -12,7 +12,6 @@ This NIP specifies the use of the `30064` event type (parameterized replaceable * `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 -* `format` ("Base64" or "BSON") Defines how the data is stored in the content. Having the option of being in base64 format or in BSON format. 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. @@ -29,7 +28,6 @@ The `NIP-94` can be used to broadcast the ID of that event, with the ` and ` tag ["decrypt",,], ["p", <32-bytes hex of a pubkey>, ], ["hash",< SHA256 hexencoded string of the raw data>], - ["format",<"Base64" or "BSON">] ], "content": , "sig": <64-bytes hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field> From 988e0b1c5d7ad145adf458b1f0f1b1778b42c209 Mon Sep 17 00:00:00 2001 From: frbittencourt Date: Fri, 17 Mar 2023 13:58:40 +0000 Subject: [PATCH 4/8] remove tag hash and change to regular event --- 95.md | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/95.md b/95.md index 8ff6fb74..6b240591 100644 --- a/95.md +++ b/95.md @@ -8,8 +8,7 @@ The intention is to combine the ease of NOSTR, with many clients being developed 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. +This NIP specifies the use of the `1064` event type (parameterized replaceable event), 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 @@ -22,12 +21,10 @@ The `NIP-94` can be used to broadcast the ID of that event, with the ` and ` tag "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": , - "kind": 30064, + "kind": 1064, "tags": [ - ["d", ], ["decrypt",,], ["p", <32-bytes hex of a pubkey>, ], - ["hash",< SHA256 hexencoded string of the raw data>], ], "content": , "sig": <64-bytes hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field> From 75e23c7874c0e4eecb3b41d0c093face71f36c72 Mon Sep 17 00:00:00 2001 From: frbittencourt Date: Tue, 4 Apr 2023 17:42:04 +0100 Subject: [PATCH 5/8] add new evento to use header --- 95.md | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/95.md b/95.md index 6b240591..0b54043b 100644 --- a/95.md +++ b/95.md @@ -14,8 +14,6 @@ This NIP specifies the use of the `1064` event type (parameterized replaceable e 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>, @@ -31,6 +29,22 @@ The `NIP-94` can be used to broadcast the ID of that event, with the ` and ` tag } ``` +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": , + "kind": 1065, + "tags": [ + ["e",], + ], + "content": , + "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. From 7062bbc4ef71f66329fe026fd0f1c11372c540d0 Mon Sep 17 00:00:00 2001 From: Fernando Bittencourt Date: Thu, 28 Mar 2024 13:46:44 +0000 Subject: [PATCH 6/8] Update 95.md fixed descriptions --- 95.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/95.md b/95.md index 0b54043b..bdb9615d 100644 --- a/95.md +++ b/95.md @@ -8,7 +8,7 @@ The intention is to combine the ease of NOSTR, with many clients being developed Nostr event ------------------ -This NIP specifies the use of the `1064` event type (parameterized replaceable event), having in `content` the binary data that you want to be stored in Base64 format. +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 @@ -55,7 +55,7 @@ The relay can allow access to this data via URL, having its own URL pattern for 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. +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. @@ -72,4 +72,4 @@ 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/ \ No newline at end of file +* https://www.linkedin.com/pulse/do-store-files-your-database-mongodbs-gridfs-thinks-otherwise-gordon/ From 49328e0e1e5249106dbda5709ad6103435e21b6d Mon Sep 17 00:00:00 2001 From: Fernando Bittencourt Date: Thu, 28 Mar 2024 13:51:39 +0000 Subject: [PATCH 7/8] added reference to NIP-94 --- 95.md | 16 +--------------- 1 file changed, 1 insertion(+), 15 deletions(-) diff --git a/95.md b/95.md index bdb9615d..f491c9bc 100644 --- a/95.md +++ b/95.md @@ -29,21 +29,7 @@ This event must not be returned in generic searches. It should only be returned } ``` -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": , - "kind": 1065, - "tags": [ - ["e",], - ], - "content": , - "sig": <64-bytes hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field> -} -```` +The file description is defined by [NIP-94](https://github.com/nostr-protocol/nips/blob/master/94.md) Relay Behavior --------------- From 9ce5ab56710ee1686b8c7a6c793e7d402326229a Mon Sep 17 00:00:00 2001 From: frbittencourt Date: Thu, 28 Mar 2024 16:35:51 +0000 Subject: [PATCH 8/8] removed the connections with the NIP-94, making this nip independent. --- 95.md | 37 ++++++++++++++++++++++++++++++++----- 1 file changed, 32 insertions(+), 5 deletions(-) diff --git a/95.md b/95.md index f491c9bc..d0a1274a 100644 --- a/95.md +++ b/95.md @@ -29,7 +29,36 @@ This event must not be returned in generic searches. It should only be returned } ``` -The file description is defined by [NIP-94](https://github.com/nostr-protocol/nips/blob/master/94.md) +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": , + "kind": 1065, + "tags": [ + ["e",], + ["m", ], + ["x",], + ["size", ], + ["dim", ], + ["thumb", ], + ["summary", ], + ["alt", ] + ], + "content": , + "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 `x` +* `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 --------------- @@ -37,13 +66,11 @@ Relays that use a relational database may have more difficulty implementing this 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. +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, 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. +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: .