Mostr uses the nostr protocol in novel ways to provide an immutable changelog and seamless synchronization.
The Task
Let's look at what a Mostr task is made up of:
The task title is the content of the nostr event creating the task, and apart from metadata like creation date the only immutable element of a task. To change the title, you have to create a new task.
The state takes a special place, because it has its own event kinds for different types of states (Open, Pending, Done, Closed, Procedure) adapted from Nostr NIP 34. These can be further subdivided by giving the state a description in its content field, which could then form Kanban columns.
All other properties, such as hashtags, priority, parent and assignee, are tags which can be added to (or for priority and assignee, replaced) by a new event with such tags. Assignee and priority are not something that is expected to be changed frequently by different people especially when the displayed priority will incorporate the due date into a dynamic calculation so that urgency calculation can be left to the task manager.
Deletion or replacement of properties do not exist: Properties can either be amended - such as the description, by adding new notes, as well as tags, parents and dependencies - or superseded by one with a newer timestamp (priority, assignee, state), but the previous one will always stay in the history.
For the rare case of multiple people changing the state of a task and the latest one not being correct, it can easily be corrected by a new event. But this should never happen anyways:
Usage
If multiple people mess around with one task, especially its state - one of the few properties where a sync can lead to unexpected results, something is probably off with the processes. Mostr makes it supremely simple to subdivide a task, so as soon as multiple people work on something, it should be appropriately subdivided. This then makes offline work very easy.
It is a consideration to engrain Task Ownership technically thus that only one owner of a task can make changes to it, except for adding comments (not to be confused with notes, which form the task description). But even without that enforcement, Using Mostr appropriately should not lead you into conflicts.
Protocol Level
One last thing to keep in mind here is that each event is entirely independent. They can be visualized as a tree since most events refer to a parent and ordered by timestamp, but there is no chain like in git which could warrant a merge of diverging states.
Synchronization happens entirely independently to interpretation of the data. Where other software does merge conflict resolution, nostr events are simply combined into one timeline. Then the mostr client simply forms a time-ordered sequence of events and accounts for each one, in some cases displaying only the latest one but never discarding any data.