I would like to take this space to update you on the latest improvements and features coming to Fexr in Q1 2023. Mobile wallet has been a great way to secure secrets for multiple Web3 wallets without fear during a time when even top tokenized asset exchanges are getting exposed to hacks and frauds.

Link web and mobile apps with Fexr​

We found it is important for users to use their NFTs and tokens across all compatible platforms to make their borderless, T0 transactions easier. Fexr users will be able to link their wallet with newly created browser extension. This was made possible by powerful web based SDKs for Rubix and Fexr. This allows developers to enable web apps and merchant services to accepts the token linked to the wallet (including Access NFTs issued by other developers).

Developer friendly​

Browser extension + mobile wallet + web SDK for Rubix and Fexr is developed with the support of open source libraries to work in fully transparent and decentralised setup, i.e. A user can optionally setup their hot wallet using Sky connector (hot wallets can also be provided as-a-service by developers with computing resources), modify or use existing browser extension including SDKs for Rubix and Fexr, all with enjoying cross compatibility with other Fexr wallets and services providers.

Secrets with you, always​

While the secret keys for addresses are secured in the mobile wallet, setting up and configuring the essential hot wallet, which communicates with the blockchain peers had been a bit technical for most users and maintenance was sometimes expensive. To overcome this challenge, Fexr is working towards providing specialised nodes for users.

Choose between your wallet providers​

This is made possible in Fexr wallets by intelligently syncing the latest state of web3 Identity, on-chain assets, and provenance of linked user within their mobile wallet, allowing users to backup, disconnect and connect a different node provider anytime during their operation. This ensures a competitive development environment for app builder and service providers under the same platform. Users can easily switch their node provider for a specialised service without having to worry about losing their data or having access issues.

One address, multiple owners​

Multiple signature approvals for a wallet transaction is another important feature we are bringing to the users in Q1 2023. This uses the same strong encryption used natively in Rubix for decentralised identity creation, locally without moving the secret key anywhere from their device.

This feature allows larger adoption from families to businesses, where multiple key owners need approve a transaction. This is also useful for businesses to manage their assets and transactions with multiple stakeholders.

Fluir means to flow​

Every day we’re finding more ways to help users navigate their Web3 journey secure and seamless. This release, we’re calling it ‘Fluir’ is a big leap in the support for app developer, merchant service and organisations to streamline their borderless payments and access management.

Testing summary​

We used three active mainnet nodes to test the first insider version of Fluir build.

Validator.Social is a new social network subnet run by validators to support other validators. Cycle360.tech is an open-source supply chain tracker managed on blockchain. Both are the asset verifiers and payment receivers in this real-case scenario. Fexr.Club is the Web3 console maintained by Fexr. A user hosted with Fexr.Club is transfering to a node hosted by Validator.Social, both the transactions had happened via locally configured Sky connector tool to communicate and also provide hot wallet to the sender and receiver wallets.

Rubix community quorum (type one transaction) is used to verify transaction run between Fexr.Club, Cycle360.tech and Validator.Social. All transactions used UI interface and does not include CLI commands or triggers to support or initiate transaction in foreground or background.

Transaction details and analytics will be shared in the next blog post.

When reading the heading there can be some doubts about the terms mentioned there, so I will start by giving a brief explanation about the terms. So the first question arising in this context will be about public-private key pair. As the name suggests, a public-private key pair is a pair of keys that are used to encrypt and decrypt data. The public key is used to encrypt the data and the private key is used to decrypt the data.In our blockchain scenario the private key is used to sign the data and the public key is used to verify the data. The public key is available to anyone and the private key is only available to the owner of the key. This is how a public-private key pair works.

Since the first part, which explains about the public-private key pair is completed, we will now talk about how the public-private key pair becomes public-private key pair images and how it is generated. So the process begins by selecting a random 256*256 bit image and giving a random passphrase of the user's choice. The given image is converted to binary, the passphrase is hashed using SHA3-256 and is embedded with the image binary, using this set of binary digits a new image known as the DID image is created. From this DID image a new pair of images are created, one for the public key and one for the private key. These images are created using a complex patented algorithm known as Non-Linear Secret Sharing (NLSS) algorithm. The algorithm works based on some really complex mathematical equations. The program which generates the images iterates till a matching public and private key is found. These private and public key images are then used to sign and verify data. This is the basic generation of image based public-private key pair generation.

Though the above process seems simple the inbound computation is really complex and cpu intensive. Performing such a cpu intensive task on a small device was really a challenge. The part where the key-pair generation requires high computation power is finding the matching public and private key images. The program reecursively checks for the matching public and private key images and if it finds one it returns the key images.