nips/100.md

NIP-100
======

Kanban Boards
------------

`draft` `optional`

This NIP defines a protocol for creating and managing Kanban boards on Nostr.

## Abstract

This NIP introduces event kinds and conventions for implementing Kanban boards, allowing users to create boards with multiple columns and cards that can be organized and tracked in a visual workflow.

## Motivation

Kanban boards are a popular project management tool that enables visual organization of tasks and workflows. Adding native Kanban support to Nostr allows for decentralized project management while maintaining the platform's permissionless and censorship-resistant nature.

## Specification

### Board Event 

```javascript
{
    "created_at": 34324234234, //<Unix timestamp in seconds>
    "kind": 30301,
    "tags": [
        ["d", "<board-d-identifier>"],
        ["title", "Board Name"],
        ["description","Board Description"], //can contain markdown too
        ["alt","A board to track my work"], //Human-readable plaintext summary to be shown in non-supporting clients - as per NIP-31

        // List of all columns in the board below in format ["col","col-id","name","order",<<csv of card statuses that need to be displayed in the column>>]
        // If the last element in the 'col' tag is not defined, it is assumed that column will display those cards (see event below) whose 's' tags EXACTLY the column name
        ["col", "col1-id", "To Do", "0"],
        ["col", "col2-id", "In Progress", "1"], 
        ["col", "col3-id", "Done", "2","Done, Completed, Finished"],

        // designate a 'maintainers' list who can add/edit cards in this board
        // add maintainers using 'zap' tag so that the zaps go to them using zap-splits as per NIP-57, if 'zap' tags are absent, then only the owner can add/edit cards in the board
        [ "zap", "82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2" ],  
        [ "zap", "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52" ],  
        [ "zap", "460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c" ],   
    // other fields...
    ]
}
```

In case there are no `zap` tags to designate maintainers, the owner of the board is the only person who can publish cards on the boards.

Editing of the board event is possible only by the creator of the board. 

### Card Event

```javascript
{
    "created_at": 34324234234, //<Unix timestamp in seconds>
    "kind": 30302,
    "tags": [
        ["d", "<card-d-identifier>"],
        ["title", "Card Title"],
        ["description","Card Description"], //can contain markdown too
        ["alt","A card representing a task"], //Human-readable plaintext summary to be shown in non-supporting clients - as per NIP-31
        ["s", "To do"], //status of the card
        ["rank","10"], // order of the card in the column - cards may be displayed in the ascending order of rank by default

        // card url attachments with 'u' tags similar to NIP-98
        ["u","https://attachment1"],
        ["u","https://attachment2"],

        // add assignees using 'zap' tag so that the zaps go to them using zap-splits as per NIP-57
        [ "zap", "82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2"],
        [ "zap", "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52"],  
        [ "zap", "460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c"], 

        // The list of boards this card will be a part of. 
        // However, the card will be displayed in a board only when this event's pubkey matches an entry in the board's maintainers list
        ["a", "30301:<board-1-creator-pubkey>:<board-1-d-identifier>", "<optional-relay-url>"],  
        ["a", "30301:<board-2-creator-pubkey>:<board-2-d-identifier>", "<optional-relay-url>"],  
    ],
    // other fields...
}
```

When editing a card, the maintainers can copy the card event with the `d` tag intact and publish a new event. 

When a client gets multiple card events with the same `d` tag, it takes the latest one by any maintainer or the creator of the board event as the source of truth.

### Tracker Card Event

In case one wants to just track another nostr event (like a tracker card, without modifying the original event), one can designate a tracker card using a `k` tag to denote kind and `e` tag to denote the nostr event to be tracked.  

```javascript
{
    "created_at": 34324234234, //<Unix timestamp in seconds>
    "kind": 30302,
    "tags": [
        ["d", "<card-d-identifier>"],
        ["k", "1"], //this one tracks a text note
        ["e", "<event-id>", "<relay-url>"] // as per NIP-10
    ],
    // other fields as per card event above...
}
```

The clients MAY display this tracker card like they display the tracked event, or using the 'alt' tag of the original event if not supported.

Any `30302` event with a `k` tag will be treated as a tracker card.

#### Automatic movement of tracker cards

In case of tracked card, its status is deemed to be the `s` tag value of the event it tracks. 

This allows automatic movement of a card (like a Git issue) across different columns as the card's status changes in the source system, without any manual updates in the board.  

If the tracked event does not have an `s` tag, then tracker card event's `s` tag is the status of the card.

### Event Kinds

- 30301: Kanban Board Definition
- 30302: Kanban Card

### Required Tags

#### Board Events (kind: 30301)
- `d`: Unique identifier for the board
- `title`: Board name

#### Card Events (kind: 30302)
- `d`: Unique identifier for the card
- `title`: Card title
- `a`: At least one. This points to the board that this card belongs to

### Access Control

1. Only the board creator can:
   - Modify board

2. Only the board maintainers can:
   - Add a card to the board
   - Publish edits to the existing cards (including the status)

2. Any user can:
   - View the board and cards
   - React, comment, zap on board and cards

### Client Behavior

Clients MAY:
- Display boards in a visual column layout
- Allow drag-and-drop card movement for authorized users
- Implement proper authorization checks before allowing modifications
- Implement additional features like card labels, due dates, or assignments
- Support board templates
- Provide filtering and search capabilities
- Prioritize to show the maintainer comments on cards

## Security Considerations

1. Clients MUST verify event signatures and delegation tokens before allowing modifications
2. Relays MAY implement additional spam prevention measures
3. Relays MAY choose to retain only a few recent versions of board and card events.

## Implementation Notes

To maintain a consistent board state:

1. Clients should handle concurrent updates by:
   - Using the event timestamp to resolve conflicts
   - Maintaining card order within columns

2. For performance, clients can:
   - Cache board and card data locally
   - Use efficient subscription filters when requesting updates

## Client-Relay Communication Example

```javascript
// Subscribe to the cards of a board
{
"kinds": [30302],
"#a": ["30301:<board-creator-pubkey>:<board-d-identifier>",...]
}
```