nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-11-13 23:39:08 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

updated fostr NIP for next PR

Browse Source
This commit is contained in:
KaffinPX 2023-06-21 20:43:06 +03:00 committed by GitHub
parent 852bd7f872
commit 8da7f7e451
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 115 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

115
96.md Normal file
View File

@ -0,0 +1,115 @@
NIP-96
======
File distribution over Nostr
----------------------
`draft` `optional` `author: KaffinPX and Not Thomiz`
This NIP defines a way to distribute files over nostr by using it as transport and organizer layer. We could implement it for solutions like Git but their scheme is not compatible with async networks like nostr because of their commit chain, if one commit is missing we cant build latest state of files. This NIP will consider every commitment as revision which will include latest state of files and won't keep state on nostr but just an unique indicator(an integrity proof) for file.
## Definition of a File Distribution Event
`kind: 96` uses the `b` tag to identify the base repository, MAY contain a `t` tag to be used as title or description of revision.
By default its an event for committing a revision. The `content` of a file distribution event MUST contain an unique indicator as text for file(s) like an IPFS CID or Torrent so clients can get & verify actual files by it.
```json
{
"kind": 96,
"tags": [
[ "b", <repository identifier> ],
[ "t", <revision title>]
],
"content": <unique identicator>
}
```
### Interacting with Other Repositories
A file distribution event MUST contain a `p` tag indicating public key if it's not interacting with an owned repository.
```json
{
"kind": 96,
"tags": [
[ "p", <repository owner> ],
[ "b", <repository identifier> ]
],
...
```
### Threads(Issues)
A file distribution event MAY contain a `c` tag to indicating the event is specific to creating a thread. If present, the `c` tag SHALL define title of the thread.
The `content` of it MUST contain a comment as text.
```json
{
"kind": 96,
"tags": [
[ "p", <repository owner> ],
[ "b", <repository identifier> ],
[ "c", <title> ]
],
"content": <comment>
}
```
### Merge Requests
A file distribution event MAY contain a `m` tag indicating the event is specific to creating a merge request. If present, the `m` tag SHALL define the title of pull request.
The `content` of it MUST contain an unique indicator as text for file(s) to be merged.
```json
{
"kind": 96,
"tags": [
[ "p", <repository owner> ],
[ "b", <repository identifier> ],
[ "m", <title> ]
],
"content": <unique indicator>
}
```
### Comments
A file distribution event MAY contain an `e` tag indicating the event is specific to commenting on a thread/merge request. If present, the `e` tag MUST define an event id of thread.
The `content` of it MUST contain a comment as text.
```json
{
"kind": 96,
"tags": [
[ "p", <repository owner> ],
[ "b", <repository identifier> ],
[ "e", <event id> ]
],
"content": <comment>
}
```
### Management
A comment event may contain a `s` tag indicating the event is specific to changing state of a thread or merge request. If present, the `s` tag MUST be `OPEN` or `CLOSE`.
Only considered valid if used by thread or merge request owner or by the repository owner.
The `content` of it MUST contain a comment as text.
```json
{
"kind": 96,
"tags": [
[ "p", <repository owner> ],
[ "b", <repository identifier> ],
[ "e", <event id> ],
[ "s", <state> ]
],
"content": <comment>
}
```