ANNOUNCING VERUS MOBILE 1.0.1 TESTFLIGHT/GITHUB APK RELEASE, AND CALL FOR TESTING TO TEST IDENTITY UPDATES AND APP ENCRYPTION REQUESTS, ENABLE EXPERIMENTAL DEEPLINKS IN WALLET SETTINGS
Github APK (Android):
https://github.com/VerusCoin/Verus-Mobile/releases/tag/v1.1.0-1TestFlight Link (iOS):
https://testflight.apple.com/join/A6e5WS35 (This link may take a few hours to display 1.0.1-1, if it says it isn't accepting new testers, try again soon)
This release is a large wallet capability update, and the result of about 2 calendar years of work by a number of developers, both volunteers and with bounties supported by donations, to allow Verus Mobile to support the Verus DREAM (Decentralised, Rights-preserving Encryption Application Model). The biggest changes are a rework of Z-transaction support, refactoring and upgrading it on the back-end and adding shielded transaction support for Android, the new compact, much more capable DREAM deeplink, QR code, and NFC format, and support for identity update, and data encryption requests. Updated Z-address support As part of the complete rework/upgrade of z-transaction/encryption/decryption support, Android now supports shielded Verus addresses and private Z transactions through the native lightwallet stack. This brings Android to feature parity with iOS for private wallet operations. What this means in practice:
* All users can now set up a Z seed from Settings > Profile. If your current wallet seed is a valid 24-word mnemonic, the app can offer to reuse it as the Z seed. You can also import an existing 24-word Z seed or an extended spending key.
* All wallets can now derive Sapling/Z addresses, track shielded balances, show shielded sync progress, and list private transactions.
* Z memos are supported when sending to private/Z recipients. The memo field appears in the send form when the destination is a private address.
* The app blocks sending while a shielded wallet is still syncing, because private balance data is only reliable after sync completes. First sync can take a while.
* Private funds need confirmations before they are spendable. The UI now explains this when a private balance is pending or not yet spendable.
1. New GenericRequest deeplinks The app now supports the new compact GenericRequest deeplink format. These are the new verus:// links, such as: verus://1/<compact request payload> The GenericRequest is a unified request envelope. Instead of every feature inventing its own QR/deeplink format, apps can package one or more request details into a single signed request. Verus Mobile can parse the envelope, verify who signed it, validate each request detail, show the correct UI, build a response, sign that response, and return it to the requesting app or service. This is a newly defined, extendable protocol that enabled the development of Verus DREAM applications by creating a package for any type of wallet request (present or future), including identity updates, app encryption requests, user data requests, login requests, VerusPay invoices, or even a combination of multiple different request types at once. Supported request details in this release include:
* VerusPay v4 invoice details, adding support for private addresses to VerusPay, and greatly reducing the size of a VerusPay request to allow for easier-read QR codes or more data
* AuthenticationRequest, the new compact login/authentication request, also greatly reduced in size, with added support for encrypted responses
* IdentityUpdateRequest, a new request type that allows for deep links or QR codes to prompt the user to add encrypted data to their ID, or update their VerusID details
* AppEncryptionRequest, a new request type that allows for the creation of an zero knowledge encrypted channel between an app and the user's wallet
* DataPacketRequest and UserDataRequest primitives exist in the libraries and are upcoming, but are not fully exposed in the app UI yet
2. Important behavior:
* Legacy x-callback-url VerusPay and login deeplinks are still supported.
* New verus:// links are shorter and more flexible.
* Experimental request types, including identity update and app encryption, are controlled by the "Enable experimental deeplinks" setting.
3. This release turns Verus Mobile into a general request handler for Verus identity, payments, encryption, and future app-to-wallet workflows. IdentityUpdateRequest support GenericRequest can now carry identity update requests. Verus Mobile validates the request, loads the target identity, compares the proposed update against the current identity, and presents a guided review flow. The identity update UI is split into clearer steps:
* Review who requested the update and which identity would be changed.
* See a summary of content changes and high-risk changes.
* Inspect identity content changes in a dedicated content step.
* Review authority, recovery, revocation, and other sensitive changes separately.
* Confirm payment and submit the update transaction when approved.
* See and copy the resulting identity update transaction ID after completion.
4. There is also special handling for credential data. If an identity update includes vrsc::identity.credential content, the app encrypts credential data locally before creating the transaction. The plaintext credential data is not sent to the RPC server. This requires the user's Z seed to match the private address on the identity. AppEncryptionRequest support This release adds the first mobile flow for AppEncryptionRequest inside GenericRequest. An AppEncryptionRequest lets another app ask Verus Mobile to derive Verus encryption key material from the user's identity and Z seed, after user approval. The wallet can return viewing-key/address information, and optionally an extended spending key if the request asks for it and the user approves. The app shows:
* The requesting identity
* The signing system
* Signature time when available
* Derivation number
* Derivation identity or request identity when present
* Whether an encrypted response address is requested
* Whether the request asks for secret key material
5. Responses are added to the GenericResponse and then signed by the user's selected identity. If the request includes an encryption response address, the response detail can be encrypted into a DataDescriptor before it is returned. This feature depends on the user's Z seed because the derivation uses Sapling key material. If no Z seed is configured, the app explains that setup is required. Deeplink reliability and UI polish There are also a number of smaller fixes and UI changes in this release:
* Fixed an iOS issue where deeplinks could fail to trigger if the app was already open.
* Reworked VerusPay information pages.
* Reworked login/authentication request pages.
* Added clearer request signer cards, chain labels, timestamps, and technical detail sections.
* Added UI for opening compatible requests in another installed Verus handler app.
* Added settings for experimental GenericRequest request types.
* Improved Z-wallet sync messaging and send blocking while shielded data is still syncing.
For developers and services If you are building an app or service that talks to Verus Mobile, GenericRequest is the new preferred format. Use verus://1/<payload> for the new compact request deeplinks. The request can include one or more detail objects, response URIs, signer metadata, a preferred handler, and a signed envelope. Verus Mobile will validate the envelope and route each supported detail to the right user flow. The verusid-ts-client library supports the creation of these requests and older request styles are marked as deprecated. Legacy VerusPay and legacy login consent deeplinks still work, but the new GenericRequest format is where new functionality will land. This release is an important step toward the realization of the Verus DREAM, enabling the creation of decentralized applications that preserve user rights, scale to the world, and aren't subject to value extraction. To learn more about the Verus DREAM model, you can watch @miketout's presentation at Paris Blockchain Week last week at
https://www.youtube.com/watch?v=8alMlLVcZuU. More resources to come. Happy testing
Once we get enough testing on this release, and the remaining expected DREAM request types are pulled into the app, an App Store/Play Store release with the new request types is imminent.
