Problem

Using the CCN API as a single source of truth is a great method of maintaining consistency and redundancy of stored messages when building dApps. But compared to regular databases, the API lacks the performance and expressiveness of the queries of DB solutions like PostgreSQL or SQLite.

Solution

Many dApps being developed on top of Aleph Messages usually only require a certain subset of all messages to be observed, like by a set of channels or senders.

Therefore, I propose to develop a light node or more fittingly "domain node", as in a node that synchronizes on a certain domain/subset of messages on the Aleph network. It should offer the following:

• Full reconfigurability in:
  • what kind of channels, message types, and senders will be retrieved and stored
  • which CCNs to use for message retrieval
  • what kind of SQL engine to be used
• Ease of use for developers
• Limited required dependencies and resources
• Optional validation of retrieved messages

Implementation

As discussed with @hoh, the best course for a minimal implementation would be:

• Define a Python & CLI interface to run a domain node
• Setup an SQLite database, which is well-known and compatible with many frameworks such as Pandas, Django and other SQL databases
• Setup a WebSocket or libp2p connection with a CCN to retrieve past and current messages and persist them in the SQLite DB

The user should be able to use this by either:

• Launch a separate process with the CLI and connect to the DB manually
• Launch the domain node inside their Python app and directly access the DB through sqlite

Later on, features typical of light nodes, such as message validation and proxying POST messages, can be implemented.