Glossary of terms

Name	Description
Node	A physical machine that is running the Disgo node in the network.
Contact	A contact is a running node in the network that can be "contacted" over a network protocol. A contact has a specific address value with a unique hostname. It can be a simple node or a full node on the network. This term is used specifically in the context of Disgovery.
Simple Node	A simple Node refers to a node on the network that does not necessarily need to run DAPoS consensus and is more commonly going to refer to nodes that are not a Delegate, Seed or other node type that has specific behavior in the network.
Full Node	A full node refers to a node that is capable of running the full suite of operations that a node is capable of. A full node is will run consensus if requested, whether or not it is currently a delegate node. A full node also maintains a Kademlia Hash Table (KDHT) with a list of contacts in the network. Any node can request the list of contacts from a full node.
Bookkeeper	A Bookkeeper is a full node that has a specific responsibility with other bookkeepers to persist transactions to the ledger after Delegate consensus This is currently a proposal and not implemented
Learner	A learner is another name for a bookkeeper
Seed Node	A Seed node is a full node that has a specific static DNS name or I.P. Address. The purpose of the seed node is to provide a list of contacts and/or delegates to nodes joining the network that do not have an active contact available to them to call. The expectation of the seed node is to be the last line of calls when trying to join the network.
Delegate	A Delegate node is a full node that is one of the selected nodes that will perform DAPoS consensus during their tenure as a delegate. The delegates are elected in a 24-hour cycle. It is possible if not likely that a delegate node is re-elected many times.
Kademlia Hash Table (KDHT)	A distributed Hashtable that we use to store contacts in "nearest" order. This is used to maintain a list of all of the contacts that an individual running node knows about. If the desired address is not in the node's local KDHT, it can make requests to the contacts in its own KDHT to find nodes that do have information on that address. Requests to other nodes should result in receiveing the either the actual node, or the "nearest" node that the contact knows about ... which results in additional requests until the node is found or not found if it is offline.
Delegated Asynchronous Proof-of-Stake (DAPoS)	DAPoS is a new consensus algorithm developed by the Dispatch team for use in the Dispatch protocol. By electing Delegates to validate transactions, and leaving each delegate responsible for their own chain of transactions, DAPoS works like a gossip-protocol. DAPoS Delegates can write as many transactions per second to their chain as their hardware is capable, improving scalability over stepwise blockchain consensus algorithms.
More to come	We have a lot going on and there are a lot of terms that maybe we take for granted that are not in this list and should be. Our goal is to have a comprehensive list that can help even the most novice to navigate this emerging technology and understand what we are doing here at DispatchLabs.