nips/96.md

NIP-96
======

Code Collaboration over Nostr
----------------------

`draft` `optional` `author: KaffinPX and Not Thomiz`

This NIP defines a way to collaborate on coding 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 Code Collaboration 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 code collaboration 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 code collaboration 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>
}
```

### Revision Requests

A code collaboration event MAY contain a `r` tag indicating the event is specific to creating a revision request. If present, the `r` tag SHALL define the title of revision 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> ],
    [ "r", <title> ]
  ],
  "content": <unique indicator>
}
```

### Comments

A file distribution event MAY contain an `e` tag indicating the event is specific to commenting on a thread/revision 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

An event MAY contain a `s` tag indicating the event is specific to changing state of a repository and MAY contain `e` tag for managing a thread or revision 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 reason/comment as text.

```json
{
  "kind": 96,
  "tags": [
    [ "p", <repository owner> ],
    [ "b", <repository identifier> ],
    [ "e", <event id> ],
    [ "s", <state> ]
  ],
  "content": <comment>
}
```