Tree of responsibilities and RawData exchanges.

To explain my position on the RawData exchanges, I will need 3 comments.

This first one will define the basic functionalities to be delivered by the Common-Adapter.

As Common-Adapter, we need to provide a set of methods in order to interact from the UI with objects of type:

contracts
usages
settlements

by CRUD or actions endpoints.

So from the UI perspective, the Common-Adapter is the service responsible for the creation, storage, transmission, reception, and consistency of all of these resources.

Of course, the Common-Adapter would not be able to provide all of these functionality without the precious help of the services with which it can itself interact. But from the UI perspective, the Common-Adapter is a unified interface providing access to all of these features.

This second comment will try to define the tree of responsibilities of the whole of the solution that we are all going to deliver, through examples.

When the UI requests the Common-Adapter to create a Settlement from a Usage:

The Common-Adapter receives this request, performs some checks, and sends a request to the Calculation Service, in order to perform this calculation work on the basis of Discounts and Usages.

Once this result has been received, for its part, does the Common-Adapter recalculate the result it should have received, to check the content of the Calculation Service response?
No.
Why?
Because it is the responsibility of the Calculation Service to provide this data, and the Common-Adapter must in no case question the accuracy of the data returned by the Calculation Service.

When the UI requests the Common-Adapter to create a Discrepancy from 2 Usages:

The Common-Adapter receives this request, performs some checks, and sends a request to the Discrepancy Service, in order to perform this discrepancy work on the basis of home and partner Usages.

Once this result has been received, for its part, does the Common-Adapter recalculate the result it should have received, to check the content of the Discrepancy Service response?
No.
Why?
Because it is the responsibility of the Discrepancy Service to provide this data, and the Common-Adapter must in no case question the accuracy of the data returned by the Discrepancy Service.

When the Common-Adapter receive a contract from a partner:

The Common-Adapter download this document from the Blockchain-Adapter, performs some checks, use the RawData to create and store the received contract, in order to allow the UI to access this contract during its next requests.

Once some UI requests are received, for its part, should the UI verify the contract content from the RawData, to check the content of the Common-Adapter response?
No.
Why?
Because it is the responsibility of the Common-Adapter to provide this contract from RawData, and the UI must in no case question the accuracy of the data returned by the Common-Adapter.

Why create this mess in this tree of responsibilities, without any functional utility to do this action in the UI?

If the UI cannot trust the Common-Adapter about the returned contract, how could this UI trust the RawData field itself contained in this contract?

This third comment will try to detail my personal point of view.

I would suggest that Common-Adaptor exposes a new End Point to solve this issue: maybe an endpoint to verify that the content of a contract is equivalent to its RawData? or an endpoint to verify RawData content is the signed one AND the content of a contract is equivalent to this RawData?

I understand this Use Cases, and why they should be done.

But I don't understand the Use Case where the UI should validate this RawData in internal. RawData is data exchanged between the Common-Adapters of 2 partners, data that can be certified by the blockchain, signed, and potentially allow to recreate or validate the resources exposed by the Common-Adapter. But where is the need to do any of these actions in the UI? The UI should eventually be able to launch them, but that's all.

Once again, if it's done like this it's for the wrong reasons, adding mess, for no real need.

Thanks for sharing your point of view. From reading it, I got the impression that we have different understandings how software components or users interact with our BWRP components. And while I think it is good to discuss details individually we need to align our philosophies before we progress with the details.

Let me try to visualize my view of your understanding (philosophy 1): For two orgs X and Y we then have: X: user_X <-> UI_X <-> common-adapter_X Y: user_Y <-> UI_Y <-> common-adapter_Y And then an interaction between the two orgs: common-adapter_X <-> blockchain-adapter_X <-> blockchain <-> blockchain-adapter_Y <-> common-adapter_Y So the data integrity and blockchain is only between the adapters and after that abstracted away from the user.

In my view user_X and user_Y are interacting directly with each other and the blockchain (philosophy 2): All the steps in between are (mostly) there to help and make it easier as well as faster. Still, the users stay in control and are always able to verify the data with the ledger directly. Resulting in a system that has to be seen and build as a whole: user_X <-> UI_X <-> common-adapter_X <-> blockchain-adapter_X <-> blockchain <-> blockchain-adapter_Y <-> common-adapter_Y <-> UI_Y <-> user_Y Or without the helpers: user_X <-> blockchain <-> user_Y

If we do not see the case that our users are going to verify the data on their own we can think of legacy_system_X which does the the verification transparently for the user. legacy_system_X could directly store a copy of the private data and verify/compare it with the blockchain-data.

While I see that some of the shared/distributed ledger features had to be removed to fulfill privacy requirements of this project I would like to keep as much of them as possible to keep the advantages like security, integrity, provability and so on. With philosophy 2 the user could always run e.g. a blockchain-explorer, fetch the data as described in the wiki and verify it. Also, an additional client running in parallel could be used to check it. And this is not about distrusting the common-adapter but about transparency and having options.

If you take some dApps(e.g. Uniswap, Cryptokitties, ...) running on/with blockchain, most of them provide some UI which makes interacting with the blockchain/CC/smartcontract easier. Still, you always have the option to run your blockchain-client of choice and interact directly with the chain. Again, this is (for me) what blockchain is about. Having options, transperency, security, ...

