Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simple Kanban Boards #1804

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

dluvian
Copy link
Contributor

@dluvian dluvian commented Feb 22, 2025

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
Copy link
Member

fiatjaf commented Feb 22, 2025

What about @danieldaquino's #1767?

@vitorpamplona
Copy link
Collaborator

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
Copy link
Contributor

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
Copy link
Member

fiatjaf commented Feb 22, 2025

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
Copy link
Contributor

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
Copy link
Member

fiatjaf commented Feb 22, 2025

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Collaborator

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
Copy link
Member

fiatjaf commented Feb 22, 2025

That's true.

@vitorpamplona
Copy link
Collaborator

@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
Copy link
Contributor Author

dluvian commented Feb 22, 2025

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
Copy link
Collaborator

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
Copy link
Contributor

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

@SilberWitch
Copy link
Contributor

Not even the board owner can move other people's cards.

He can just hide any cards he can't control.

Anyone can refer to any event in their own, regardless of who created the original event, since we have no method for censoring. I'm not actually sure why it should bother me, if someone wants to write cards I can't control, if I can just ignore them.

@SilberWitch
Copy link
Contributor

SilberWitch commented Feb 24, 2025

No large event sizes, please.

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

That's true, especially if you're not versioning them. Although, that goes for any replaceable event.

The current issue events are a UX non-starter, tho. We just link to them from elsewhere and document them fully, with markup, in the new location, and then tag them with an ID.

Like so:
https://gitcitadel.com/r/naddr1qvzqqqrhnypzplfq3m5v3u5r0q9f255fdeyz8nyac6lagssx8zy4wugxjs8ajf7pqy88wumn8ghj7mn0wvhxcmmv9uqq5stvv4uxzmnywf5kz2elajr/issues/note13vlgkdkev4eudquh5v20gh3phagmps9wjl576ws0zuqlva265fkqsn3fp8

@cypherhoodlum
Copy link
Contributor

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

On our client we have rolled our own issues that are editable and we're retaining the edit history. Can't really rug someone's event cache arbitrarily. But back to the topic.

Having written my own (now abandoned) Kanban implementation that eliminated all race conditions I think the plain Kanbanstr board spec without issue cards is a very good solution. Cards need to be replaceable to make the UX actually work. Otherwise you'd be dealing with a more complex delete-and-add-new logic to move cards. Replaceable card events is just a cleaner solution.

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.

I think @vivganes is making a lot of sense here. There's no need to replace the whole NIP-100 spec just to add issue cards.

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.

I think this is the biggest flaw of the NIP-100 spec. Putting the column uuid in the s tag would make much more sense than having the title of the column in the s tag.

@alltheseas
Copy link
Contributor

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.

github tracks edits, and UI is excellent, in my opinion.

image

image

@dluvian
Copy link
Contributor Author

dluvian commented Feb 26, 2025

github tracks edits, and UI is excellent, in my opinion.

Another reason to use normal events. You would lose the edit history by using replaceables

@dluvian
Copy link
Contributor Author

dluvian commented Feb 26, 2025

There's no need to replace the whole NIP-100 spec just to add issue cards

The complexity lies in having to wrap these issues in replaceable card events which then have to be updated all the time to get the latest version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants