For the launch of TIKI SDK 1.0, we created an example app for each platform we support (iOS, Android, and Flutter). The example application simulates a mobile app sending user data to a remote server. Using the TIKI SDK, the app is capable of keeping track of user data ownership and corresponding user consent for the usage of this demo data source.

Upon starting the application, the initial "Try it out" screen is visible, consisting of two sections:

Wallet - Contains the user's wallet address on the TIKI blockchain as well as the Ownership and Consent NFTs.

Outbound Requests - Contains information about submitted requests. A green dot shows that the request had consent and was properly sent.

Wallet

The wallet is represented by a user's address on the TIKI Blockchain. The example app starts without any wallet created. To create a new one, the user needs to tap on "Create Wallet"; a new screen appears with a "+ new wallet" button.

Each device has a wallet for each user. In the example app, it is possible to switch wallets while using the application. This functionality is used to simulate SDK initialization on a device where the user has previously created a wallet or for multi-tenant applications. When a valid address (private key registered in the secure storage) is passed as an initialization parameter, the TIKI SDK instance is pre-loaded with the corresponding wallet. To switch wallets, the user simply taps on the wallet's address.

Ownership

The Ownership NFT is like a property title —it is the registration of the user's ownership over one or more datasets in the application. On the Try It Out screen, it shows the blockchain transaction id for the ownership registration. By tapping on the Ownership NFT ID, you can view its details:

Hash: The transaction id of the NFT
Source: The unique source identifier for the dataset
Contains: Tags describing the represented dataset
About: A description of the dataset
Origin: The application that generated the dataset

Consent

The Consent NFT contains the current user consent, represented by approved paths and uses for the dataset specified by its Ownership NFT. For the example app, the consent destination is composed of the request URL path, and the use is just the HTTP method for the request.

Hash: The transaction ID of the NFT
Paths: The paths where the data can be sent
Uses: The approved use cases for dataset
About: A description overview of the consent
Reward: An optional reward that the user will receive in exchange for consent
Expiry: The consent expiration date

To grant or revoke consent, a user just needs to hit the "toggle consent" switch. Requests are immediately blocked/allowed according to the consent status.

Destination

The destination where requests are sent, it defines the destination of the Consent NFT: the "path" is the URL, and the "use" is the HTTP method. If these values are changed, a new Consent NFT is generated to reflect the changes.

It’s also possible to change the frequency with which requests are sent —changing this value has no impact on the Consent NFT.

Body

Defines the body of the HTTP request to be sent. It can be any text value, but typically JSON formatted data is used for REST API requests.

Requests

A log of the requests sent by the app to the destination URL. A green dot shows a successful request (has consent). A red dot shows that the request was blocked for lacking consent.

Select a request to view the server response (if any).

Under the Hood

The example app demonstrates using the TIKI SDK to manage data ownership and data consent providing both user transparency and control.

Each implementation has its own quirk; check out our platform-specific guides to learn more:

The goal of the sample app is to help developers play with and learn how to implement the TIKI SDK. It represents a stripped-down use of the TIKI SDK; keep an eye on our blog, discord, and doc portal as we build out more complex examples.

TIKI 1.0 — Example app