Yes that is true.. sorry missed to mention that!
To add more detail -- I want to assign a card that I created to someone else, so that they can update it with the progress
i assume this question is for kanbanstr? i have no clue how you'd do this. gotta call in the big brains nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 nostr:npub1ymt2j3n8tesrlr0yhaheem6yyqmmwrr7actslurw6annls6vnrcslapxnz
Discussion
there is probably a much better way of doing this but off the top of my non developer head, maybe if the assignee accepts the event or card, the event gets copied and created by the new assignee/owner. then the old event is updated by the original creator in status the points to the new owner. *shrug* /notadev
Updates could be posted as responses to the original event. your client could renderer these as updates to the main item whereas other clients could render these in a thread style whilst retaining their meaning.
Another approach is to assignment via a tag in your replaceable event that points the assignee's pubkey. Instead of your app using the standard nostr behavior of honoring the version of the replaceable with the highest created_at date from your pubkey, it could also honor version from assigned pubkeys too.
When designing the event structure consider how it may be rendered by clients that won't honour your permissions system. Look at the Status events in NIP-34, they can be rendered as responses to the original event or as part of the item itself.
my advice it to try and make it simple, anti-frague, gracefully degradable, and easy to implement in other clients as possible.