In the process of redesigning the underlying architecture of the wallet, we decided to go with a statemachine-approach to model the different states the wallet can be in. We started the work on this, but are still in the process of finding the optimal pattern. The basis idea is, that the wallet is always in a very specific and well-defined state. When a action occurs (like the creation of a DID), the wallet undergoes a strict transition from one state to the next. Whenever the user exists the wallet or another session is opened, the last state is restored from the encrypted storage and every information not in alignment with the last state is thrown out. This architecture keeps the wallet-data coherent and provides safety in cases of abrupt termination in every situation. Another feature we have worked on and which we’ll develop further along the way is the Logging-Service, which offers methods to query the data stream of incoming events. These could be system-messages, user-interaction or incoming data from external sources.

An overarching topic, we also mentioned in the last report, is interoperability. A lot of resources are currently going into the development of a .net compatible library for DIDComm v2. The current reference implementation doesn't have support for .net, so we have to build it ourselves. This is a considerable endeavor and not covered by the initial plan, but nonetheless a crucial feature for future development. The main goal is to archive interoperability with RootsWallet in the next weeks.

Lastly, we also worked on the improved website-integration and the support of the direct injection of the wallet inside a website (using Iframes). These extents the different modes the wallet can run in to four: As a normal extension, the fullscreen-extension-mode, as a Popup opened by a click on a website and now also injected into a website as a overlay.

The analytics-platform is finally also available on mainnet (https://bt-analytics-mainnet.azurewebsites.net/), which required an architectural overhaul in some parts, due to the size of the dataset. The previous approach of syncing the data were (while being feasible in general) not up to the task of syncing the dataset in a acceptable amount of time. Currently, the project is using SQL-databases living on Microsoft Azure. This is producing a bit more costs than initially estimated, and we are looking into ways of optimizing the infrastructure in regard to future growth and feature expansion while keeping the costs in a reasonable manner (and inside the proposals budget). In the end in comes down to the expected performance we would like to provide in the long term and with upcoming features. The next major development regarding personal accounts and the management of the collection of DIDs has already begun, but currently takes a back seat due to the development of a .net implementation of DIDComm v2. At first glance this might be unrelated to the analytics platform, since this is a way of inter-wallet communication, but with the integration of agents and the ability to export and store DIDComm Messages from a wallet this opens up an entirely new dimension of possibilities.

Details on the progress can be found here: https://github.com/bsandmann/p2p-transactions . More information are also available here: https://blocktrust.dev

This is the first progress report of the newly funded browser-extension wallet: The first funding round occurred in the beginning of November.

Ed Eykholt was onboarded on the Identity Wallet project and is now its Lead Developer. In the last month, we spend some time re-architecting some core components of the wallet. The first iteration of the wallet was in many ways just a proof of concept, and it left many architectural questions unanswered. While we are still in the process of finding out of how to structure things best, we rebuild most of the core-services. We also updated our existing PRISM SDK to 1.4.1 and made the necessary adjustments in the wallet and connecting services.

The biggest problem we tackled early on was the migration to Manifest Version 3: Currently, nearly all Browser-Extensions (including the Crypto-Light-Wallets) face the same problem: Chrome requires new browser-extensions submitted to the web-store to use v3 instead of v2. This seemingly small change forces big projects to rethink their complete internal architecture of how to interact with webpages. Instead of a few days of refactoring, this caused those big projects like Metamask to go on a multi-month journey which isn’t over any time soon. Until now, nearly no v3 extensions are available, despite the fact, that projects are able to submit v3 extension over a year now. This shows the problems many extension developers are still facing. Since we restarted our developer effort on the wallet, and we were free to throw away old approaches we might have it a bit easier, than other projects, but we are also not completely there yet. The extension is running on v3 now, but we have to still figure out some architectural pattern for ourselves, since there are currently no reference implementations of how to build browser-extensions-wallets – even for crypto with the new manifest version. Doing everything is WebAssembly was also a additional hurdle which didn’t make thing easier in the current stage of the project.

Additionally, we made a few smaller UI changes and currently working towards the first milestone, which includes logging and the activity history.

Overall, we are quite happy with progress we made so far – it was by no means fast, but we are confident to pick up speed after leaving the topics of browser-interop behind us and focusing more on the business logic, which we can implement in .net.

This is the first progress report of the newly funded analytics platform.

The project is based on the already developed proof-of-concept of the analytics platform for the testnet. In the first month, the project was updated to use the new blocktrust SDK to align with the PRISM SDK on version 1.4.1. The update included a new type of operation which wasn’t available on 1.3.3 which is the “Deactivate DID” operation. The new operation caused some major rework and required also some additional testing, since the official PRISM node is not behaving as it should in some cases. The causes different results in the resolution of some DIDs. Since these are all edge cases, the real-world differences shouldn’t be relevant at this stage.

Additionally, the project was also released to support the preproduction network, which required some additional work to make the code more agnostic of the underlying Cardano-network. The project is now using a CI/CD pipeline to roll out a new version of the analytics platform to each network independently. The current version can be found here: https://bt-analytics-preprod.azurewebsites.net/

The mainnet analytics will also follow in a few days. The next item on the to-do list is the integration of a private area, which allows users to monitor a specific set of DIDs over time.

Details on the progress can be found here: https://github.com/bsandmann/p2p-transactions More information also available here: https://blocktrust.dev

Details on the progress can be found here: https://github.com/bsandmann/p2p-transactions More information also available here: https://blocktrust.dev

Details on the progress can be found here: https://github.com/bsandmann/p2p-transactions More information also available here: https://blocktrust.dev

Details on the progress can be found here: https://github.com/bsandmann/p2p-transactions More information also shortly be available here: https://blocktrust.dev

Details on the progress can be found here: https://github.com/bsandmann/p2p-transactions More information also shortly be available here: https://blocktrust.dev

Details on the progress can be found here: https://github.com/bsandmann/p2p-transactions More information also shortly be available here: https://blocktrust.dev

Details on the progress can be found here: https://github.com/bsandmann/p2p-transactions

The detailed progress report can be found here: https://github.com/bsandmann/p2p-transactions

Progress can be tracked here: https://github.com/bsandmann/p2p-transactions/blob/main/progress_report.md