=============================================================================================================================
Comparison between `Muse <https://museapp.com>`_ and `Secure-Scuttlebutt <https://en.wikipedia.org/wiki/Secure_Scuttlebutt>`_
=============================================================================================================================

These are the last two event-driven database systems I, Henry, worked on. Contrasting them might give us some insights about the choices we want to make for Mass Market.

.. csv-table:: System Comparisson
    :header-rows: 1
    :widths: auto
    
    "Muse", "SSB"
    "Server holds all *User Log*'s", "One Log per client/feed"
    "Log is shared between all devices of a User", "no multi-device => we want multi-clerk"
    "Writes happen as RPC to the Server ","writes always happen locally, which allows for true p2p between local clients"
    "Local-first via “pending” writes ","works b/c no complex shared state between feeds. Threads of posts are grow-only sets, in a sense."

Let's consider the Muse model for us: The **Relays** would hold the write primitive, which mutates the **Listing** finally.

Stores/clients would fetch the mutations/events from a **Relay** and apply them locally, to reconstruct the state and verify against on-chain commitment data.

.. note:: The **Relays** *build* the Log, **Store** users *write* to them.

The important distinction here is that the state of listing is the combination of all mutations applied, not the latest/longest chain.

Let’s assume we have two clerks working at a store: everything should be fine until they change the same item.

.. image:: ../images/MutateListing.png
    :alt: Mutating the listing