But I think we need clarity on what cc-node is intended to be. A federated ledger, and one that can be used, vanilla, under a wide variety of policy and use-case regimes.
The original design was to provide a suite of microservices (it's all documented), to preserve the maximum flexibility.
The ledger service was described as 'the diamond' in an attempt to capture the intent to produce a simple-as-possible transaction recording engine. Ideally, one that could be fully verified (mathematically provable, like a smart contract).
Such an engine ideally has zero configuration options. Immutable, like a diamond. One of those services you confirm the hash of before installing
Policy decisions as to validity of a transaction must therefore happen elsewhere.
Any real world service using CredCom ledger should be able to operate any policies not inconsistent with the way a CredCom ledger works. To maximise the applicability of CredCom the ledger needs to impose the smallest, least constraining set of conditions required.
So, policy can live wherever an instance designer chooses. The ledger just needs to faithfully record validated transactions.
In the Credit Coop case, I 100% agree that the UX is a bad place for policy.
I also need to say that duplicating policy operations in the same system should never happen - fundamentally an unsound architecture where inconsistency is bound to creep in. The microservice approach theoretically allows calling services on a hypothetical basis for things like pre-flight checks.
I think there is a strong case for making a validation engine as a service within the CredCom suite of services. I know that Matthew has built such a thing but at this point I don't know enough about the architecture to comment further. Meaning that, for instance, I don't really know what is meant by 'CC-node'.
Probably only Billy and John Gray have had/taken the time to acquire such knowledge
Which suggests to me, that - perhaps when there has been some initial work on documentation - we ask Matthew to do a presentation on the architecture of the reference implementation.
At which point I think discussions will be productive.
On Wed, Oct 4, 2023 at 09:08, Miles Thompson @.***(mailto:On Wed, Oct 4, 2023 at 09:08, Miles Thompson < wrote:
@utunga approved this pull request.
TBH I don't fully understand all the implications of this code but it LGTM
👍
Raised a discussion over in the protocol working group discussion CredComSoc/ProtocolWorkingGroup#16 about the pros and cons of putting business logic like this up in the top of the UX layer
The topic definitely is worth airing.
But I think we need clarity on what cc-node is intended to be. A federated ledger, and one that can be used, vanilla, under a wide variety of policy and use-case regimes.
The original design was to provide a suite of microservices (it's all documented), to preserve the maximum flexibility.
The ledger service was described as 'the diamond' in an attempt to capture the intent to produce a simple-as-possible transaction recording engine. Ideally, one that could be fully verified (mathematically provable, like a smart contract).
Such an engine ideally has zero configuration options. Immutable, like a diamond. One of those services you confirm the hash of before installing
Policy decisions as to validity of a transaction must therefore happen elsewhere.
Any real world service using CredCom ledger should be able to operate any policies not inconsistent with the way a CredCom ledger works. To maximise the applicability of CredCom the ledger needs to impose the smallest, least constraining set of conditions required.
So, policy can live wherever an instance designer chooses. The ledger just needs to faithfully record validated transactions.
In the Credit Coop case, I 100% agree that the UX is a bad place for policy.
I also need to say that duplicating policy operations in the same system should never happen - fundamentally an unsound architecture where inconsistency is bound to creep in. The microservice approach theoretically allows calling services on a hypothetical basis for things like pre-flight checks.
I think there is a strong case for making a validation engine as a service within the CredCom suite of services. I know that Matthew has built such a thing but at this point I don't know enough about the architecture to comment further. Meaning that, for instance, I don't really know what is meant by 'CC-node'.
Probably only Billy and John Gray have had/taken the time to acquire such knowledge
Which suggests to me, that - perhaps when there has been some initial work on documentation - we ask Matthew to do a presentation on the architecture of the reference implementation.
At which point I think discussions will be productive.
Dil
Sent from Proton Mail for iOS
On Wed, Oct 4, 2023 at 09:08, Miles Thompson @.***(mailto:On Wed, Oct 4, 2023 at 09:08, Miles Thompson < wrote: