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

{
    "created_at": 34324234234, //<Unix timestamp in seconds>
    "kind": 30301,
    "content": {
        "description" : "Board Description", // can contain markdown too
        "columnMapping": 'EXACT' //map the card's status exactly with column name - Extensible to different logics in future
        "columns": [
            {
                "id": "col1",
                "name": "To Do",
                "order": 0
            },
            {
                "id": "col2",
                "name": "In Progress",
                "order": 1
            },
            {
                "id": "col3",
                "name": "Done",
                "order": 2
            }
        ]
    },
    "tags": [
        ["d", "<board-d-identifier>"],
        ["title", "Board Name"],
        // List of all cards in the board below
        ["a", "30302:<card-1-event-author-pubkey>:<card-1-d-identifier>", "<optional-relay-url>"],
        ["a", "30302:<card-2-event-author-pubkey>:<card-2-d-identifier>", "<optional-relay-url>"],
        ["a", "30302:<card-3-event-author-pubkey>:<card-3-d-identifier>", "<optional-relay-url>"],
    ],
    // other fields...
}

Card Event

{
    "created_at": 34324234234, //<Unix timestamp in seconds>
    "kind": 30302,
    "content": {
        "status": "To do", // Match exactly with column name
        "description": "Card description", //can contain markdown too
        "order": 0, // auto-increment new card order in increments of 10 to provide space for rearranging to an extent
        "attachments": [
            "https://example.com/file1.png",
            "https://example.com/file2.pdf"
        ]
    },
    "tags": [
        ["d", "<card-d-identifier>"],
        ["title", "Card Title"],
        // add assignees using 'zap' tag so that the zaps go to them using zap-splits as per NIP-57
        [ "zap", "82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2", "wss://nostr.oxtr.dev", "1" ],  // 25%
        [ "zap", "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52", "wss://nostr.wine/",    "1" ],  // 25%
        [ "zap", "460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c", "wss://nos.lol/",       "2" ]   // 50%
    ],
    // other fields...
}

Event Kinds

• 30301: Kanban Board Definition
• 30302: Kanban Card

Required Tags

Board Events (kind: 30301)

• d: Unique identifier for the board
• title: Board name
• a: One for each card in the board

Card Events (kind: 30302)

• d: Unique identifier for the card
• title: Card title

Access Control

1. Only the board creator can:

   • Modify board
   • Add a card to the board

2. Only the card creator can:

   • Modify cards (including the status)

3. Any user can:

   • View the board and cards
   • React, comment, zap on board and cards

Client Behavior

Clients SHOULD:

• Display boards in a visual column layout
• Allow drag-and-drop card movement for authorized users
• Support board sharing via nostr: URI scheme
• Implement proper authorization checks before allowing modifications

Clients MAY:

• Implement additional features like card labels, due dates, or assignments
• Support board templates
• Provide filtering and search capabilities

Security Considerations

1. Clients MUST verify event signatures and delegation tokens before allowing modifications
2. Relays MAY implement additional spam prevention measures

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 should:

   • Cache board and card data locally
   • Use efficient subscription filters when requesting updates

Client-Relay Communication Example

// Subscribe to the cards of a board
{
"kinds": [30302],
"#a": ["30302:<card-1-event-author-pubkey>:<card-1-d-identifier>","30302:<card-2-event-author-pubkey>:<card-2-d-identifier>",...]
}