Hello Giorgio, have you seen this: https://github.com/lovesh/bulletproofs-amcl
and this: https://github.com/DSRCorporation/milagro-crypto-rust Cheers, Brian On 4 Jun 2019, at 18:30, Giorgio Zoppi wrote: > Now I have the meeting..i believe that go could be fine..we want to support > as well a rust library and a modern c++ library for interop with embedded. > Best Regards > Giorgio. > > On Jun 4, 2019 19:22, "Brian Spector" <[email protected]> wrote: > > Hi Giorgio, > > I’d like to propose that in order to accommodate your idea and others, > that reorganize the structure of the repos and, in general, how we > deliver our ‘product’. > > First, I’d like everyone to consider that the product we ship just be > called a ‘Milagro Server’. The other product we ship is crypto > libraries, like milagro-crypto-c, milagro-crypto-JavaScript and *-Java. > > The Milagro Server is multi-functional. So it can perform a number of > different security functions (MFA, custody, etc.) needed to secure > enterprises and decentralized systems. Each function has its own folder, > and subfolders that rationally reflect code organization along function, > language or framework. > > Using this concept, Giorgio’s suggestion below works: > > >> My idea is to separate the tests and in src in two separate folders >> and as >> well the python and ongoing cpp work. >> An possible structure, might be: >> *./src # source directory* > >> *./test # test directory./deprecated # deprecated stuff (in case of >> mfa-server) is not needed../src/cpp # c++ code./src/python # python >> tornado server./test/cpp # catch/gtest for c++ code./test/python >> # >> nose or current tests for python tornado server../examples # here we >> can > >> put an demos application.* >> >> *./docker # any docker description * >> >> *./build # any binary package (deb/rpm/exe)* >> The same structure can be thought for the library or something similar >> to >> Apache Mxnet since it is a project that supports multiple languages.. >> I will help to restruct any structure that come from this discussion. > > Of course, we could subdivide by git submodule, but I think that adds a > layer of complexity that might not be warranted. I’m sure @smihaylov > has thoughts on this subject. > > Giorgio, the latest code contribution we are going to make is a server > process built with Golang. But it should fit into this paradigm. > > I’m overdue on communicating our plans for incorporating a > distributed, immutable file systems and encrypted envelope transport > into the Milagro server, but am working on it tonight. > > I hope you like it and see the possibilities from this design in the way > we do. > > Brian > > > On 31 May 2019, at 19:58, Giorgio Zoppi wrote: > >> Dear all, >> i would like to begin the discussion of the proposal of the subtree >> mfa-server. >> My idea is to separate the tests and in src in two separate folders >> and as >> well the python and ongoing cpp work. >> An possible structure, might be: >> *./src # source directory* >> >> >> >> >> >> >> *./test # test directory./deprecated # deprecated stuff (in case of >> mfa-server) is not needed../src/cpp # c++ code./src/python # python >> tornado server./test/cpp # catch/gtest for c++ code./test/python >> # >> nose or current tests for python tornado server../examples # here we >> can > >> put an demos application.* >> >> *./docker # any docker description * >> >> *./build # any binary package (deb/rpm/exe)* >> The same structure can be thought for the library or something similar >> to >> Apache Mxnet since it is a project that supports multiple languages.. >> I will help to restruct any structure that come from this discussion. >> >> Best Regards, >> Giorgio
