mirror of
https://github.com/nostr-protocol/nips.git
synced 2025-02-24 06:09:01 +00:00
155 lines
4.6 KiB
Markdown
155 lines
4.6 KiB
Markdown
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,
|
|
"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
|
|
|
|
```javascript
|
|
{
|
|
"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
|
|
|
|
```javascript
|
|
// 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>",...]
|
|
}
|
|
```
|