Terms ===== .. glossary:: Store A *Store* is operated by a merchant to sell (physical) goods. It exists an `EIP721 `_ as on-chain information in our :term:`Smart Contract` system. It is mainly accessed by a JavaScript-powered Website, available at a certain known domain, which interacts with a :term:`Relay` to supply the Listing. Relay A *Relay* main job is to manage the :term:`Listing` and :term:`Inventory` of a :term:`Store`. It is also responsible to sequence :ref:`ref_market.mass.Event` writes from Users into a logical log of *Events* and send *Events* to all Clients of a Store. KeyCard A seperate cryptographic KeyPair that is used to primarily for interacting with the :term:`Relay`. It is used to sign :ref:`ref_market.mass.Event`'s and transactions, and is used to identify the User to the Relay. Its main purpose is to reduce interactions with the :term:`Wallet` of a User. See :ref:`keycards-vs-user-wallets` for more information. Listing Contains the *public* information of Items in a :term:`Store`. Names, Prices and other metadata. Inventory Is *private* to the :term:`Store`. It is information attached to Items. Most notably how many of an Item are available at a given time, since this could be used to profile sales if it were public. Wallet A *Wallet* is a piece of software that is used to manage a User's funds, creation of cryptographic signatures and interaction with :term:`Smart Contract`'s. A common example is `MetaMask `_. Smart Contract A *Smart Contract* is a piece of code that is executed and verified by VM Blockchain, like `Ethereum `_. The Mass Market system consists of three Smart Contracts: *Store Registry*, *Relay Registry*, and *Payments Factory*. See :ref:`smart-contracts` for more information. Operator The *Operator* of the :term:`Relay` is responsible for funding the :term:`Wallet` of the Relay, so that it can pay for the needed Gas. - While :term:`Store` **owners** *can* host their own :term:`Relay`'s, they shouldn't have to. The long-term idea being that we find ways to incentivising the operation of :term:`Relay`'s that serve multiple :term:`Store`'s. Those people being the *Operators.* Eventual Consistency In contrast to classical on-line database systems (e.g. RDBMS like SQL), in `event sourcing (ES) `_ (aka append-only logs) all mutations of the state are broken up into discrete events. Hence, instead of retrieving a full table of data, each *INSERT* and *DELETE* is transmitted individually, at least conceptually. This helps a lot in distributed systems to gain `eventual consistency `_, which allows for fault tolerant processing during network partitions, if the required semantics can be established for partitioned scenarios.