Merge remote-tracking branch 'origin/master' into markdownlint

# By frbittencourt (14) and others
# Via fiatjaf_
* origin/master: (23 commits)
  Update 01.md
  fix: re-add NIP-15 to the list
  Add NIP-94 and kind 1063 to README.md
  nip update to reach consensus with other nips
  fixed text description
  Apply suggestions from code review
  change to regular event
  Update 94.md
  Update 94.md
  Update 94.md
  Update 94.md
  Update 94.md
  move nip-95 to other branch
  ajusts description of decrypt tag
  ajusts  decrypt tag
  ajusts formt text
  minor fix
  fix example image
  fix format text in md
  add hash tag
  ...

# Conflicts:
#	01.md

01.md

@@ -105,5 +105,5 @@ A relay may choose to treat different message kinds differently, and it may or m
 ## Other Notes
 
 - Clients should not open more than one websocket to each relay. One channel can support an unlimited number of subscriptions, so clients should do that.
-- The `tags` array can store a tag identifier as the first element of each subarray, plus arbitrary information afterward (always as strings). This NIP defines `"p"` --- meaning "pubkey", which points to a pubkey of someone that is referred to in the event ---, and `"e"` --- meaning "event", which points to the id of an event this event is quoting, replying to or referring to somehow.
+- The `tags` array can store a tag identifier as the first element of each subarray, plus arbitrary information afterward (always as strings). This NIP defines `"p"` --- meaning "pubkey", which points to a pubkey of someone that is referred to in the event ---, and `"e"` --- meaning "event", which points to the id of an event this event is quoting, replying to or referring to somehow. See [NIP-10](https://github.com/nostr-protocol/nips/blob/127d5518bfa9a4e4e7510490c0b8d95e342dfa4b/10.md) for a detailed description of "e" and "p" tags.
 - The `<recommended relay URL>` item present on the `"e"` and `"p"` tags is an optional (could be set to `""`) URL of a relay the client could attempt to connect to fetch the tagged event or other events from a tagged profile. It MAY be ignored, but it exists to increase censorship resistance and make the spread of relay addresses more seamless across clients.

94.md

@@ -0,0 +1,57 @@
+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 `1063` event type, having in `content` a description of the file content, and a list of tags described below:
+* `url` the url to download the file
+* `m` 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)
+* `"aes-256-gcm"` (optional)  key and nonce for AES-GCM encryption with tagSize always 128bits
+* `x` containing the SHA-256 hexencoded string of the file.
+* `size` (optional) size of file in bytes
+* `magnet` (optional) URI to magnet file
+* `i` (optional) torrent infohash
+* `blurhash`(optional) for cosmetic purposes 
+
+```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": 1063,
+  "tags": [
+    ["url",<string with URI of file>],
+    ["aes-256-gcm",<key>, <iv>],
+    ["m", <MIME type>],
+    ["x",<Hash SHA-256>],
+    ["size", <size of file in bytes>],
+    ["magnet",<magnet URI> ],
+    ["i",<torrent infohash>],
+    ["blurhash", <value>]
+  ],
+  "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. 
+
+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
+-------------------
+* 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.

README.md

@@ -33,6 +33,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/fia
 - [NIP-12: Generic Tag Queries](12.md)
 - [NIP-13: Proof of Work](13.md)
 - [NIP-14: Subject tag in text events.](14.md)
+- [NIP-15: Nostr Marketplace (for resilient marketplaces)](15.md)
 - [NIP-16: Event Treatment](16.md)
 - [NIP-18: Reposts](18.md)
 - [NIP-19: bech32-encoded entities](19.md)
@@ -58,6 +59,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/fia
 - [NIP-58: Badges](58.md)
 - [NIP-65: Relay List Metadata](65.md)
 - [NIP-78: Application-specific data](78.md)
+- [NIP-94: File Header](94.md)
 
 ## Event Kinds
 
@@ -77,6 +79,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/fia
 | `42`    | Channel Message            | [28](28.md) |
 | `43`    | Channel Hide Message       | [28](28.md) |
 | `44`    | Channel Mute User          | [28](28.md) |
+| `1063`  | File Header                | [94](94.md) |
 | `1984`  | Reporting                  | [56](56.md) |
 | `9734`  | Zap Request                | [57](57.md) |
 | `9735`  | Zap                        | [57](57.md) |