Simple Kanban Boards

[dluvian]

A simple way to do Kanban Boards because #1665 is too complex.
I intend to implement this in GitPlaza soonish but I hope I can get some feedback first.

@vivganes @vitorpamplona @SilberWitch @cypherhoodlum

[fiatjaf]

What about @danieldaquino's #1767?

[vitorpamplona]

Why is #1665 too complex? Is it just the fact that cards link to the board as opposed to the board event having all cards inside of it?

Given that:
1 - we constantly get race conditions with lists and
2 - lists easily hit relay event size limits and can't be saved in most relays..

... I have been pretty much against any kind of list-based solution in Nostr.

It starts easy but simply stops working when production events get big. And when that happens, the NIP must be completely redesigned, which takes forever.

[SilberWitch]

I love simplification, but defining the cards inside of the boards breaks the domain.
Cards are their own objects, will have multiple use cases, and need their own definition and attributes. If anything, cards make issues obsolete, as issues are just a type of card.

I'd only list the cards in the boards, if cards needed to be strictly and arbitrarily ordered (like sections in an article), but they are better when simply sorted by attribute, in the client. We've been testing this "linked in" model, as opposed to "list" model, and linked-in is superior. Relays show no noticeable lag and lists quickly hit limits and/or lead to oversized events.

30040s get around this through nesting, but that adds its own headaches. Avoid lists.

[fiatjaf]

I thought the goal of kanban boards was organizing cards from a top-down perspective, so whoever has control of the board can control what cards are in which list and in which position, no?

Having cards assign themselves to boards breaks this assumption and might be super cool but isn't a kanban board anymore.

[SilberWitch]

The other NIP says

In case there are no p tags to designate maintainers, the owner of the board is the only person who can publish cards on the boards.

[fiatjaf]

In case there are no p tags to designate maintainers, the owner of the board is the only person who can publish cards on the boards.

What happens if I assign a card to a board you control? You'll fall back into either client-side filtering (which means you may have to download thousands of invalid events from me spamming your board) or NIP-29-like relay-based filtering (you only accept cards from these relays that enforce your board rules) or maybe a mix of the two.

What is your proposed solution?

[SilberWitch]

We're relay-focused, so the latter.

I'm actually okay with some level of ambiguity. I've worked with public Kanban Boards before, for support topics and etc.

[SilberWitch]

Relays also control board visibility quite neatly. Or, you could add encryption. Or both.

I generally consider "design it public, allow for private/forking" a better model than trying to retain full control in the design.

[vitorpamplona]

You'll fall back into either client-side filtering (which means you may have to download thousands of invalid events from me spamming your board)

Not really. You can easily write a filter that only downloads cards from the board author (or all p-tag maintaners) and a-tag that specific board at the same time.

[fiatjaf]

That's true.

[vitorpamplona]

@dluvian I would do some testing to see how big of a board you can realistically support with all the a, e and p tags (assuming multi-user) with all their column configurations and relay hints. The default max event size (in json) of StrFry is 65536 bytes. Since you are adding a and es for each card, the max number of cards might be as low as 100.

[dluvian]

Why is #1665 too complex?

1. Existing events need to be wrapped in a card event
2. Wrapper event needs to be replaceable
3. No lazy loading

What about @danieldaquino's #1767?

Same problem with the wrapping and replaceability. And I dont like embedding JSON in events.

cards make issues obsolete, as issues are just a type of card.

Issues should not be replaceable. You could get rugged by an edit.

I thought the goal of Kanban boards was organizing cards from a top-down perspective, so whoever has control of the board can control what cards are in which list and in which position, no?

That's another problem I have with the other proposal. It claims to be multi-user but collaborators only have control over their own cards. Not even the board owner can move other people's cards.

the max number of cards might be as low as 100

That's a bummer. ~100 cards might be too low. I will move the columns to their own event so this limit applies to each column instead of the whole board.
Do relays have exceptions for contacts lists? Many people follow way more than 1k pubkeys

[vitorpamplona]

Cards need to be replaceable. I change their descriptions, titles, and asignees all the time.

That's another problem I have with the other proposal. It claims to be multi-user but collaborators only have control over their own cards. Not even the board owner can move other people's cards.

That's true, but isn't that a feature? The creator of the card must add the owner of the board to the card event if they are different.

[vivganes]

That's another problem I have with the other proposal. It claims to be multi-user but collaborators only have control over their own cards. Not even the board owner can move other people's cards.

That's true, but isn't that a feature? The creator of the card must add the owner of the board to the card event if they are different.

I sense that we are talking about two different usecases here.

@dluvian is talking about the use case where he will be able to show Git issues/PRs in a Kanban board. This is right now possible only through "Tracker Cards" in #1665 which are different from the plain vanilla Cards. To support this use case, we need to create a board per repo and then add tracker cards for each issue/PR in the board. The cards move columns when the underlying issue changes status.

@vitorpamplona is talking about plain-vanilla cards which are editable in a Kanban board directly (not the Tracker cards).

I believe the solution is simple (It's possible that I am wrong :P)

There is no restriction as to what event kind can have a a tag referring to a board event. If we want a Git issue event to belong to a board, that should not be a problem. Each client can choose what event kinds it supports and implement the Card logic accordingly.

For example, @dluvian could create a Kanban board implementation that allows Git issue events as cards.

Tomorrow, if someone wants to track blog articles (draft -> review -> published), they can use an additional s tag in their original event and tag it to a board that they control, we can move them on a Kanban board too.

It is ideal to have the status/column in the s tag of the event but I understand that is not the case with many events.

What do you think? @dluvian @vitorpamplona