Skip to content

Full Demo Scenario

Indika Piyasena edited this page Nov 23, 2018 · 21 revisions

Full Demo Example

We are going to demonstrate app3 requesting and consuming data from app1, and in the process modify some permissions to show how data access can be controlled by the user, thereby restricting access to their data. Additionally, we will be able to see how both the users and the app providing data will receive UNDs from the app requesting the data.

1. Initialise the system

First, open a few terminal windows. In the first terminal, if you haven't already, from the project root, bring up the Docker composition:


and wait patiently for the "System Ready" banner message to fly by...

2. Check user UND balances and permissions

Open a second terminal window, and get into the babel Docker container:

docker exec -it babel /bin/bash

Let's check a few balances:

babel balance user1 PW5KZ2g5KuwVw2QhjNGn9aBbiSGsf3uq5HTigWohM6P7H767kw3dx
babel balance user2 PW5JRx3hihCz33R9Tm9uTQGPJj7UFA54nUjcgGkq3PYBy5iQXTsCG
babel balance user3 PW5KfhcoCs5yV7wLTWWh97fZbf9jshHZL7vD9tQARfpCGVnDyA95t

They should be 20.100, 6.700 and 0.000 respectively (the systemtest ran some data request tests during the demo initialisation, so some users already have a UND balance)

Let's also see their default permissions (as per the demo config)

babel permissions user1
babel permissions user2
babel permissions user3

By observing some of the permissions, one can see that user1 has granted all the permission to the conusmers app2 and app3, whereas user3 has only granted some access to the app2 consumer.

3. Make an initial Data Request

We're going to start off by mimicking app3, requesting data from app1, using the default configuration in a fresh system. So, in a third terminal, run:

docker exec -it haiku-app3 /bin/bash

Followed by:

haiku fetch app1 app1-data1.dat

and finally:

haiku view app1 app1-data1.dat

Looking at the output from the view command, we can see that user1 and user2 have granted permission to app3, and their data is available. user3 however, hasn't.

4. Check user balances


babel balance user1 PW5KZ2g5KuwVw2QhjNGn9aBbiSGsf3uq5HTigWohM6P7H767kw3dx
babel balance user2 PW5JRx3hihCz33R9Tm9uTQGPJj7UFA54nUjcgGkq3PYBy5iQXTsCG
babel balance user3 PW5KfhcoCs5yV7wLTWWh97fZbf9jshHZL7vD9tQARfpCGVnDyA95t

again, should show that they have balances of 23.3333, 8.9333 and 2.2333 respectively, since app3 has generously paid user1 and user2 2.2333 UNDs each for their data.

5. Modify some user permissions

Let's now simulate user3 granting access for app3 to access their data in app1, while user1 has decided to shut off their data-tap, and revoke access.

In the babel Docker container, run:

babel modify_permissions user3 PW5KfhcoCs5yV7wLTWWh97fZbf9jshHZL7vD9tQARfpCGVnDyA95t app1 app3

The text interface will let you choose which schema to modify, and which columns to enable or disable. Choose the first schema, and choose the default settings (where all the columns are enabled). Then press 's' to send.

Next, disable all the permissions for user1:

babel modify_permissions user1 PW5KZ2g5KuwVw2QhjNGn9aBbiSGsf3uq5HTigWohM6P7H767kw3dx app1 app3

A similar text interface will appear. Choose the first schema, and disable each of the columns by typing their names.

These permissions are now batched on the app1 Haiku server. To execute the batch,

docker exec -it haiku-app1 /bin/bash

and run:

curl https://haiku-app1:8050/process_permission_batch --insecure

Finally, on the babel host, verify that the permissions have changed:

babel permissions user1
babel permissions user3

6. Make a new Data Request

With these new permission changes, let's simulate app3, requesting data from app1 again:

haiku fetch app1 app1-data2.dat

followed by

haiku view app1 app1-data2.dat

(note that we are saving data to data2 this time)

We can see this time, that data for user1 is no longer included, but data for user3 is. Also, user3 should now have a UND balance of 3.350. Running the babel balance commands for each user above, we can see that the balances for user1, user2 and user3 should now be 0.0000, 3.3500 and 3.3500 respectively.

7. Invalidate app3

Now, we want to invalidate an app within the Unification ecosystem to prevent it from having the ability to request data. Perhaps app3 has done something nefarious, and Unification think it should no longer be able to exchange data. Within the babel docker container, we can first see which apps are valid and invalid respectively, by running:

mother validapps


mother invalidapps

We can see that all three apps are currently valid. Next, let's invalidate app3

mother invalidate app3 PW5JN14rVAQ4oL19PREuJbDjbde6QfrRmWCXsoBq8866KdxvWYJSH

We should get a message stating the invalidation process was successful. This means that the invalidation has been written to the MOTHER Smart Contract, and all apps in the Unification ecosystem know not to provide data to app3. We can see this by running:

mother invalidapps

8. Attempt to Request data, using app3

Back in the haiku-app3 Docker container, we can attempt to run:

haiku fetch app1 app1-data2.dat

We should now get an error message stating that app3 is invalid according to MOTHER. app1 has received the data request from app3, and immediately calls MOTHER to check app3s validation status, before processing the data request. app1 can see that app3 is not a valid app, and therefore rejects the request without any further processing.

9. Re-validate app3

Perhaps app3 have mended their ways, and Unification decide to allow it to contribute to the ecosystem once again. We can simulate this, once again from the babel Docker container:

mother validate app3 PW5JN14rVAQ4oL19PREuJbDjbde6QfrRmWCXsoBq8866KdxvWYJSH

We can then go back to the haiku-app3 Docker container and rerun the data request to app1:

haiku fetch app1 app1-data2.dat

app1 should now process the request successfully.

10. Invalidate app1

Validation works both ways: an app providing data must also be valid according to MOTHER, and therefore the Haiku Node will also check whether or not an app it is requesting data from is valid, before requesting the data. Let's invalidate app1 - back in the babel Docker container, run:

mother invalidate app1 PW5JN14rVAQ4oL19PREuJbDjbde6QfrRmWCXsoBq8866KdxvWYJSH

Then, in the haiku-app3 Docker container, we can rerun the data request to app1:

haiku fetch app1 app1-data2.dat

The Haiku Node should reject the request before sending it to app1, since app1 is no longer valid according to MOTHER, and can therefore no longer provide data. The process can be reversed again, using

mother validate app1 PW5JN14rVAQ4oL19PREuJbDjbde6QfrRmWCXsoBq8866KdxvWYJSH