Mirror/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2025-02-22 05:09:00 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Task and workflow-related NIPs

Browse Source 
This commit introduces a few NIPs related to business use cases around
tasks and workflows
This commit is contained in:
Daniel D’Aquino 2025-02-07 03:33:39 +00:00
parent e286001789
commit fd3676c251
5 changed files with 335 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
README.md
View File

@ -99,6 +99,10 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
- [NIP-99: Classified Listings](99.md)
- [NIP-7D: Threads](7D.md)
- [NIP-C7: Chats](C7.md)
- [NIP-XXA: Tasks](XXA.md)
- [NIP-XXB: Simple To-do Flow](XXB.md)
- [NIP-XXC: Kanban Board Flow](XXC.md)
- [NIP-XXD: Event Edit Requests](XXD.md)
## Event Kinds
@ -140,6 +144,9 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `1068` | Poll | [88](88.md) |
| `1111` | Comment | [22](22.md) |
| `1311` | Live Chat Message | [53](53.md) |
| `1500` | Simple To-do Update Event | [XXB](XXB.md) |
| `1501` | Event Edit Request | [XXD](XXD.md) |
| `1502` | Event Edit Response | [XXD](XXD.md) |
| `1617` | Patches | [34](34.md) |
| `1621` | Issues | [34](34.md) |
| `1622` | Replies | [34](34.md) |
@ -233,6 +240,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `31990` | Handler information | [89](89.md) | |
| `32267` | Software Application | | |
| `34550` | Community Definition | [72](72.md) |
| `35000` | Task Event | [XXA](XXA.md) |
| `35001` | Kanban Board Event | [XXC](XXC.md) |
| `38383` | Peer-to-peer Order events | [69](69.md) |
| `39000-9` | Group metadata events | [29](29.md) |
@ -310,6 +319,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `clone` | git clone URL | -- | [34](34.md) |
| `content-warning` | reason | -- | [36](36.md) |
| `delegation` | pubkey, conditions, delegation token | -- | [26](26.md) |
| `due_at` | unix timestamp (string) | -- | [XXA](XXA.md) |
| `description` | description | -- | [34](34.md), [57](57.md), [58](58.md) |
| `emoji` | shortcode, image URL | -- | [30](30.md) |
| `encrypted` | -- | -- | [90](90.md) |

90
XXA.md Normal file
View File

