The TIKI trail project is an immutable, distributed, record system for data transactions.
The design is inspired by traditional asset record systems, like property titles, birth certificates, etc. Where the asset itself is external to the record keeping system.
Traditionally these systems were immutable through paper (only 1 original), using physical signatures and notaries. Newer-age systems often employ blockchains to create digital immutability, streamlining costs, improving access, and time-to-finality. For traditional assets, like land, blockchain gas costs, and write times are more than sufficient.
But! With data as an asset, that doesn't cut it. There's always workarounds. Though scaling to trillions of records, often warrants a dedicated design. This is that.
For example, TIKI trail benchmarked at over 25,000 transactions per second per device (iPhone 12).
The TIKI Trail design utilizes two levels of immutability, first at the data layer and then at the storage layer. Records are created and digitally-signed locally using a blockchain-inspired data structure. This enables fast writes, with 0 gas costs, since records are single-party โusing zero-party data as a standard, the owner of the device creating the data is the owner of the data itself.
The chain of records is then backed up to one or more hosted WORM (write-once, read-many) repositories. The shared repository functions both as long term storage for device failure recovery, and as an index, enabling easy integration of records into backend services.
If you'd like to read more about the design, check out the original ๐ WHITEPAPER.md.
For most applications, we do not recommend using this project directly. Instead, use one of our dedicated native libraries for iOS, Android, Flutter, and Javascript.
Get familiar with our platform-wide ๐ docs, or jump right into the ๐ API reference.
- A Publishing ID. Get one for free at console.mytiki.com.
- A platform-specific secure key_storage implementation.
- A platform-specific implementation of CommonDatabase.
While technically this library can be used to create records of any type. We've simplified and abstracted the API. By all means, feel free to fork and create your own type(s).
- TitleRecord - describe a data asset and MUST contain a Pointer Record to the raw data (often stored in your system).
- LicenseRecord - describe the terms around how a data asset may be used and always contain a reference to a corresponding TitleRecord.
- PayableRecord - describe a payment issued or owed in accordance with terms of a LicenseRecord.
- ReceiptRecord - describe a payment or partial-payment in accordance with a PayableRecord.
InMemKeyStorage keyStorage = InMemKeyStorage();
CommonDatabase database = sqlite3.openInMemory();
String id = Uuid().v4();
String ptr = const Uuid().v4();
TikiTrail.withId(id, keyStorage);
TikiTrail tiki = await TikiTrail.init('PUBLISHING_ID','com.mytiki.tiki_trail.example', keyStorage, id, database);
TitleRecord title = await tiki.title.create(ptr, tags: [TitleTag.userId()]);
print("Title Record created with id ${title.id} for ptr: $ptr");
LicenseRecord license = await tiki.license.create(title, [LicenseUse([LicenseUsecase.attribution()])],'terms');
print("License Record created with id ${license.id} for title: ${license.title.id}");
tiki.guard(ptr, [LicenseUsecase.attribution()], onPass: () => print("There is a valid license for usecase attribution."));
tiki.guard(ptr, [LicenseUsecase.support()], onFail: (cause) => print("There is not a valid license for usecase support. Cause: $cause"));
The TIKI Trail project interacts with the following backend services:
- Storage - Writing backups to the shared WORM repository.
- Index - Search and fetch records using metadata.
- Registry - Sync user records across multiple devices.
The more, the merrier. Just open an issue or fork the project and create a PR. That's it to make the fancy table ๐.
Please follow the Code of Conduct.
Thanks goes to these wonderful people (emoji key):
Mike Audi ๐ป ๐ ๐ |
Ricardo Gonรงalves ๐ป ๐ ๐ |
Jurnell Cockhren ๐ป |
Harshit |
This project follows the all-contributors specification. Contributions of any kind welcome!