SQLite Mode P2P Local Network Only about icefiredb HOT 6 CLOSED

Thank you @koh-osug ​​for your interest and valuable suggestions. Below is a brief update on our current status and considerations:

1. CRDT Implementation:

   • Although the SQLite part has introduced the P2P network, the CRDT aspect has yet to be implemented. Your awareness of this has been documented and we have incorporated it into our roadmap for future development.

2. mDNS Integration:

   • Your suggestion about integrating mDNS is very good. Recognizing the importance of local network P2P communication, we plan to incorporate mDNS to improve our capabilities in this area.

3. P2P node authentication:

   • Node authentication is a key security consideration. Your suggestion to introduce pre-created keys for P2P identities and subsequent access rights checks is compelling. We are evaluating and considering implementation of this feature.

If you have any further questions or suggestions, please feel free to let us know!

from icefiredb.

1. What SQLite conflict resolution is right now use if not CDRT? If it is working it might be good enough.
2. Can I achieve a local network only mode by some other means? E.g. 0 bootstrap nodes?

from icefiredb.

1. Regarding synchronization conflicts in SQLite database scenarios, we are currently not using CRDTWe are currently building the IceGiant Project. The IceGiant project uses cosmos tendermint to build the blockchain layer. We integrate database write instructions into Blockchain transactions to ensure ordering of instructions and conflict resolution. But currently we have not set up icegiant as a public repository, I will contact you again when IceGiant is open source.
2. For local network scenarios, you can try to modify the node_host_ip address in the configuration file to the LAN listening address.

from icefiredb.

Without digging into the whitepaper:

• Is the blockchain approach a public permission less one?
• Is the consensus mechanism based on a leader?
• Is there a limit for the leader selection and communication overhead?
• How long does it take to finalize a transaction?
• I.e. can this be useful for local network installations?

from icefiredb.

• Tendermint can be configured as a public, permissionless blockchain.
• Tendermint uses a consensus mechanism called Practical Byzantine Fault Tolerance (PBFT), which does not rely on a leader but rather a round-robin proposer selection process.
• The leader selection and communication overhead in Tendermint is limited, as it relies on a fixed set of validators that take turns proposing blocks.
• The time it takes to finalize a transaction in Tendermint depends on the block time and the number of blocks needed for finality, which can be configured. Typically, finality can be achieved in a few seconds.
• Tendermint can be useful for local network installations where a reliable consensus mechanism is needed, such as in private or consortium blockchains.

from icefiredb.

Thanks

from icefiredb.