Multi-User Kanban boards on Nostr

100.md

@@ -0,0 +1,184 @@
+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>",...]
+}
+```