User story:

As a user I don't want app has eat the all available device space
As a user I feel comfortable when app takes from 25 to 120 mb on the device

Tech details:

Put the limit on the cache. Let's say 50 transactions for this stage.
Apply obfuscation tools to minimise app size on the device.
Explore other tools to put app size on the device within required constrains.

Steps to reproduce:

1. Login into account on the mobile device
2. Register some offers
3. Register at least one demand (at this stage demand is visible on the screen)
4. Delete the application
5. Install the application again
6. Login into the same account on the mobile device

Expected behaviour:
All registered offers and demands are visible on the profile screen

Observed behaviour:
All registered offers are visible. Registered demand is not shown. Attempt to register the same demand will lead to error message from the backend "The same demand for this profile already exist".

Extra notes:
The issue is noticed after recent refactoring and migration to WorkManager.

Part of [feature] Integrate ethereum chain module into the main app #13

User story:

As a user I want to be able to remove item from my offers

Tech details:

This functionality has been implemented already. However since ongoing integration with on-chain operations it should be extended to support ethereum part of the app.
Ethereum ERC721 standard allows to burn() a token. Project implementation of ERC721token standard also allows to make token offer outdated. I believe burn() option would be the best fit for this use case.

Description

This information-only issue to track gained knowledge with struct related issues in the web3j. There are grown number of known issues in web3j which required to be written for the history.

web3j-cli autogenerate contract wrapper issue

I had issues to autogenerate wrappers for my contracts. Here is an opened issue. After the latest web3j-cli release I am able to generate wrapper for SwapValue.sol, but not for SwapChain.sol. Possible root cause is this contract uses struct with solidity address field. This post claims struct with address field is not supported yet by web3j.

RPC call from a mobile client with struct as an input param issue

When I do a call from a koltin code with a help of web3j to a solidity code, data in struct field is different from I have sent, e.g. valueOfTheFirstUser contains address of the user instead of expected tokenId and vice-versa.
I have test coverage for this logic in type-script test and it works fine. Also I have a similar scenario in another contract and it works fine. The difference between struct input params in this two scenarios is the first one contains address field.

That's all for now.

User story:
As a user I share with others what I can offer

Tech side:
We have to pass this data on the server and request it from server each launch. Synced data with server is a single source of truth. Due server-side works are postponed till mobile client readiness, we will use mocks as server responses, e.g. add an interceptor on network layer and hijack requests to mock the response.

Tech description:

At this moment chain's nodes are deployed on the local VM and startup partly automated over bash script. Consider to migrate this to docker as a more modern virtualisation solution.

To explore container's filesystem:
docker exec -it swap-database-default bash

To build images in inner dockerfiles:
docker compose up --build (-d flag is optional to run command as a daemon)

Tech description

Changes in DTO objects currently leads to several bugs. The root cause is some project layers work with unprocessed input param from the upper layer and changes in design of this object are not always followed by changes in the rest other places. Follow-up this places, e.g. profile model layer, to work with business domain object instead of raw params from the web request.

User story:

As a developer I want to easily deploy and scale up infrastructure, preferably in 1-3 clicks.

Tech description:

Bash and npm scripts helped a lot with automatisation of the process. Planned migration to Docker compose should help go even further with automatisation of the whole ecosystem. Although, it is already known Docker is not a virtualisation technology and could not be considered as a full replacement of the VM. It breaks isolation environment for some cases, e.g. db volume mapping, which may be crucial for such tasks as a private chain deployment.

Ansible is not a virtualization or a containerization technology at all, but it is still automatisation tool which might be more handy in some cases rather than docker compose. The aim of this task to explore the Ansible capabilities and, in the positive case, define steps to utilise the Ansible for project.

Current important task is orchestrate private chain nodes with secure way of passing passwords,

At the first iteration there is no limit how much rows server get from db and send to the client. In version that should be available for public usage amount of selected rows per requested should be limited (~30).

Current implementation has signs of previous engineering decisions. It should be cleanup.

Make common error cases such 'no network' or "timeout exception" more direct, more expressive to the end user.

This two cases should be distinguished.

Both cases should tell user "There is no connection to the internet. Are you connected?" or "There is no connection to the server. Try again later. If often repeats please contact the developer."

User stories:
As user if my device has wifi or cell network turned off I see the error message "There is no connection to the internet. Are you connected?"

As user if my device trying to send request to the server within a minute without positive result I see the error message "There is no connection to the server. Try again later. If often repeats please contact the developer."

Add authorization over auth tokens - basic 64 was a temporal version just to avoid passing credentials as clear text.

It might be jsonwebtoken

User story:

As user I want my operations with the platform to be tracked both on ethereum chain and the web backend.

Tech details:

This chain module is already integrated for this part functionality. I don't like how it had been implemented, this solution could be called clever and likely it would be refactored. Integration test is ready.

User story:

As a user I want to have the most relevant matches by my demand

Tech description:

The initial idea was to:
-- always polls chain by schedule or on each register demand for potential match to execute swapNoParams (= chain record, database record)
-- always pools chain by schedule for Swap event and update database records (= record in database)

However, at this moment, another solution is implemented. If you create potential match on each time when any users registers a new demand it would solve this and outdated data issues:

• When you register a new demand there are no yet existing matches and the match table wouldn’t have a new entry. When another user register a new demand, there is a match and it would be added to the table. No duplicates.
• When a new demand has been added and search for matches is run, there is no way the PotentialMatches table would have some of existing matches. Any new registered demand would do a whole db search for existing matches and add it to the table. As the ‘no duplicates’ issue has been solved it asserts there would not be any duplicate missed.

Potential sharding would break this schema, but at this moment it is considered as premature optimization.

This task remains open until integration test would be ready and app will pass it.

For more details please check tech documentation on GDrive.

User story:
As a user I can contact another person who matched my demands by his services

Tech side:
We have to extend the profile with contact option, e.g. cell phone. Shall we share it with others users or use server as a proxy in communication?

Tech description:

All work on features is done in the separate branch. When integration will be ready, it should be merged back to the master branch.

Consider to write a whole use case integration test before merge, if it would not be done till this moment.

User story:

As a user I want to receive match between my demands and available offers from others who also needs things I am offering on this platform

Tech details:

V1 version did matching on the contract level. This solution requires a lot of gas which force us to minimise operations on-chain to the most valuable ones. V2 version utilise blockchain feature of unreversible storage records, but keep the most time consuming operations like find matches on the server. When user wants to receive all matches, data from the chain and the backend's db should be combined in single result set.

It should be double checked, but all chain data should be already on the backend and the SQL query is ready too. It might require optimisation. For more information check tech documentation on GDrive.

User story:

As a user I want to register demand for services or products to be able exchange some of my offers to this.

Tech details:

It is already implemented on both the mobile client and the backend. In the V2 version of the contract, demand shouldn't be registered on-chain to reduce gas cost on operations with search for match queries.

User story
As a user I want to see all matches between my demands and offers

Tech side:
We agreed on keywords to do the match. Keywords might be stored in the separate database field as strings separated by commas. I have concerns on performance by doing aggregating query with text search on big number of records. Think more about possible alternatives. Also do not forget about pagination.

User story:

As a user I want to mine a token and exchange it over the platform.

Tech details:

Work with the ethereum chain is implemented in the separate module. It is verified and covered with tests. Now this should be added to the main app to combine business logic on-chain and business logic off-chain.

How to handle the case when mint a token takes too long and a mobile client can not get callback within appropriate time?

Geth has an API which returns transaction by hash, in the case of web3j it is web3.ethGetTransactionByHash(txHash). However to obtain txHash is an issue in web3j. TxReceipt is ready when tx has been put into the pool and waits to be mined, but web3j returns txReceipt only after tx has been mined.

What else do we have to obtain tx info?

It should be possible to get this information from the Event which is broadcasted when tx or at least token has been mined.
It is possible to cache profile state before the call and compare it with the profile state after the call, e.g. query the list of assigned tokens before and after (still has some drawbacks).
The contract can be extended to support this functionality.
Technically geth supports sending back tx receipt as soon as tx has been put into the waiting pool. It means it should be possible to extend web3j to support it.

Current solution would be to not do overengineering and go with the default solution. At this moment nodes and the chain are under full control, mining happens every 15 seconds and in the foreseen future there are no business requirements which bring changes to it.

For more information refer documentation to the project in Google drive.

Sub-features in the group:

[feature] Register user on both web and ethereum chain platforms #14
[feature] Register offer on both the chain and the server. #15
[feature] Register demand on the server #16
[feature] Limit the cache in the mobile client #17
[feature] Synthetic match query from the database and the chain #18
[feature] Confirm user always receives the most up-to-date matches #19
[feature] Remove offer action from user profile #25
[choir] Merge with the master branch #20
[bug] Registered demands are not appeared after re-login #26

Relevant sequence diagram (21.02.2023)

As a user I want to see all demands

Tech side:
no comments

Tech description:

Keeping a private chain on own laptop lead to the issue of available space. Explore options to decrease space occupied by working chain.

Tech description:

At this moment the is no other way to operate with the private chain except node's console and its API. It would be good to have all functionality which is offered by official open chains, e.g. etherscan.

User story:
As a user I want to see all offers

Tech side:
We should not forget about pagination

User story:

As a user I want to register my offer on the chain and the web part of the service

Tech details:

Backend and chain parts has been implemented as a separate use cases. During integration several new requirements has been discovered:

• to have the chain's token id which corresponds with offer we have to process txReceipt logs aka 'topics'
• if the change in business requirements will lead to increased time from chain, operations with chains should be moved to background service and later chain queried again to receive the status of tx
• it would require to cache tx hash which is not returned at this moment by the web3j interface (at this moment tx receipt is returned only after tx has been mined)

Refer project documentation of GDrive for more details.

At this moment extra work covers:

• migrate operation with chain into WorkManager
• add observation of cached data and perform POST requests in queue for transactions which have been mined on chain
• extend backend /account/offers and, possibly, account/demands to support mapping of offer on-chain and offer data on the backend.
• add CASCADE trigger to delete matches associated with profile id
• write integration test on mobile client, unit tests could be done too by demand

Add ORM like sequelize to db layer instead of direct queries to db.

Also keep API response, domain and model objects on different layers.

User story:
As a user I share with others what I am looking for.

Tech side:
The same as 'user offers'. Besides that we have to build an index or keywords to match demands with offers. It might be an extra field in database with keywords and user confirms keywords when applying profile to the server.