Task and workflow-related NIPs

[danieldaquino]

This PR draft introduces 4 new NIPs that can be used to implement task and project management systems — as well as other productivity tools — using Nostr.

Motivation

Most mainstream productivity and task management tools are either closed, or have limited interoperability, which leads to a myriad of issues, including:

• The need for manual data entry between different tools that don't integrate well, leading to inefficiencies, human errors, and data silos.
• The missed opportunity to use existing tools with closed platforms.
• The need to develop and maintain several API integrations to connect different tools, which is time-consuming and costly.
  • For instance, to get $N$ tools to work together, one would need to implement up to $\binom{N}{2}$ (i.e., $\frac{n!}{2!(n-2)!}$) API integrations to cover every possible tool-to-tool combination, which quickly becomes unmanageable. With Nostr, that number could be theoretically reduced to as low as $N$ integrations — one for each tool to the Nostr protocol.
• The fact that businesses often need to build custom software to model or integrate specific business workflows that do not fit existing tools, leading them, in turn, to reinvent the wheel for task management schemas, logic, and UIs.
  • Usually, the starting point for most internal tools and workflows are frameworks that provide database, authentication, and basic UI primitives — which is still a lot of work to build and maintain, specially for small teams or startups.

Note: I have personally experienced all these issues, and can confirm that they are real and painful.

Benefits

The proposed NIPs aim to address these issues by providing a set of common formats and specifications that promote standardization and ease of integration across multiple task management systems and other productivity tools, bringing the following benefits:

• Interoperability: Businesses and individuals can implement specialized tools and workflows more efficiently to fit their specific use case, benefiting from the underlying Nostr infrastructure (SDKs, relay software, libraries, etc.) that support these protocols.
• A new source of contributions: Businesses building valuable tools using Nostr would inevitably end up contributing to those SDKs, libraries, and relay software, which would benefit the entire ecosystem.
• Reduced development time and costs: By leveraging these NIPs, businesses can reduce the time and costs associated with developing and maintaining custom task management solutions, as well as the integrations between different tools.

Rationale and approach

Task management and workflows are very diverse, there is no one-size-fits-all solution that can cover all use cases. Therefore, these NIPs have been designed to be small and modular. This approach deliberately avoids the imposition of a one-size-fits-all solution, promoting instead a framework of reusable primitives. By isolating each NIP to address specific components of task management, and without over-constraining the specifications, they can be tailored to meet more use cases and be combined in various ways.

Some fragmentation on the consensus around the state of tasks is acceptable (i.e. When is a particular task considered "done"? Who is allowed to change a task?), because consensus is usually done at an organizational or project level, so it's not a problem if different organizations or projects to use slightly different rules. The important thing is that the same primitives and tools can be used, and data can be shared and integrated between different tools and systems without too much friction.

Other notes

• The NIPs have been named with placeholder values for now — final numbers can be assigned later.
• This PR is still largely a draft, and I am quite open to changes and suggestions.

I would love to hear and discuss any feedback, suggestions, or concerns you might have.

Thank you!

[danieldaquino]

CC @fiatjaf @jb55, would love to hear your thoughts!

[fiatjaf]

I didn't read everything yet, but it looks good and well-thought. Except for the edit request event, which I like and I think it could be used elsewhere, the other NIPs could all be merged into one? They're all interdependent, right? Sorry, I'll read better when I have more stamina.

[vitorpamplona]

Can we make the kanban spec compatible with https://www.kanbanstr.com?

[danieldaquino]

Thank you for reading @fiatjaf!

Except for the edit request event, which I like and I think it could be used elsewhere, the other NIPs could all be merged into one? They're all interdependent, right? Sorry, I'll read better when I have more stamina.

In terms of interdependencies:

• NIP-XXB (Simple To-do flow) depends on NIP-XXA (Base task object)
• NIP-XXC (Kanban flow) also depends on NIP-XXA (Base task object)
• NIP-XXB and NIP-XXC are independent of each other.
• NIP-XXD is completely independent of A, B, C

