<div dir="ltr"><div>Hi everyone,</div><div><br></div><div>I initially sent emails elsewhere until I found this list. I am copying them here. The comments are in relation to an IBM Article from IBM India in 2019 to be found at</div><div><br></div><div><a href="https://arxiv.org/pdf/1903.01919.pdf">https://arxiv.org/pdf/1903.01919.pdf</a></div><div><br></div><div><br></div><div>"<br><div>Yes, Ben, I am searching for multi-master replication solutions, 
but with a difference .. the idea is to allow automated Trust to be 
developed on a database system by doing away with your standard single 
superuser system on bucardo and replacing it with multiple bucardo masters on top 
of multiple substrate masters..</div><div>My idea is to copy IBM's 
research and to build-in a consensus-seeking solution for the proposed 
multi-master bucardo system. The consensus being sought is intended to order 
transactions appropriately before final committing..Please refer to the 
previously attached IBM research paper"</div><div><br></div><div>"<br><div>Sorry to carry on before receiving any response, but I have been thinking about how to implement these Automated Trust ideas.</div><div><br></div><div>If
 there were as many bucardo servers as there were base-level database 
servers, and each bucardo server were configured to only replicate from 
changes on its own (base) database server, then the problem would reduce
 to obtaining consensus (per transaction "block") from all bucardo 
servers as to the order in which the executed transactions are to be 
committed. The Consensus Algorithm outlined in the IBM paper, is given 
in sufficient detail to reproduce on bucardo (I claim!)<br></div><div><br></div><div>I am now thinking I should look at your github site.</div><div><br></div><div>From
 our point of view as Enterprise Application developers and operators we
 are looking toward customers such as those companies involved in Supply
 Chain operations which require smart contracts you can implement on 
postgres databases, if bulk data is involved. Also we intend to provide 
distributed applications in non-internetworked areas eg Real Estate 
Agencies, NGO Housing Providers, Conveyancing etc. We organise our 
customers by "Member Class" meaning they would share IT "Mission" and a 
lot of activities daily (as far as what was actually done during the day) and fit into the same business network (if 
internetworked at all). One member Class per database server. Operated 
by a consortium-employed operator - a consortium of Members (Companies) in the 
Class. Our only involvement as a player, is to have the numbers of users etc etc 
reported monthly for Billing purposes. The idea that nobody has to trust
 anyone else during daily operations is attractive. Member Class 
Operators are being kept honest by the nature of the system, as are we. 
That is why I am hoping we can somehow organise an adaptation to bucardo
 for these purposes.</div><div><br></div><div>It is worth noting that we
 are looking towards the Elastos Blockchain with its "Carrier" security 
system for web communication as the provider of "Distributed" Id's to 
allow signing of every transaction securely The only thing in the IBM 
agenda of shortcomings of databases (from the point of view of a 
Blockchain) is how can we make a PLpgSQL function as "deterministic" as a
 transaction on a blockchain? We could also possibly utilise the 
insurance of Elastos to check the database for integrity (as, if more 
than 50% of bucardo servers were somehow caused to act fraudulently in 
concert, Trust would be destroyed).<font color="#888888"><br></font></div><font color="#888888"><div>"</div><div>We think this is a very attractive idea of IBM's and feel that bucardo could play a role in its development. bucardo would act both as replicating agent as well as ordering agent.<br></div><div><br></div><div>John Olsen</div><div>IT/OT Chain & Cloud Australia<br></div></font></div></div></div>