If we go with philosophy 1, the user might not be even aware that he/she is using a blockchain-based system. Behind the scene could be even E-Mail, shared storage, ...

For me, it is quite important that the user is aware that there is a blockchain and (with some help) would be able to verify data with it in case it is needed. Otherwise, we use only a very small portion of the blockchains potential.

Most of our latest discussions regarding reverenceID vs. (local) contractID, payload validation, unifying raw and non-raw, from and to, ..., in my opinion boil down to the two philosophies described above.

Most of our latest discussions regarding reverenceID vs. (local) contractID, payload validation, unifying raw and non-raw, from and to, ..., in my opinion boil down to the two philosophies described above.

I totally agree. I think there is no real point to start diving into details those question immediately until we are on the same page from this high-level perspective, which you summarized as 2x philosophy .

as for our view, we take "crypto currency trading/exchange" as an example.

at the end of the day. The actual transaction happens on the respective network. (take Eth and BTC for eg). meaning, for you to now own say "extra" Bit Coin or Eth, a "transaction" will happen on the network.

Yes, fundamentally, a "user" can execute the "transfer" directly on the network. but for this to happen. the user would need to know all the technical knowledge to do so.

So, lets take a example. Coinbase https://developers.coinbase.com/api/v2#list-transactions

They have a "list" transaction API. These are "local" coinbase transaction. not Blockchain-transaction.

and you can see that the API do not specifically reference anything related to blockchain in the front end. But in the backend, all information are being stored.

for instance .you identify yourself as a local "userId", not your network wallet address. https://developers.coinbase.com/api/v2#user-resource

you then add/associate your wallet address using these api. https://developers.coinbase.com/api/v2#list-addresses

once they are associated. all other transaction will be "automatically" use the "information" from your "user profile"

They have API to send/receive money too. https://developers.coinbase.com/api/v2#send-money

So, Overall as you can see. Their API in generally do show much about blockchain, but doesn't mean they are not using blockchain in the back. https://developer.bitcoin.org/devguide/index.html

They just abstracted out the core Bitcoin API(and any other Crypto currencies ) into a Product.

And more importantly. Coinbase as an exchange then now Offers this as an Standard API where 3rd can also use these API.

For example, https://zabo.com/integrations/coinbase-api/ https://mint.intuit.com/blog/budgeting/how-to-add-coinbase-to-your-mint-com-budget-tools/

To put into perspective. Common-adapter = coin-base blockchain-adapter(s, one or more) = bitcoin.org, ethereum.org, etc etc. webui = Official coin-base App, (showing a "mobile" version as they are standalone. and will communicate to "coinbase" backend, most likey to the "common-adapter" layer)

and at the same time allowing 3rd "clients" to communicate with it.

Thanks for providing a detailed example for a "philosophy 1" application.

The Coinbase application is a classic application which focuses on trading "inside" the app. Meaning if I buy Bitcoins with e.g. EUR that does not create a ledger entry on the Bitcoin Blockchain. It only adds an entry in the local database of Coinbase. So I could use this application for it's main purpose(trading) without a blockchain at all. They only have (hidden) interfaces to blockchains and bank transfers to start the trading but we can not consider that as a blockchain/distributed application (in contrast to e.g. Uniswap).

So we still need to decide whether we want to have an application that is able to interact with some blockchains (P1) OR a blockchain application (P2) where we can leverage all positive aspects of distributed ledgers (transparency, traceability, security, efficiency, manipulation resistance, ...).

I also think that the analogy that Kong provided is a very good explanation of the two conceptual approaches. Using trading platforms brings a lot of comfort benefits to end users, but come with a security risk and limited transparency - there is a long list of events where people lost their assets because trading platforms were hacked or compromised. That's why it is so important to move assets from those platforms to e.g. cold storage. Only if you move your assets into your own wallet you have control, transparency and immutability - so the core benefits of blockchain technology (as long as you don't forget your private key). Are trading platforms convenient? Absolutely. Can you trust them? Well, it's complicated.

The fundamental idea of blockchain is to take out intermediaries from interactions and therefore the dependencies that they come with - remember the initial idea for coming up with Bitcoin was to get rid of banks and governments in the financial process. Now, leaving users with the responsibility to control private keys might also be risky, not from a technical, but more from an "every day life" perspective. So pure blockchain also might have drawbacks. In the end, technology needs to work in a human context, otherwise it is just a nice academic concept. For example, in our project, transparency is a problem when it comes to revealing business relations or contract details. That's why we came up with our own approach using off-chain communication in parallel to on-chain transactions which in the end brought us to the modular approach (which I think is really great by the way) that we have right now.

So in our case it boils down on how we balance pure blockchain approach with commercial requirements. And here the goal should be to use the benefits of blockchain and push the technology which the whole project is about to the boundaries of what's possible.

I think in our project, which is the first large scale project in the industry that shows the potential of blockchain, it is absolutely necessary that we utilise the basic concepts and benefits that the technology offers as much as possible: transparency, user control, decentralization, immutability. It's the only way to create a platform that people will trust.

From a technical perspective, there is no doubt that both philosophies lead to working solutions. But we must not underestimate the human factor: seeing is believing.

GSMA-CPAS / BWRP-common-adapter

Tree of responsibilities and RawData exchanges. #42