I wrote A, B, C as separate NIPs because I wanted to give clients/relays the option to implement either a "to-do" flow, a "Kanban" flow, or some other flow that is not yet listed in here (e.g. Gantt charts could be another such workflow that could be built on NIP-XXA). In other words, I did not want to force clients/relays to implement a specific flow if it doesn't interest their use case.

We could discuss merging A, B, C if needed, as long as we can give implementers the flexibility to pick the workflow that works best for them (i.e. I would not want to force an "Apple Reminders" clone app to implement a Kanban flow, and vice versa)

[danieldaquino]

@vitorpamplona

Can we make the kanban spec compatible with https://www.kanbanstr.com?

Interesting, I don't know much about it yet. How does kanbanstr work?

[vitorpamplona]

They have a PR open here #1665

[danieldaquino]

Can we make the kanban spec compatible with https://www.kanbanstr.com/?
They have a PR open here #1665

Thanks @vitorpamplona, I had some more time to go through that PR. To answer your question, I think the kanban spec here can be modified to be very close and mostly compatible with the "Board Event" spec at #1665, but there is one important fundamental difference between this proposal and #1665.

In #1665, the "Card Event" makes a reference to the board it lives in, and only exists within the context of Kanban boards. That is the reverse approach from the one proposed in this PR. In this PR, the Kanban Board makes reference to items it tracks instead (which I believe allows for more flexibility, different use cases, and easy integration with other NIPs (such as NIP-34 git issues)). Other than that, the schema of the board event could be the same or similar to #1665.

cc @vivganes, I am curious to hear what your thoughts are on this! And whether having the board refer to cards/tasks instead would work for your intended use case.

I am also curious to hear from @pablof7z about his thoughts on this approach. I believe it solves some of the concerns he raised in #1665.

Thank you!

[vivganes]

@danieldaquino - I initially added the cards list in the board event like your suggestion. However, I changed my approach due to the following reasons:

1. Avoidance of race condition when two people update/add their cards into the same board. Some situation like - Just before the team review meeting, everyone updates/adds their cards. We do not want race conditions to remove cards that they just added.

