Subscriber
Subscribing to the subjects
Subscribers bring value to the system by paying for the data provided by the Publishers and delivered by Brokers. Subscribers reach an on-chain agreement with Publishers on the service fee, i.e. data price, of the subject by subscribing to the corresponding service listed on the developer portal.
The content and format of the messages are not validated on the App Chain. Therefore, the Subscriber should refer to the on-chain service description and off-chain documentation provided by the Publisher. Additionally, most of the subjects can be previewed on the testnet before paying for them on the mainnet.
Read more about how to become a Subscriber in our official guide.
Clients
Subscribers are represented by one or multiple Clients. A Client is an entity authorized by a Subscriber to actually consume the data. Whereas, a Subscriber is an on-chain address that is paying for the data consumed.
In reality these can represent one and the same entity, but very often a single Subscriber could be paying for many Clients.
Under the protocol, a Subscriber is issuing consumption tokens to its Clients. Clients then use these tokens to consume data streams that are subscribed by the Subscriber.
The Subscriber-Client relations are based on trust
In the initial version of the Data Layer protocol, the Client management is left to the responsibility of the Subscriber, i.e. there’s no on-chain client management.
Crediting the services
As part of the Subscriber profile on-chain registration, it is topped up with credit. The credit is essentially the Subscriber’s Synternet tokens that are temporarily locked and can only be used for covering all liabilities of the Subscriber. For every message delivered to the Client a portion of credit is consumed.
Subscribers can top up their credit at any time. Forgetting to add credit to a profile would result in data streams, subscribed on-chain under corresponding services, being stopped for all the Clients of that Subscriber.
Unsubscribing
Subscriber can withdraw the credit from its on-chain profile only if he is not registered on the active services that are using it. Therefore, the Subscriber has to unsubscribe from the services first. After the initial unsubscription, the tokens that were left in its profile remain locked for a period of 14 days. Only after this locking period ends, the Subscriber can retrieve the remaining tokens to its wallet address.
The data accounting and payments are usually lagging behind the data consumption. How big this lag is depends on the rate of data consumption, but realistically this can only be from a couple of minutes to a couple of hours. However, the period, during which the credit has to wait for accounting actions to complete, is much longer as the on-chain accounting transactions can be challenged for some time after the fact.
Future Work
All future work is the research and development that is planned, however, this cannot be seen as a commitment to deliver certain features.
On-chain Client management
For truly decentralized applications (dApps) that have no backend, i.e. the App Chain is their only backend, Client management should happen as part of the on-chain business logic.
Trustless Subscriber-Client relations
Currently, it is assumed that the Subscriber-Client relations are based on trust, which means that there are no protection mechanisms for any of the undesired behavior between them, e.g. Client purposefully spending the Subscriber’s credit or the Subscriber withdrawing the Credit and closing the data streams for its clients without prior notice. However, these improvements will be considered in future releases.
Double spend prevention
Double spend is an event when a malicious Subscriber issues the same consumption token more than once. This situation must be detected and prevented by the system.
In order to prevent Subscriber double spend cases, Subscribers would be also required to credit their profiles, in addition to crediting the services they subscribe to. If an attempt of double spend was detected, a Subscriber who executed it would be penalized by slashing its credit. However, the protocol will need a way to distinguish between the cases, where it is apparent that the Subscriber acted maliciously, and not one of his Clients.