<div dir="ltr"><div>I have decided to shut down all github repositories and we are moving to Atlassian Bitbucket</div><div><br></div><div>Therefore the new url is</div><div><br></div><div><a href="https://bitbucket.org/itotcca/bucordo/src/master/">https://bitbucket.org/itotcca/bucordo/src/master/</a></div><div><br></div><div>This remains a public repo.</div><div><br></div><div>John<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 11, 2022 at 11:23 AM John Olsen <<a href="mailto:john@itotchaincloud.com.au">john@itotchaincloud.com.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi,</div><div><br></div><div>I have established a forked repository for my project "Bucordo".</div><div><br></div><div>It is at</div><div><br></div><div><a href="https://github.com/john-itcsolutions/bucordo" target="_blank">https://github.com/john-itcsolutions/bucordo</a></div><div><br></div><div>Cheers,</div><div><br></div><div>John.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 4, 2022 at 11:51 PM John Olsen <<a href="mailto:john@itotchaincloud.com.au" target="_blank">john@itotchaincloud.com.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Once again,</div><div><br></div><div>I'm not exactly as expert as some in Perl and Postgres, however I am prepared to do as much as I can to achieve this goal and to "open source" it.</div><div><br></div><div>The use of the Elastos Smartweb blockchains and system is our company idea and need not be carried across (at least I don't think so) to general usage.</div><div><br></div><div>Anyone interested?</div><div><br></div><div>My linkedIn is: <a href="https://www.linkedin.com/in/john-lloyd-olsen/" target="_blank">https://www.linkedin.com/in/john-lloyd-olsen/</a></div><div><br></div><div>John<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 4, 2022 at 11:25 PM John Olsen <<a href="mailto:john@itotchaincloud.com.au" target="_blank">john@itotchaincloud.com.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi,</div><div><br></div><div>On reading through the "bucardo" file on github, I can see that my ideas would mean fundamentally altering Bucardo.</div><div><br></div><div>If these ideas gain any creedence here, I am proposing to create a new adapted package called "Bucordo" to reference the idea of an ordering process (the transaction ordering to form a block, that will be necessary) but to relate to bucardo, still, as an ancestor.</div><div><br></div><div>John.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 4, 2022 at 10:18 PM John Olsen <<a href="mailto:john@itotchaincloud.com.au" target="_blank">john@itotchaincloud.com.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi once more everyone,</div><div><br></div><div>You may be wondering how we get "Automated Trust" from such an arrangement.</div><div><br></div><div>It appears to me we would have to insist that database administrators as much as developers be denied permission to write anywhere to the production databases and that we provide (as ITOTCCA) only ways for client devices to update the database including signing up new customers and creating new member-classes (performed by ITOTCCA's own database node (our own member-class) servers via our own client devices). In this way each transaction can be signed with an Elastos-created DID and therefore becomes "Non Repudiable".</div><div><br></div><div>John Olsen</div><div>IT/OT Chain & Cloud Australia<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 4, 2022 at 11:52 AM John Olsen <<a href="mailto:john@itotchaincloud.com.au" target="_blank">john@itotchaincloud.com.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi again</div><div><br></div><div>I have been thinking further on this subject.</div><div><br></div><div>It appears it would be essential to organise inter-master replication via the Bucardo masters so that an event originally may occur on base-server-0 then it would communicate with bucardo-server-0 which would communicate with every other bucardo sevrer, which would then cause their own base-servers to be updated, and some time after this, enter into an ordering process (between the range of bucardo-servers) of a Block of transactions for committal. In this way bucardo servers only update "their own" base-servers unless the bucardo server is updating other bucardo servers on behalf of the base servers.</div><div><br></div><div>John Olsen</div><div>IT/OT Chain & Cloud Australia<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jul 3, 2022 at 2:31 AM John Olsen <<a href="mailto:john@itotchaincloud.com.au" target="_blank">john@itotchaincloud.com.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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" target="_blank">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>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>