I wrote this issue to organize a few thoughts on the future direction of the BAMI repository. The repository did come up a few times in our discussions and meetings, yet there are no concrete plans on how we can proceed with this codebase. I believe with sufficient effort and focus, this repository can become instrumental in our labs' experiments.
BAMI essentially started as an implementation of Plexus and shifted towards being an “accountability toolbox”. The idea of Plexus, however, has changed significantly (both code-wise and conceptually) whereas this repository has remained untouched since last year. At the same time, I see an increasing need for a Python framework with distributed system data structures so we can quickly prototype any ideas that we would have.
Whereas IPv8 provides basic, yet very robust networking services, I would envision that BAMI provides developers with primitives to build decentralized applications. This would, for example, include commonly used data structures like:
Bloomfilters and its variants
Merkle trees/dags
Skiplists (?)
All implementations should be accompanied by representative unit tests. Unlike the policy with the Tribler repository, this repository can contain dead code or unused data structures.
Since BAMI builds upon IPv8, developers should be able to quickly combine these data structures with their customized overlays. BAMI would then also provide the following services:
Sophisticated methods for peer discovery and organization
Overlay peer services such as witnessing
Routing services
Compared to libp2p, we would avoid a monolithic library while at the same time provide an academic toolbox with primitives for P2P research. This approach would solve two problems:
Repository bloat: right now, we have many different repositories under the Tribler organization. TrustChain is integrated into the AnyDex market, making it hard to find. We should, for example, integrate TrustChain in BAMI.
Redundant engineering efforts: it is a given that future students will re-implement (parts of) our existing implementations, maybe because they are underdocumented or hard to find. A unified framework would hopefully address this issue.
I wrote this issue to organize a few thoughts on the future direction of the BAMI repository. The repository did come up a few times in our discussions and meetings, yet there are no concrete plans on how we can proceed with this codebase. I believe with sufficient effort and focus, this repository can become instrumental in our labs' experiments.
BAMI essentially started as an implementation of Plexus and shifted towards being an “accountability toolbox”. The idea of Plexus, however, has changed significantly (both code-wise and conceptually) whereas this repository has remained untouched since last year. At the same time, I see an increasing need for a Python framework with distributed system data structures so we can quickly prototype any ideas that we would have.
Whereas IPv8 provides basic, yet very robust networking services, I would envision that BAMI provides developers with primitives to build decentralized applications. This would, for example, include commonly used data structures like:
All implementations should be accompanied by representative unit tests. Unlike the policy with the Tribler repository, this repository can contain dead code or unused data structures.
Since BAMI builds upon IPv8, developers should be able to quickly combine these data structures with their customized overlays. BAMI would then also provide the following services:
Compared to libp2p, we would avoid a monolithic library while at the same time provide an academic toolbox with primitives for P2P research. This approach would solve two problems:
I would also like BAMI to support simulation, e.g., by integrating my discrete event asyncio loop.
Thoughts/comments? :D