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

# By arkin0x (2) and others
# Via GitHub (1) and fiatjaf_ (1)
* origin/master:
  Reword description of kind 1063
  forgot to update the initial nonce in the explanation
  example was incorrect
  reword NIP-94 to remove confusion.
  blurhash explanation

# Conflicts:
#	13.md
#	94.md
This commit is contained in:
Mariano Pérez Rodríguez 2023-04-25 16:40:29 -03:00
commit c8f3afdac6
No known key found for this signature in database
GPG Key ID: 695E1DF7F390D47A
3 changed files with 64 additions and 44 deletions

74
13.md
View File

@ -8,12 +8,14 @@ This NIP defines a way to generate and interpret Proof of Work for nostr notes.
`difficulty` is defined to be the number of leading zero bits in the `NIP-01` id. For example, an id of `000000000e9d97a1ab09fc381030b346cdd7a142ad57e6df0b46dc9bef6c7e2d` has a difficulty of `36` with `36` leading 0 bits.
`002f...` is `0000 0000 0010 1111...` in binary, which has 10 leading zeroes. Do not forget to count leading zeroes for hex digits <= `7`.
## Mining
To generate PoW for a `NIP-01` note, a `nonce` tag is used:
```json
{"content": "It's just me mining my own business", "tags": [["nonce", "1", "20"]]}
{"content": "It's just me mining my own business", "tags": [["nonce", "1", "21"]]}
```
When mining, the second entry to the nonce tag is updated, and then the id is recalculated (see [NIP-01](./01.md)). If the id has the desired number of leading zero bits, the note has been mined. It is recommended to update the `created_at` as well during this process.
@ -32,7 +34,7 @@ The third entry to the nonce tag `SHOULD` contain the target difficulty. This al
[
"nonce",
"776797",
"20"
"21"
]
],
"content": "It's just me mining my own business",
@ -42,33 +44,61 @@ The third entry to the nonce tag `SHOULD` contain the target difficulty. This al
## Validating
Here is some reference C code for calculating the difficulty (aka number of leading zero bits) in a nostr note id:
Here is some reference C code for calculating the difficulty (aka number of leading zero bits) in a nostr event id:
```c
int zero_bits(unsigned char b)
{
int n = 0;
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
if (b == 0)
return 8;
int countLeadingZeroes(const char *hex) {
int count = 0;
while (b >>= 1)
n++;
for (int i = 0; i < strlen(hex); i++) {
int nibble = (int)strtol((char[]){hex[i], '\0'}, NULL, 16);
if (nibble == 0) {
count += 4;
} else {
count += __builtin_clz(nibble) - 28;
break;
}
}
return 7-n;
return count;
}
/* find the number of leading zero bits in a hash */
int count_leading_zero_bits(unsigned char *hash)
{
int bits, total, i;
for (i = 0, total = 0; i < 32; i++) {
bits = zero_bits(hash[i]);
total += bits;
if (bits != 8)
break;
}
return total;
int main(int argc, char *argv[]) {
if (argc != 2) {
fprintf(stderr, "Usage: %s <hex_string>\n", argv[0]);
return 1;
}
const char *hex_string = argv[1];
int result = countLeadingZeroes(hex_string);
printf("Leading zeroes in hex string %s: %d\n", hex_string, result);
return 0;
}
```
Here is some JavaScript code for doing the same thing:
```javascript
// hex should be a hexadecimal string (with no 0x prefix)
function countLeadingZeroes(hex) {
let count = 0;
for (let i = 0; i < hex.length; i++) {
const nibble = parseInt(hex[i], 16);
if (nibble === 0) {
count += 4;
} else {
count += Math.clz32(nibble) - 28;
break;
}
}
return count;
}
```

30
94.md
View File

@ -1,11 +1,12 @@
# NIP-94 - File Header
# NIP-94
`draft` `optional` `author:frbitten`
## File Metadata
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.
`draft` `optional` `author:frbitten` `author:kieran` `author:lovvtide` `author:fiatjaf`
## Nostr event
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. With that, multiple types of filesharing clients can be created. NIP-94 support is not expected to be implemented by "social" clients that deal with kind:1 notes or by longform clients that deal with kind:30023 articles.
## Event format
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:
@ -16,7 +17,7 @@ This NIP specifies the use of the `1063` event type, having in `content` a descr
* `size` (optional) size of file in bytes
* `magnet` (optional) URI to magnet file
* `i` (optional) torrent infohash
* `blurhash`(optional) for cosmetic purposes
* `blurhash`(optional) the [blurhash](https://github.com/woltapp/blurhash) to show while the file is being loaded by the client
```json
{
@ -39,19 +40,8 @@ This NIP specifies the use of the `1063` event type, having in `content` a descr
}
```
## Client Behavior
## Suggested use cases
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 relay for indexing shared files. For example, to promote torrents.
* A pinterest-like client 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.

View File

@ -59,7 +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)
- [NIP-94: File Metadata](94.md)
## Event Kinds
@ -79,7 +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) |
| `1063` | File Metadata | [94](94.md) |
| `1984` | Reporting | [56](56.md) |
| `9734` | Zap Request | [57](57.md) |
| `9735` | Zap | [57](57.md) |