floating item, lending & sharing network - fljota.network

Teaser PoC Hedera Token Service
2. Different Backend possibilities
3. Sharing User Flow
4. PoC RestAPI for HTS Interaction

Inspiration

The sharing economy has arrived in different areas of our lives. It is now normal to share a car, rent a scooter, couchsurf an apartment, share an office space, furniture or sports equipment as you need and pay as you go (PAYG).

Today, the majority of useful items is locked away in business-inventory or personal space, that is not accessible to external groups or single persons (without contracts and regulatory risk). Nowadays accessibility to the items you need to use is more important than owning and storing them.

Physical items should not be left unused. Every item has its purpose: The fljota.network handles sharing and resharing your personal and business items and secures a risk free sharing with anyone possible in just a few seconds.

What it does

The fljota 'item' network uses the Hedera Token Service to tokenize real world sharing assets. It fuels sharing and resharing in b2b, b2c, c2c and all possible b2c∞c2b scenarios.

Keep track of all your personal belongings in your item inventory.
Tokenize unlimited belongings with different styles of sharing-possibilities.
Share your items with others based on standard sharing contracts.
Ensure to handle risk insurance, resharebility, etc. built on decentralized systems.

All personal data is stored exclusively on your device. It will only be distributed to potential blockchain backends like Hedera Hashgraph via Hedera Token and Consensus Service, if you decide to securely share and reshare your stuff.

How it is built

The main concept of fljota's item inventory is the sharing handshake and the sharing contract. They are prototypically developed in an Elixir Pheonix Frontend, that is scalable to simultaneous handling of P2P devices. To bring things to a trustful backend and tokenize your real-world assets, you can choose the interconnection to any setup you like (*two different backend possibilities).

In three weeks of night sessions I've invested at Hedera21, I focused on a Restful Middleware (api.fljota.network) that handles experimentally some dimensions needed by the frontend. I decided to start with node.js RestAPI with Express and Swagger connected to HTS.

Step 0 - The new user can start directly via his prefered web browser, add (dummy) items to his personal inventory, share and return them to other people that are connected to the website. Not all parts are in the demo PWA, but you get the flow (*3. Sharing User Flow).

Step 1 - if you want to estimate the value of the tokens for your items and settle your sharing contract, you will need a third party. This is where you need access to Hedera Token Service. In order to easily create a new account, I generated a Hedera Credential Generator, that generates new accounts (createAccount) from the main fljota account. It serves them via JWT to the user. The encrypted JWT is stored as AccessToAccounts (xs2a) token in the user's browser.

Step 2 - with an existing account you can connect the API and start interacting with the Hedera services that are crafted in the Rest API. In the demo video you can see how a fresh JWT is passed to the API and e.g. returns the account's tokens connected to this account. With this basis, all the other dimensions of the RestAPI can be addressed. Not all routes are fully connected yet, but it gives a teaser of what should be possible. (*4. PoC RestAPI for HTS Interaction)

Step 3 - Now users can tokenize their existing items. After selecting one local item it is possible to pass some evaluation data to the tokenizing service. The new item tokens are associated to the user's account and set how they are configured. This part of the demo is quite mocked up, but it gives a feeling of what should happen.

Step 4 - When two or more users share items, they want a contract in a sharing environment, decide to whom they want to restrict their items, set a value, deposit and verify that they will receive everything in a quality they can accept. This is where the sharing contract comes in, which is handled by a mocked service (3 weeks of night sessions are not enough to complete the whole project ;-D).

Step 5 - Requesting and ReSharing the items is the final part of the process. When an item is set to reshareable it can float free in the sharing network and the deposit token transfers from user to user - the real item token stays in the ownership of the real owner - the deposit token marks possession and gives the owner the possibility to request back his floating item, when needed. The handling of value and deposit token is maintained in the smart contract, which will be evaluated if generated colored tokens can be transferred via SC.

Step 6 - At the end the systems approach is to minify the users interaction to unknown blockchain and token terminology.

In Simple Words: The user can track all his personal items - basically no backend needed. The user can share his items with others and track who possesses his items - basically between two devices, but also trustfull via tokenization values. The user can tokenize every item with a value that can be verified by other - API Needed The user can securely share his item with known and unknown parties - item token and deposit tokens are associated and handled in the smart sharing contract. The user can ensure receiving his item or at least the deposit token which is associated with the tokens deposit. The business can share its items to a restricted group of people. The business can qualify and ensure deposit and KYC processes. The user can participate in sharing items to business sharing and returning a sharing fee. ...

Challenges

Token Interchangeability - in my sharing item concept it is not clear, if the TokenAssociateTransaction() can be verified to different provided colored tokens. If a user creates a new token from his personal account, every transfer to sharing partners must be associated with the owner's item token. In the worst scenario, one user account needs to be associated with hundreds of tokens. The other possibility would be to mint tokens (TokenMintTransaction()) from a centralized account and associate these tokens globally to all fljota users - but this undermines my decentralized option of this system.

Deposit Token - one idea was to generate a deposit token equivalent to the verified value. Unfortunately I cannot create a concept of the full refund process via TokenWipeAccountTransaction() or Treasury Account. There is still some work to develop the refund of another account's token back to the owners account without use of smart contracts. One other idea is to value the deposit token in hbar equivalent Euro value, which was not part of the concept in the hackathons backend.

Sharing Contract Restriction for hbar - if I got it right, it is not possible at this point of time to transfer colored tokens via Hedera Smart Contracts. This would imply that I need to arrange all sharing contract dimensions in my API, which gives up one main idea of 'real' smart sharing contracts. Perhaps this is solvable with hbar instead.

Securely storing JWT Credentials via WebCrypto and Serviceworker - I have learned a lot about securely storing credentials in the browser, but there is still the fact that the user needs to securely store his private key or all credentials in another place. In this demo it was sufficient to use encrypted localDB and CORS Protected localstorage, but that might be a security issue.

Admin Key / Minting Key - perhaps it would be a good idea to store admin and minting keys in a 3rd party service. This was not part of the concept, but when users start tokenizing different kinds of items, there must be a safe space to retrieve admin, freeze and minting keys, as the user needs enough knowledge to handle this part

Accomplishments to be proud of

YEAH! Learned a lot about all the provided services but also about the restrictions I now ran into.

The best part is, that it is now possible to tokenize your local items stored encrypted in your smartphone browser local storage / localDB to Hedera Hashgraph. I wish I had more time for the real functional demo of the detailed process, but now I have an idea how to approach the next steps...

What we learned

Swagger Dokumentation in node.js Token Generation / Association / Restriction / Abstraction Interoperability to other Backends and Blockchains

What's next for floating item, lending & sharing network - fljota.network

Rough Roadmap

Completing Sharing + Receiving Demo Simplifying the Process via a fljota.handshake with Sensor Quaternion Settling a Sharing Contract 3 Demos in Hedera Services