github.com/jbendotnet/noms@v0.0.0-20190904222105-c43e4293ea92/doc/decent/architectures.md (about)

     1  [Home](../../README.md) » [Use Cases](../../README.md#use-cases) » **Decentralized** »
     2  
     3  [About](about.md)  |  [Quickstart](quickstart.md)  | **Architectures**  |  [P2P Chat Demo](demo-p2p-chat.md)  |  [IPFS Chat Demo](demo-ipfs-chat.md)
     4  <br><br>
     5  
     6  # Architectures
     7  
     8  There are many possible ways to use Noms as part of a decentralized application. Noms can naturally be mixed and matched with other decentralized tools like blockchains, IPFS, etc. This page lists a few approaches we find promising.
     9  
    10  ## Classic P2P Architecture
    11  
    12  Noms can be used to implement apps in a peer-to-peer configuration. Each instance of the application (i.e., each "node") maintains a database locally with the data that is relevant to it. When a node creates new data, it commits that data to it's database and broadcasts a message to it's peers that contains the hash of it's lastest commit.
    13    
    14  ![P2P Architecture](./p2p-arch.png)
    15   
    16  Peers that are listening for these message can decide if that data is relevant to them. Those that are interested can pull the new data from the publisher. The two clients efficiently communicate so that only data that isn't present in the requesting client is transmitted (much the same way that one git client sends source changes to another).
    17  
    18  Peers can use a flow similar to the following in order to sync changes with one another:
    19  
    20  ```nohighlight
    21  for {
    22     listen for new message
    23     if new msg is relevant {
    24        if new msg is ancestor of current commit {
    25           // nothing to do
    26           continue
    27        }
    28        pull new data from sender of msg
    29        if current head is ancestor of new msg {
    30           // fast forward to the new commit
    31           set head of dataset to new commit
    32           continue
    33        }
    34        merge new with current head and commit
    35        publish new commit
    36     }
    37  }
    38  ```
    39  
    40  Noms has a default [merge policy](https://github.com/attic-labs/noms/blob/2d0e9e738370d49cc09e8fa6e290ceca1c3e2005/go/merge/three_way.go#L14) that covers many classes of concurrent operations. If the application restricts itself to only operations that are mergeable by this policy, then Noms can automatically merge all concurrent changes. In this case, the entire database is effectively a CRDT.
    41  
    42  If this is not sufficient, then applications can create their own merge policies, implementing whatever merge is appropriate for their use case.
    43  
    44  # Decentralized Chunkstore Architecture
    45  
    46  Another potential architecture for decentralized apps uses a decentralized chunkstore (such as IPFS, Swarm, or Sia) rather than local databases. In this case, rather than each node maintaining a local datastore, Noms chunks are stored in a decentralized chunkstore. The underlying chunkstore is responsible for making chunks available when needed. 
    47  
    48  ![Decentralized Architecture](./dist-arch.png)
    49  
    50  The flow used by peers to sync with one another is similar to the peer-to-peer architecture. The main difference is data is not duplicated on local machines and doesn't have to be pulled during sync. Each app keeps track of it's latest commit in the chunk store.
    51  
    52  ```nohighlight
    53  for {
    54     listen for new message
    55     if new msg is relevant {
    56        if new msg is ancestor of current commit {
    57        // nothing to do
    58           continue
    59        }
    60        // No pull necessary
    61        if current head is ancestor of new msg {
    62           // fast forward to the new commit
    63           set head of dataset to new commit
    64           continue
    65        }
    66        merge new with current head and commit
    67        publish new commit
    68     }
    69  }
    70  ```
    71  We have a prototype implementation of an IPFS-based chunkstore. If you are interested in pursuing this direction, let us know!