You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
Implementation
As discussed with @hoh, the best course for a minimal implementation would be:
The user should be able to use this by either:
Later on, features typical of light nodes, such as message validation and proxying POST messages, can be implemented.
The text was updated successfully, but these errors were encountered: