DanConwayDev on Nostr: Updates could be posted as responses to the original event. your client could ...
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.
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.