Hey S Thanks for your thoughts , I would like to start with defining this.
Public chains are immutable , that means we cannot delete once recorded that’s true but blockchain dB such as Bitcoin be EtH does not need to store any structured data that is revealed to public , instead it stored the ownership transfer but in cryptographic method so GDPR laws don’t apply since data is arbitrary Public chains are different in nature and may come to use later in different use cases but they are not subject to GDPR laws since you are not storing any data there so it does not matter. It's just a value transfer. Now private chains are like any other database with that you can imagine of but it’s inherently running on principle of encryption and its contains all public chain feature like immutability peer to peer communication and definitely if you end up storing some dB object like loan on your own private chain you end up coming under GDPR laws that is true but as I said private chains can be used for different use cases. One design pattern is to store all kind of commands that are happening over the system across all services and design they with a encrypted script and treat it like a single source of truth that has happened in the microservices , these services can communicate to understand the state of the system by just communicating with the DB and over this DB the services can request to delegate rights over other kind of DB I mean since the design pattern says that each service mapped to its own DB so why limit to one single DB Use of blockchain is different here. We should not store anything related to Loan or anything specific for maintaining the accounts, and can be used to execute smart contracts that's all and can act as a single layer for other services to communicate and share commands plus it can act as a secure rule engine. Banks are already experimenting with blockchain On Monday, September 27, 2021, Sander van der Heyden < sandervanderhey...@musonisystem.com> wrote: > Hi, > > While not being active on Fineract CN I do have a few thoughts to chip in > on the proposal to use a blockchain DB: This is not going to be acceptable > in any country (or company) that is subjec to GDPR. Blockchain and GDPR are > effectively counterparts due to the nature of the blockchain in which data > is immutable and therefore cannot be deleted, which contradicts with the > right to be forgotten in GDPR. > > We already see that more and more countries outside EU start implementing > similar concepts and where we frequently get questions around this topic, > this might not come in with smaller MFI's but regulated banks (and their > regulators) are clearly paying attention to this topics. Therefore I would > strongly advise to be very cautious in jumping onto these types of > developments without fully understanding whether it would not rule out the > project for substantial parts of the world. > > S > > > On Mon, 27 Sept 2021 at 08:23, Saransh Sharma <sara...@muellners.org> > wrote: > >> >> On Sun, Sep 26, 2021 at 2:54 PM Awasum Yannick <awa...@apache.org> wrote: >> >>> Hi Saransh, >>> >>> Right now, the most important things we need to do on Fineract are to: >>> >>> 1.) Upgrade the major project dependencies. >>> a.) Upgrade to Spring Boot 2 ( this is already in progress and >>> needs testing) . >>> b.) Upgrade from Java 8 to Java 11 (LTS). Java 17 is another LTS >>> version but we can do that later. >>> c.) Upgrade to a more recent version of Angular, say 10, 11 or 12. >>> How much effort do you think will be required for all these? >>> >> >> Honestly manually upgrading 40 repos is a daunting task don't you think? >> >> >> 2.) Deploy a Sandbox Environment for Testing Fineract CN. So the >>> community will have a demo environment for playing around and learning >>> about the new system. >>> 3.) Figure out how to Release Fineract CN. Myrle, Markus and Mark will >>> help us when we get here, they have a lot of experiences in that area. >>> Others will be available to help including Petri, Juhan, Mike, Aleks and >>> many others. >>> 4.) Write Documentation on how to host Fineract CN on major Cloud >>> Infrastructure. >>> 5.) Decide on how to host Fineract CN artifacts either using JFrog or >>> whatever solution is available out there... Juhan already did a lot of work >>> in that direction >>> >> I think this is where we have to put a lot of time artifacts are binded >> in single language, if we say that we stick to certain codebase always then >> it make sense are we sticking to such choice then we are always binded to >> such methods , now choice is do we want to move away from this? >> >>> 6.) With 5. in place, we can figure out a complete CI/CD environment for >>> auto deploying to the sandbox environment we defined in 2. above.. >>> ..... >>> >>> Why dont we add these also :: >> Why dont we retire some services from FineractCN and perhaps these >> services could be >> 1. Auth service instead use PKI and Public Key based AUTH that are >> already in use. or let people use whatever auth they like ? >> 2. Retire provisioner, and its supported libs that are like anubis >> If we retire some services and make the product light weight then we have >> a chance to quickly upgrade the project. >> >> This is going to be controversial:: Maybe we retire the DB support since >> sticking with one single DB could be problematic in the design patterns of >> the Microservices. (I know a lot will say what will happen to Multi-tenancy >> and migration) >> I think we could use a different kind of DB that just stores on log level >> and has inbuilt encryption like a blockchain DB ? >> >> There are so many things to do on Fineract CN. These are some of the most >>> important things which this community needs. We can start drawing up a road >>> map for these things and begin working on them. >>> As a community, we have not been able to achieve even a fraction of >>> these important goals over the past few years since the initial importation >>> of code into Apache Infra. Some powerful and forward thinking Orgs have >>> hard forked Fineract CN and are making progress and it has been successful >>> for them. This shows Fineract CN can work. Let's not abandon it, let's make >>> it better and even do an initial release of Apache Fineract CN before we >>> start talking about doing other things. We can build whatever blockchain or >>> smart contract solutions on top of the fundamental release. If we cannot do >>> the above as a community then we won't be able to do whatever you or >>> anyone else will propose. >>> >>> Why have we not been able to make progress with releasing Apache >>> Fineract CN? Why? That should be a question on our minds. >>> >>> Then once we have that then we can ask the community to roll features on >> top in their language by the support of generators in their lang choice and >> support >> >> Hey, Ronald and Awasum , this superset sounds good , let's do that. Here >> I am able to grant and support another 1500 USD to support this kind of >> development. >> >> Let me know if you guys wish to work together and make this a project >> workable and show it to the community. >> >> Thanks >> >>> >>> On Sat, Sep 25, 2021 at 4:23 PM Saransh Sharma <sara...@muellners.org> >>> wrote: >>> >>>> I hope this email finds you well, since Apache Con is over we can >>>> resume discussing the potential ideas and maybe fix some level of community >>>> established quorum on those ideas. >>>> >>>> Last year , we proposed several Architectural (this does not mean that >>>> we nuke existing work)changes in Fineract CN. We have learned >>>> >>>> 1. Make Fineract CN developers ready. (Through the use of tech like >>>> generators that allows the easy bootstrapping) >>>> 2. Implementing a consensus layer and script like a rule engine. >>>> 3. We should potentially explore ideas down distributed architecture >>>> also at the same time. >>>> 4. Moving forward on protocol level rather than API >>>> 5. Slowly phasing out or contributing on top of Fineract CN. How do we >>>> do that ? Like if we change something deep (maybe introducing another >>>> library that does most of the work and phase out the non-essential ) >>>> 6. Using smart contract rather than microsservices >>>> 7. Having a single source of truth (something like blockchain that can >>>> work for consensus and data protection) >>>> >>>> I would like to take this task, or probably hire a resource on behalf >>>> of a non profit foundation that can take this task ahead, collaborate with >>>> stakeholders and understand what are the ways we can potentially explore. >>>> >>>> This is not about code changes or a PR so please avoid sending emails >>>> like Open a ticket on JIRA (Yes yes we will do that but first let's come to >>>> a consensus which way we would like to go.) >>>> >>>> Please contribute over this thread and probably lets treat this email >>>> as information gatherer rather then jumping on the conclusion >>>> -- >>>> Thanks and regards, >>>> >>>> Saransh Sharma >>>> Research Partner >>>> >>>> This mail is governed by Muellners® IT policy. >>>> The information contained in this e-mail and any accompanying documents >>>> may contain information that is confidential or otherwise protected from >>>> disclosure. If you are not the intended recipient of this message, or if >>>> this message has been addressed to you in error, please immediately alert >>>> the sender by reply e-mail and then delete this message, including any >>>> attachments. Any dissemination, distribution or other use of the contents >>>> of this message by anyone other than the intended recipient is strictly >>>> prohibited. All messages sent to and from this e-mail address may be >>>> monitored as permitted by applicable law and regulations to ensure >>>> compliance with our internal policies and to protect our business. E-mails >>>> are not secure and cannot be guaranteed to be error free as they can be >>>> intercepted, amended, lost or destroyed, or contain viruses. You are deemed >>>> to have accepted these risks if you communicate with us by e-mail. >>>> >>> >> >> -- >> Thanks and regards, >> >> Saransh Sharma >> Research Partner >> >> This mail is governed by Muellners® IT policy. >> The information contained in this e-mail and any accompanying documents >> may contain information that is confidential or otherwise protected from >> disclosure. If you are not the intended recipient of this message, or if >> this message has been addressed to you in error, please immediately alert >> the sender by reply e-mail and then delete this message, including any >> attachments. Any dissemination, distribution or other use of the contents >> of this message by anyone other than the intended recipient is strictly >> prohibited. All messages sent to and from this e-mail address may be >> monitored as permitted by applicable law and regulations to ensure >> compliance with our internal policies and to protect our business. E-mails >> are not secure and cannot be guaranteed to be error free as they can be >> intercepted, amended, lost or destroyed, or contain viruses. You are deemed >> to have accepted these risks if you communicate with us by e-mail. >> >
