Hey Myrle, Following the fineract CN architecture we can take the fineract-CN-template and perhaps break that template in pieces and through a step b step wizard or command line generate the boilerplate.
Like service , api, like test and in fact domain and entity also with supplied set of auth lib Now, my suggestion is that what are the libs that you personally think we can remove? So that the size becomes smaller? Another thing you can highlight are the essential things that we cannot remove . For example, can we definitely move away the crypto lib? There are much better libs out there that we can include? Another example is to maybe move provisioner service , I mean don't you think that services can do these provisioning and declare them as part of env when in the run time as like a config? Identity makes sense , but I would like to ask you if there are other written libs that are more mature and open source that one might or would like to use. Why supply an identity service? Is there a license issue in using other services ? Service-like rhythm makes sense but don't you think each service could send a message through some kind of command approach ? Like maybe we could use commands for that ? Please help us understand this , this way we can put back and maybe learn a few things. On Mon, Sep 27, 2021 at 9:05 PM Muellners ApS <an...@muellners.org> wrote: > This is not going to be acceptable in any country (or company) that is > subject 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. > > >>>>Please read the below cited European Union's study, dated July 2019 > > > https://www.europarl.europa.eu/RegData/etudes/STUD/2019/634445/EPRS_STU(2019)634445_EN.pdf > > "The study has concluded that *it can be easier for private and > permissioned blockchains to comply with these legal requirements as opposed > to private and permissionless blockchains.* It has, however, also been > stressed that the *compatibility of these instruments with the Regulation > can only ever be assessed on a case-by-case basis*. Indeed, blockchains > are in reality a class of technologies with disparate technical features > and governance arrangements. This implies that *it is not possible to > assess the compatibility between 'the blockchain' and EU data protection > law*. Rather, this study has attempted to map various areas of the GDPR > to the features generally shared by this class of technologies, and to draw > attention to how nuances in blockchains' configuration may affect their > ability to comply with related legal requirements. Indeed, the key takeaway > from this study should be *that it is impossible to state that > blockchains are, as a whole, either completely compliant or incompliant > with the GDPR. Rather, while numerous important points of tension have been > highlighted and ultimately each concrete use case needs to be examined on > the basis of a detailed case-by-case analysis.**"* > > "The second key element highlighted in this study is that whereas *there > certainly is a certain tension between many key features of blockchain > technologies setup and some elements of European data protection law*, *many > of the related uncertainties should not only be traced back to the specific > features of DLT.* *Rather, examining this technology through the lens of > the GDPR also highlights significant conceptual uncertainties in relation > to the Regulation that are of a relevance that significantly exceeds the > specific blockchain context*. Indeed, the analysis has highlighted that > the lack of legal certainty pertaining to numerous concepts of the GDPR > makes it hard to determine how the latter should apply to this technology, > but also others. This is, for instance, *the case regarding the concept > of anonymous data, the definition of the data controller, and the meaning > of 'erasure' under Article 17 GDPR.* *A further clarification of these > concepts would be important to create more legal certainty for those > wishing to use DLT, but also beyond and thus also to strengthen the > European data economy through increased legal certainty*." > > "It is on the basis of these observations that the study has formulated > three broad policy recommendations, which have been broken down into > various elements. First, it was suggested that > > 1. regulatory guidance on the interpretation of certain elements of the > GDPR when applied to blockchains should be provided to generate more legal > certainty in this area. > > 2. Second, it was recommended that codes of conduct and certification > mechanisms should be encouraged and supported. > > 3. Third, it was recommended that funding be made available for > interdisciplinary research exploring how blockchains' technical design and > governance solutions could be adapted to the GDPR's requirements, and > whether protocols that are compliant by design may be possible." > > Blockchain as a means to achieve GDPR objectives! > > Further, The EU's central bank had also invited suggestions on Central > Bank Digital Currencies (last year), announcing an effort, set for a 3 > year program right now, including other global efforts like that of the > Reserve Bank of India and China's Central Bank's effort. > > Read more about EU's effort here: > https://www.eublockchainforum.eu/sites/default/files/reports/CBDC%20Report%20Final.pdf > Why have we not been able to make progress with releasing Apache Fineract > CN? Why? That should be a question on our minds. > >>>>Awasum, thanks for putting effort on this thread. That's a good > question indeed, I love your spirit. CN is not being abandoned! > > On Mon, Sep 27, 2021 at 5:26 PM Awasum Yannick <awa...@apache.org> wrote: > >> Hi Saransh, >> >> The Fineract PMC or Committers do not pay anyone here to do development >> on the Fineract codebase. The PMC does not manage a budget for developing >> Fineract. We are all volunteers here and contribute as individuals not >> companies. >> >> If you want to hire a Developer to do work on Fineract, then you have to >> manage that outside of Fineract. Hire someone at your foundation and define >> their role and get them to fix issues if you like. But they have to fix >> issues which the community wants and needs. >> >> If you want to do any of the tasks which I highlighted in my >> earlier email then go ahead. If you want to rewrite Fineract CN or Fineract >> CN, then fork the project and call it a different name and take the >> discussion to another forum and leave the majority of people here who >> believe in Fineract CN to stay on. You can even create your own new Apache >> Project if that is what you want.. Apache Incubator is there to guide you. >> >> The community at this time does not want to change the language, >> framework or architecture of Fineract CN at this time. We want to test, >> improve and release what is already available. >> >> >> >> On Mon, Sep 27, 2021 at 4:13 PM Saransh Sharma <sara...@muellners.org> >> wrote: >> >>> I don't know what this email means. I am not asking you to enter in any >>> kind of business with me? It's a grant Myrle, I mean it's not a typical >>> business transaction. Grant from a non profit that could help developers >>> and contributors to work together nothing else ,I am not going to influence >>> anyone in any way. >>> >>> Actually zero trust protocol aka Blockchain does help in such >>> transactions by the way , the idea that we need to trust someone is already >>> flawed in many ways. >>> >>> I neve dismissed Sander; he raised an interesting point but I >>> highlighted why the point is no longer valid. >>> >>> Banking the unbanked by also a solution that the unbanked cannot manage >>> or use , that is what we are trying to solve. >>> >>> >>> >>> On Mon, Sep 27, 2021 at 7:46 PM Myrle Krantz <my...@apache.org> wrote: >>> >>>> So much wrong here, I'm just gonna skip to the end. >>>> >>>> On Mon, Sep 27, 2021 at 3:09 PM Saransh Sharma <sara...@muellners.org> >>>> wrote: >>>> >>>>> Ok , understood we can put more fire power once we get this rolling, >>>>> but if you look at the work I asked was to develop the Proposal not actual >>>>> development, think that's a lot ? >>>>> >>>> >>>> Saransh, I do not trust you, and won't be entering into a business >>>> relationship with you already for that reason. But even if I did, your >>>> management approach here is completely wrong: you are trying to replace >>>> intrinsic motivation to bank the unbanked, or build a software architecture >>>> I can believe in, or (equally valid) build a business that I can own. You >>>> are trying to replace that intrinsic motivation with extrinsic motivation >>>> of $1500 and <handwave> blockchain. (Which, given the way you dismissed >>>> Sander, you clearly don't understand either.) I shouldn't need to tell you >>>> that that is... unlikely to lead to your own success. The people here have >>>> earned more dignity than that. >>>> >>>> Best Regards, >>>> Myrle >>>> >>> >>> >>> -- >>> 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. >>> >> > > -- > Ankit > Managing Partner > Muellners ApS, Denmark > > Impressum- Muellners® Inc; Copenhagen, Denmark CVR: 41548304; > New Delhi, India CIN: U72900DL2019PTC344870; Foundation EU CVR:41008407 > > 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.
