Polkadot Native DApp

This is a writeup about how I envision this application can be deployed, as a standalone DApp, relying on almost nothing more than Polkadot (or, any other substrate-based chain). The goal is to have a permissionless notification service for the Polkadot ecosystem, whereby you can stay informed about relevant transactions and events related to an account, or a set of accounts.

The main idea is to use the blockchain as the main tool for which it was created: The source of truth for contentious data, in this case payment ledger. In other words we don't use any payment providers. Polkadot, and the transfer of DOT to a special account is the payment provider service.

In the simplest case, imagine: a batch(transfer(1 DOT), remark(config)) is sent to a specific account associated with the notification service. The amount of DOT in transfer will imply for how long you wish to use the service (e.g. 0.1 DOT per account per month per chain to listen to). The remark contain a JSON configuration, possibly exactly as the one that the application uses. This orders the notification service to spawn a new instance of the application, with the given configuration, for the given duration.

Now, let's imagine the DApp through which the user sends this transaction.

• As the first step, they connect to the DApp, and provide an account with which they are going to sign and send the payment transaction.
• Then, they can chose between either a few prelude options:
• Then, the are walked over a few steps that help us fill the aforementioned JSON configuration. First, they select the accounts they want to monitor. The default option is the account they chose to in the previous step, but they can edit it or add more.
• Then, they select the networks they want to listen to. Polkadoot is the default, a list of networks is shown as extra suggestion. Any wss endpoint can be valid in principle.
• Then, they select their notification filter. This is the more complicated aspect, so a list of presets should be show:
  • All notifications related to the accounts chosen before.
  • Staking reward notifications related to the accounts chosen before.
  • deposit events related to the accounts chosen before.
  • Or, chose build your own filter. This is basically selecting one of: All, Only or Ignore, and providing the list of associated pallets and methods.
• Finally, they receive a quota as a daily rate (most dominantly based on the amount of chains they wish to monitor). Once that's known, they select the number of days they wish to receive notifications for, make the payment, and that's it.

Here's a sketch that demonstrates the above:

If this idea really works, then creating a library called polkadot-payment-api that simplifies the process of receiving payments (and configs, as a batch of remark and transfer) from users.

Known caveats:

• Missed blocks are hard to compensate for. We need a simple database that atomically tells us with a very high degree of confidence which applicants have been serviced for which blocks. As long as we have this, if we have a failure in our side (or the ws goes down) we can easily recover. Although, then we'd lose our timeliness.
• Spawning a new node.js process per user, as explained above, is almost certainly not the "efficient way" to do things, but it does help simplify the design at this early stage.