It’s a nice feeling to be able to write an update on the progress of Trinity with the wallet now available on app stores and released to 1.0.0. Many hours of work went into this project and it has culminated in an application that has been very well-received within both the IOTA and wider cryptocurrency communities.
However, the work does not suddenly stop now that we have a full, stable release for Trinity V1. We must now look forward to the second iteration of Trinity: a new version that is much more comprehensive than a simple cryptocurrency wallet.
Tens of thousands of people are already using Trinity 1.0.0 and so its continued maintenance is extremely important. The team will continue to dedicate much of their weekly work to ensure that any outstanding bug fixes, crash reports, and minor feature adjustments are resolved efficiently.
There are a handful of outstanding features that we would still like to include in V1, but we will soon be setting a feature cut-off point where all new features must be developed for V2. We would like to have a quicker turnaround time for the release of this second iteration, so (near-to) full team attention will be required soon.
Some of the remaining new features for V1 include:
Ledger Nano X Bluetooth support: Ledger Nano X has been available for a couple of months and, although supported via USB on Trinity desktop, we are yet to add Bluetooth support. With this addition, Trinity Mobile users will also be able to secure their funds with a Ledger Nano X.
Trinity Desktop dev mode: This will make using the wallet with devnets / private tangles a more straightforward process.
Spent Address Recovery Tool: Back in the day when users were grappling with the original (pre-Trinity) IOTA wallet, there were few checks on address spend statuses when sending transactions. Unsurprisingly, many users ended up with funds on spent addresses.
With Trinity V1, it’s near impossible to end up in a situation where funds arrive at a spent address. Nonetheless, some users may send tokens using other software that does not make the same checks. Therefore, it is necessary to provide a means of rescuing tokens that have inadvertently arrived at a spent address. Until now, users have had to resort to using the CLI wallet to recover their funds. We recognize the substantial UX issues here.
This is not a simple process because once you spend from an IOTA address you reveal 50% of that address’ private key. We must make use of a process known as ‘Bundle Hash Mining’ to create a suitable bundle that reveals as minimal additional private key fragments as possible.
This is the final piece in the address reuse puzzle for Trinity V1 and we appreciate that some users have been patiently waiting for this feature.
We are working hard to provide an update on these features soon.
Work has already begun on designing and planning Trinity V2. We will save the finer details for a future post.
But here is a basic overview of what that new version may look like…
“We plan a highly modular system, built around a core account module (a future iteration of the one already available in the client libraries). The module exposes an access-controlled API for third-party plug-ins to access core functions such as transfer initiation, address generation, chat-integrated commands, etc. This opens up Trinity for developers to implement their own modules that directly interface with user accounts. On a simple level, this enables things like exchange integration, but also the possibility of many exciting future use cases.”
We will leave it to the community to begin to think about those possibilities.
We would also like to involve the community in this process as much as possible. We want to know which proposed features answer your needs best. We ask you to simply take a look at the Github issues labelled feature request and upvote (with a thumbs up!) those you like the most.
If you think of some other feature that is not listed, just go ahead and submit your own feature request!