:PROPERTIES:
:ID:       mostr-merges
:CREATED:  [2024-11-26 Tue 14:02]
:END:
:LOGBOOK:
- State "DONE"       from              [2024-11-26 Tue 14:02]
:END:
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 [[https://nips.nostr.com/34][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.