The Dawn Nexus Archives Protocol

All data is stored on disk and sent in Google's Protocol Buffers format to optimise size and storage/network performance, and used with gRPC for integration into applications.

Database

The Dawn Nexus operates as gRPC linked distributed nodes with one server per database. The database is a registry containing a potentially arbitrarily growing number of applications that operate with the protocol.

1. Dawn Registry
2. Dawn Forum
3. ...

This is just an identifier type for messages, which must target a type of database. The first two are reserved for Nexus. New applications can simply generate a large (32 bit) random number which is certain not to have a collision.

Message

All messages are first wrapped in this container.

Type

1. Broadcast
   This is the message dispatched by a client to all the Validators in a Validator set for a particular location or application to write data to the database.

2. Crosscheck
   This is the echoing of the received message from the Client out to all other validators in the validator set. All validators examine each other's messages to ensure they are identical and correct according to the encapsulated message protocol.

3. Vote
   Validators vote to approve or disapprove each other's messages, the votes are distributed amongst them and a consensus is reached on the result, and if approved, the message gets into the log and the database changed accordingly.

4. Digest
   Every 64 write operations, the network triggers a rebroadcast of the log of the last 64 write operations. This ensures that if anyone has got it muddled the first time, within a minute or less, they will have the correct data.

Structure

1. Author
   Unique identifier as found in the Registry

2. Time
   Timestamp of author with UUID

3. DatabaseType
   Which database type

4. MsgType
   Broadcast/Crosscheck/Voting/Digest

5. Payload
   Message contents (one from below)

   1. Broadcast
      Protocol message specific to database

   2. Crosscheck
      Full received message

   3. Vote
      Peer assessment of message gossip

      1. Validator
         Account UUID of validator

      2. Hash
         Hash of validator's message

      3. Approve
         (1 or anything else for disapprove)

   4. Digest
      A list of the last 64 transactions as stored in a node's log

6. Hash
   Hash of all foregoing data

7. Signature
   Signature from the Author's private key

8. Intermediaries
   List of all the account ID's acting as Validators for this transaction

9. MsgHash
   Hash of all foregoing data

10. MsgSignature
    Signature from the Author's private key

Address

Type

1. IPV4
2. IPV6
3. TOR
4. I2P
5. ZEROTIER

Structure

1. AddressType
   Which type of network address (tor, ipv4, zerotier, i2p, ipv6)

2. Address
   The string recognised by the protocol

Node

Role

There is three types of Archives nodes:

1. Validator
   These are the nodes that process transactions and generate the stream of database updates. This is a list that is gazetted whenever it changes, with the type of data the node validates.

2. Replicator
   These nodes are just subscribing to the update stream and are being applied to some prescribed purpose by its operators, such as running some service tied to the database. These nodes also advertise their services on a shared list.

3. Client
   The client just subscribes to, or polls for some of the database updates that it is interested in, and caches data generated by queries. A user will generally want to control their own replicator as well or trust those they use. The client also sends out new transaction broadcasts to the Validators. They are not listed.

Structure

1. Role
   Validator/Replicator

2. Addresses
   List of addresses the node can be reached at

3. Expiry
   Date after which this advertisement will become stale