@ -0,0 +1,90 @@
NIP-XXA
=======
Tasks
-----
`draft` `optional`
This NIP defines `kind:35000` (an _addressable event_) for tasks, generally referred to as "tasks", "to-do items", or "reminders".
This NIP intentionally does not define any information about workflows, states, authorization mechanisms, or any other complex task management features, as the needs and requirements for these vary greatly between different applications and use cases. This NIP is meant to be used only as a base for more complex task management systems, and only focuses on the basic information that models a task itself.
Workflows, states, and other task management features can be implemented on top of this NIP, and can be shared between different applications and services using the same base task model.
## Format and Structure of Task Events
### Event Kind
The `kind` of these events MUST be `35000`, which is an _addressable event_ as defined in [NIP-01](01.md).
### Content
The `.content` of these events MUST be used as the description of a task, and should be a string text in [Github Flavored Markdown syntax](https://github.github.com/gfm), with the following constraints:
- MUST NOT hard line-break paragraphs of text, such as arbitrary line breaks at 80 column boundaries.
- MUST NOT support adding HTML to Markdown.
- MUST NOT support adding JavaScript to Markdown.
Clients MAY render any inline [Nostr URI](21.md) into a rich interactive object or widget, to allow for easy navigation and interaction with the referenced content, or as simple hyperlinks.
### Metadata and Tags
- `"d"`, for a unique identifier for the task
Other metadata fields can be added as tags to the event as necessary. Here we standardize a few that may be useful, although they remain strictly optional:
- `"title"`, for the task title
- `"image"`, for a URL pointing to an image to be shown along with the title
- `"published_at"`, for the timestamp in unix seconds (stringified) of the first time the task was created
- `"due_at"`, for the timestamp in unix seconds (stringified) of the due date of the task
- `"archived"`, for a boolean value indicating whether the task is archived or not. If the task is archived, it SHOULD be generally hidden from the user interface, unless the user specifically requests to see archived tasks.
- `"t"`, for generic tags that can be used to categorize the task, which can be any string (e.g. `"work"`, `"personal"`, `"urgent"`, etc.)
- `"p"`, for referencing other users and their roles in the task (See below)
Other tags can be added as necessary, but they should be standardized and documented in a separate NIP. Clients SHOULD ignore any tags they do not understand.
#### Referencing Users
The `p` tag is used to reference other users and their roles in the task. The tag should be an array with the following structure:
```jsonc
["p", "<32-bytes hex of a pubkey>", "<optional role>"]
```
The role is optional, and this NIP only standardizes the following values:
- (Empty): The user is mentioned or CC'd in the task, but has no specific role.
- `"assignee"`: The user is assigned to the task.
- `"client"`: The user is the client or requester of the task.
- (Any other value): Any other role that is not standardized by this NIP, which for the purposes of this NIP is treated the same as an empty role.
### Editability
These tasks are meant to be editable, so they should include a `d` tag with an identifier for the task. Clients should take care to only publish and read these events from relays that implement that. If they don't do that they should also take care to hide old versions of the same tasks they may receive.
For simplicity and flexibility, this NIP does not define a specific mechanism to allow groups of users to edit the same task. This is deliberately left out to allow for different implementations to be built on top of this NIP in a way that best suits the needs of a particular use case. Examples of possible implementations include:
- A single user is assigned to a task, and only that user can edit the task.
- The task is signed using a collaborative signing mechanism, such as a multi-signature or FROST-like scheme.
- The task is signed by an authoritative keypair representing a group/company, and members of a group need to request changes to the task from that entity using [edit requests](XXD.md) or other mechanisms.
### Linking
The task may be linked to using the [NIP-19](19.md) `naddr` code along with the `a` tag.
## Example Event
```json
{
"kind": 35000,
"created_at": 1675642635,
"content": "This task is a placeholder for the description of the task. It should be written in [Markdown](https://github.github.com/gfm). Here is another task: nostr:naddr1qqzkjurnw4ksz9thwden5te0wfjkccte9ehx7um5wghx7un8qgs2d90kkcq3nk2jry62dyf50k0h36rhpdtd594my40w9pkal876jxgrqsqqqa28pccpzu. Please talk to this user for more information: nostr:npub13v47pg9dxjq96an8jfev9znhm0k7ntwtlh9y335paj9kyjsjpznqzzl3l8",
"tags": [
["d", "333e500a-7d80-4e7b-beb1-ad1956a6150a"],
["title", "Example task"],
["published_at", "1296962229"],
["t", "examples"],
["p", "b3e392b11f5d4f28321cedd09303a748acfd0487aea5a7450b3481c60b6e4f87", "assignee"],
["due_at", "1298962229"]
],
"pubkey": "...",
"id": "..."
}
```

57
XXB.md Normal file
View File

@ -0,0 +1,57 @@
NIP-XXB
=======
Simple To-do flow
-----------------
`draft` `optional`
This NIP defines a simple workflow for task management, using [NIP-XXA](XXA.md) as a base and requirement.
This NIP is meant to model a very simple task workflow. Possible use cases include:
- Individual to-do-list-style applications (Similar to Apple Reminders, Google Keep, etc)
- Group to-do-list-style applications (Similar to Apple Reminders shared lists)
- Systems that need to model to-do items to be completed by multiple people (e.g. an educational course that requires students to complete the same tasks, some onboarding system that requires new several people to complete the same tasks, etc)
- Any other system that needs to model simple to-do items (although some may need to extend this NIP to support other features)
### Workflow
In this workflow, [tasks](XXA.md) have only two states: OPEN/TODO and COMPLETE/DONE.
To update a task state, users signal updates using the task update event defined below.
The exact interpretation of which task update events are valid (e.g. to compute a final global state for each task) is left to the implementation of specific clients and relays, or to other NIPs.
### Task Update Event format
A task update event is a **regular** ([NIP-01](01.md)) event of `kind:1500` that signals a change in the status of a task.
The `.content` of these events MUST be one of two values:
- `"TODO"` to signal that the task is now open/pending/to-do.
- `"DONE"` to signal that the task is now closed/complete/done.
The list of required tags are as follows:
- `a` _(required)_: Coordinates to the kind `35000` task being updated.
Any other tags are strictly optional, and this NIP does not attach any specific meaning to them.
```jsonc
{
"id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
"pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
"created_at": <Unix timestamp in seconds>,
"kind": 1500,
"content": <"TODO"/"DONE">,
"tags": [
["a", "<kind integer>:<32-bytes lowercase hex of a pubkey>:<d tag value>", <recommended relay URL, optional>] // Coordinates to the task being updated
(...) // Any other tags are optional
]
}
```
### Other notes
1. Consensus on the global state of tasks is left to the implementation of specific clients and relays, or to other NIPs. This is done on purpose to allow for flexibility in the implementation of each use case.
2. The task update event format is a regular event (not replaceable or addressable) because — as mentioned above — the final state of whether a user has completed the task or not is not necessarily the most recent event.
- As an example, consider the example of some educational platform that assigns a task to a student, and no longer considers task updates after a due date. In this case, the final state of the task is not the most recent event, but the last one that was created before the due date.
- Another reason is that clients may want to display the task update events in a timeline, so having older events may be useful to understand the history of the task.

102
XXC.md Normal file
View File

@ -0,0 +1,102 @@
NIP-XXC
=======
Simple Kanban Board Workflow
----------------------------
`draft` `optional`
This NIP defines a Kanban board workflow, building on [NIP-XXA](XXA.md) for tasks. This proposal allows tasks to be organized within a Kanban board using definable states, linked tasks, and sorting order.
The Kanban board is a simple workflow tool that allows users to visualize tasks in different states of completion. Each task is represented as a card that can be moved between different columns, each representing a different state of completion.
This is useful for use cases similar to apps such as Trello, Asana, Jira, Github Projects, and to model business processes that require multiple stages of completion.
# Kanban board event format
## Event Kind
The `kind` of these events MUST be `35001`, and this is meant to be an _addressable_ event as defined in [NIP-01](01.md).
## Content
The `.content` of a kanban board event MUST be a JSON string defining the permissible states for tasks. The JSON should be in the following format:
```jsonc
{
"title": <title string>,
"description": <OPTIONAL description string>,
"states": [
{"id": <id string>, "label": <label string>, "color": <OPTIONAL color value>},
<other possible states>
]
}
```
The `states` array MUST contain at least one state object. Each state object MUST have the following fields:
- `id`: A unique identifier for the state within the board. This identifier MUST be unique within the board. (e.g., "todo", "in-progress", "in-review", "done")
- `label`: A human-readable label for the state. (e.g., "To Do", "In Progress", "In Review", "Done")
- `color`: An optional color value for the state, to provide a visual cue. See the "Colors" section below for allowed values.
Other fields MAY be added to the Content JSON, on other NIPs that extend this one.
### Colors
The `color` field can have any of the following values:
- One of the following preset colors:
- "red"
- "orange"
- "yellow"
- "green"
- "cyan"
- "blue"
- "purple"
- A hex RGB color code (e.g., `#FF0000`).
Clients MAY choose to display the color in the UI, but it is not required. The color is intended only to provide a visual cue to users.
The exact color codes for the preset colors is not specified and is left to the discretion of the client to match their own color scheme.
## Tags
Each task on the Kanban board should be added using an `a` anchor tag. These tags reference the task events defined in [NIP-XXA](XXA.md). The tags are structured as follows, with one dedicated value for the task's current state within the Kanban board:
```jsonc
"tags": [
["a", "35000:<32-bytes lowercase hex of task author's pubkey>:<task d-identifier>", "<state id string>"],
["a", "35000:<32-bytes lowercase hex of task author's pubkey>:<task d-identifier>", "<state id string>"],
["a", "35000:<32-bytes lowercase hex of task author's pubkey>:<task d-identifier>", "<state id string>"],
// Other tasks can be added similarly.
]
```
The `state id string` MUST match one of the `id` values defined in the Kanban board's `.content` JSON.
Clients SHOULD by default display the tasks in the order they are listed in the `tags` array, from top to bottom. If the client allows users to reorder tasks, the client MUST update the `tags` array sorting order accordingly. However, the client MAY choose to display tasks in a different order based on other criteria, such as due date or priority, sorting filters, etc.
Other required tags:
- `d`: The board's unique identifier
Optional tags:
- `p`: MAY be interpreted as the board's participant list, which could be used by clients and relays to determine who is allowed to view or edit the board, but the exact interpretation is left to the implementation.
### Linking Kanban and Tasks
When a task's status changes within this board, the tag's state value should update to reflect its new position in the workflow sequence.
### Multi-user editing
This NIP explicitly does not define how different users can edit the same board, since different use cases may require different solutions.
However, here are some possible approaches (listed here for inspiration, but not a requirement):
- A single authoritative private/public keypair that represents a group/team of users, and produce/sign new board updates, by having a program listen to [edit requests](XXD.md) from any of the group members, and automatically approving/rejecting them based on the group's rules.
- This program could be simple or very complex with a lot of rules on who can edit what, when, and how — to fit several business use cases.
- A FROST-like key scheme can be used to require multiple signatures from different users to approve a change to the board.
- A board can be owned and controlled by a single user, publishing the board to private relays (single-user apps)
- A board can be controlled by a single user, but allow other users to view it.
- A client could listen to board events from a group of users and choose to display the board based on the most recent event it has seen from any of the users, or somehow "merge" different users' boards.
## Intended use cases
- Trello-like boards for personal or team task management.
- Business process workflows that require multiple stages of completion.

76
XXD.md Normal file
View File

@ -0,0 +1,76 @@
NIP-XXD
=======
Event Edit Requests
-------------------
`draft` `optional`
This NIP introduces a protocol allowing any Nostr user to submit an edit request for any addressable event initially authored by another user. It aims to streamline collaborative editing while maintaining clear identification of original and requested contents.
## Edit Request Event Kind
Edit requests are a `kind: 1501` **regular** event with the following structure:
### Event Structure
An edit request consists of a JSON object with the following structure:
```jsonc
{
"id": <32-bytes lowercase hex-encoded sha256 of the serialized event data>,
"pubkey": <32-bytes lowercase hex-encoded public key of the edit requestor>,
"created_at": <Unix timestamp in seconds>,
"kind": 1501,
"content": "{
\"tags\": <proposed new tag contents>,
\"content\": <proposed new content string>
}",
"tags": [
["a", "<kind integer>:<32-bytes lowercase hex of the original author pubkey>:<d tag value>", "<relay-url>"] // Coordinates to the event being edited
],
"sig": <64-bytes lowercase hex of the signature of the sha256 hash of the serialized event data>
}
```
### Tags
- `a` (anchor): Required. Points to the addressable event that the user wants to edit.
### Content
The `.content` field is a JSON string containing the proposed changes (new ".content" and ".tags") to the original event. It should contain all contents that the requestor would like to see in the updated event (i.e. Not just the changes, but the full new content).
## Edit Request response event
The author of the original event can respond to an edit request by creating a `kind: 1502` **regular** event with the following structure:
```jsonc
{
"id": <32-bytes lowercase hex-encoded sha256 of the serialized event data>,
"pubkey": <32-bytes lowercase hex-encoded public key>,
"created_at": <Unix timestamp in seconds>,
"kind": 1502,
"content": "<APPROVE|REJECT>",
"tags": [
["e", "<32-bytes lowercase hex of the kind:1501 edit request event id>", "<relay-url>"] // Reference to the edit request event
],
"sig": <64-bytes lowercase hex of the signature of the sha256 hash of the serialized event data>
}
```
This event is used simply to communicate the author's decision on the edit request, in order to provide the requester with feedback on the proposed changes. Clients and relays SHOULD send these events to improve the user experience by providing feedback on the edit request, so that the requester's client can update the UI accordingly.
## Edit Request Workflow
1. A user creates an edit request event with the proposed changes and tags pointing to the event to be edited.
2. The edit request is broadcasted to the network.
3. The author of the original event receives the edit request. The author can either approve or reject the edit request:
- If the author approves the edit request, they create a response event with the `APPROVE` content, applies the proposed changes to the original event, and broadcasts the updated event.
- If the author rejects the edit request, they create a response event with the `REJECT` content.
## Intended Use Cases
- Apps/Features that enable collaborative enhancements in articles, posts, or any addressable nostr event.
- Enabling nostr entities to be collaboratively editable by multiple users (e.g. Tasks, Kanban boards, wikis, etc).
- This can be through a human editorial flow, or through automated systems that automatically approve or reject edit requests based on programmatic rules.