2. Ability to track cards in different boards than where they originated (using the Tracker card events proposed in Multi-User Kanban boards on Nostr #1665) - Something like a separate board for executives, but without requiring the duplicate update for status/column in the executive's board. For example, I wanted the team to update the card to 'Done' in their board, and it would automatically start showing in 'Done' column in the executive's board. This allows ability to track required things in different boards, removing the possibility of micro-management.

[pablof7z]

BRAVO!!!

Most people design too narrowly for exclusively their own use case.

Again... BRAVO!

[pablof7z]

Maybe just markdown instead of GFM?? Or perhaps asciidoc?

[danieldaquino]

I would be ok with CommonMark markdown (a.k.a. "regular" markdown), it's probably easier to support than GfM. I will update!

[fiatjaf]

NIP-23 has miserly defined Markdown specs that we should probably reuse here, no?

[danieldaquino]

I agree.

My only issue with NIP-23 is that it is a bit ambiguous on whether it follows CommonMark or GfM (Probably CommonMark?), which means that I don't know if it would support markdown tables (for example) — but not a big deal honestly, I am happy to use whatever Markdown spec most of Nostr is using. I guess those ambiguities are out of the scope of this PR, we should delegate that decision to NIP-23.

I will update that on the next version.

[pablof7z]

I think having p tags that are editors is an underutilized tool -- I've implemented that in https://collab-lemon.vercel.app/ and works like a charm.

The owner just p tags the people that can edit the board and when a client wants to know the latest version they just REQ with "#d": [ "<d-tag-of-the-board>" ], "authors": [ "<all-p-tagged-pubkeys>"

[danieldaquino]

That's a very nice idea, and I was debating myself back-and-forth over this quite a bit — there are multiple pros and cons to consider.

However, I found one issue with this scheme which unfortunately is a blocker in my opinion. And that is that this is not compatible with NIP-01.

NIP-01 specifies:

for kind n such that 30000 <= n < 40000, events are addressable by their kind, pubkey and d tag value -- which means that, for each combination of kind, pubkey and the d tag value, only the latest event MUST be stored by relays, older versions MAY be discarded.

The scheme proposed effectively uses a combination of kind, d tag, and multiple pubkeys, which breaks the specification of an addressable event.

I tried to think about whether this pragmatically would break things, and the answer is that it would break "a" tags:

The a tag, used to refer to (...) an addressable event: ["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:<d tag value>, <recommended relay URL, optional>]

Under this scheme we would not be able to link using anchor tags, because the pubkey of the latest board update cannot be known at the time the anchor tag is created — Anchor tags would be broken.

However, this made me think of a better way to handle multi-user board editing authorization.

We can simply make the board owned by the key that signs it, and push the rest of the complexity to key management and scripting. ALL possible multi-user editing authorization/rules can be implemented with a combination of:

• FROST-like signature schemes
• Edit requests + Scripting (e.g. A server listens to edit requests, and approves/rejects them based on an arbitrarily complex business logic)

An analogy: Imagine an office. Instead of having 3 side-by-side doors to let different people in with their own house keys, you can have one door with a powerful lock that can authorize based on any possible logic, and then you can distribute office keys to whoever you want.

Your example use case could be implemented using a group keypair to own the board, and a 1-of-N FROST signature scheme to let any participant edit it.

[danieldaquino]

Thanks @vivganes for your thoughts and insights!

1. Avoidance of race condition when two people update/add their cards into the same board. Some situation like - Just before the team review meeting, everyone updates/adds their cards. We do not want race conditions to remove cards that they just added.

That's a very good point that I haven't given enough thought yet. The alternative of having tasks/cards refer to the workflow (e.g. kanban board) could indeed reduce the risk of race conditions — but it concerns me that the task/card event specification is dependent on the kanban/workflow specification, which limits its reusability in other workflow contexts (e.g. apps similar to Apple Reminders, Gantt chart applications, etc)

I am going to do some more thinking on:

• whether we can make task/card events highly reusable for other workflows in a scheme where tasks/cards refer to workflows (e.g. boards, Gantt charts, etc)
• whether we could solve race conditions in the scheme where workflows refer to the tasks (preferably in a way that solves this problem for other list-related NIPs which would probably have similar issues)

2. Ability to track cards in different boards than where they originated (using the Tracker card events proposed in Multi-User Kanban boards on Nostr #1665) - Something like a separate board for executives, but without requiring the duplicate update for status/column in the executive's board. For example, I wanted the team to update the card to 'Done' in their board, and it would automatically start showing in 'Done' column in the executive's board. This allows ability to track required things in different boards, removing the possibility of micro-management.

Thanks for sharing that use case! I think the ability you describe will become important in other scenarios as well. More broadly, I am thinking of it as the ability to track/filter specific things and having some sort of "shared filter" among a group of people (e.g. executives, as you mentioned)

I will give it some thought!

[danieldaquino]

I am working on a new version of this proposal.

[danieldaquino]

Submitted version 2 of the draft, with a new model. It solves the problems brought up here, with zero compromises (in fact, it makes it more extensible than ever)

🏎️ Race condition issue was solved. It is now even better to prevent race conditions than either of the previous proposed approaches, without compromising any extensibility (actually it even makes it more extensible). More details in NIP-XXE

📋 Kanban board spec was updated to be much more compatible with Kanbanstr. cc @vivganes — More details in NIP-XXC

✌️Multi-user collaboration has a single well-defined consensus for much better interoperability — without compromising access control flexibility. It actually makes it more flexible for more use-cases. cc @pablof7z More details here

🏢 More extensibility for more use-cases, native NIP-34 git issue support, etc. For example, the executive board use-case pointed out by @vivganes is also now possible without requiring extra specs. See this example use case (read NIP-XXE for context)

I added some example use-cases with visual diagrams to how those could be implemented under this new NIP-XXE model.

The new NIP-XXE spec itself is less than 100 lines long, and only uses 3 simple concepts to bring all these benefits.

CC @fiatjaf, @pablof7z, @vivganes, @vitorpamplona, thanks for all the comments and insights on my first draft, I would love to hear your thoughts on this new draft!

[fiatjaf]

I just came here to say I checked in 4 different clients and they all support Markdown tables, so I guess that's the standard now.