Thanks @GodTanu correct that issue is as identified and worked through by Japanese community, thank you for the hard work on this one.
There are a couple of other problems though which also need to fixed and there is a way to do this in a patched release, I will post more completely in a short while, I am just asking the devs to check the post to ensure it is accurate
Apologies the update is a little later than planned, it took a couple hours longer than I thought to get it all written up.
We have now worked through the issues with the interim release of the Desktop Wallet last night (0.13.3).
There are workarounds and a patched release of the Dekstop Wallet is targetting 11th Nov in the morning UTC; SUBJECT TO TESTING .
There are two main issues:
Wallet is using Alpha builds of the SDK - there was the Endian/Marker issue in an SDK call which was worked around on a dev workstation but not included in the Alpha, as per @GodTanu’s comment above
The public keys/certificates being used for enabling delegated harvesting have an issue, it was not present in the dev environment due to things being run locally so not being an issue
Unfortunately both of the above were not evident in the development environment due to workarounds that then became evident on Testnet. We have learned why and are putting some separate testing in place to try and avoid this in future Sprint Releases.
The good news is that these two issues can be resolved in the SDK and released as a new Alpha version of the SDK inside a patched wallet build. That is being worked on right now and will be released when tested.
The patched release is likely to be tomorrow morning (11th Nov morning UTC) subject to testing.
There are some further minor issues which hide the above due to not being able to easily access the active harvesting status of a node, these will require some changes to REST Gateway which will be included in the next Testnet patch along with the next server version (0.10.0.4)
There are 2 major issues and 2 minor ones.
GodTanu + TomoTomo9696:
https://twitter.com/GodTanu2/status/1326054923411222529
https://gist.github.com/tomotomo9696/44a4bb7ee6b0749327695605a9aa98b2
Java:
https://github.com/nemtech/symbol-sdk-java/issues/362 .
JS/TS:
https://github.com/nemtech/symbol-sdk-typescript-javascript/issues/704 & https://github.com/nemtech/symbol-sdk-typescript-javascript/issues/713
This issue can be fixed in the SDK with an Alpha build and a PR has already been created for review.
Each node has a certificate, which is generated from a public key. This is the key that is used in the linking transaction for harvesting. There is no REST endpoint to retun the public key + cert at present, the docs incorrectly stated one did exist via NodeInfo, but that is returning the certificate authority cert not the node cert. The docs are being fixed and reviewed.
This causes a problem with trying to activate from the desktop wallet because the linking transaction can’t be called reliably. It wasn’t an issue in the development environments because they utilise local certs and known public keys so became evident when using Testnet which only happened on release.
Short term fix: There are several known NGL nodes which are set up and working, the short term fix is going to be to restrict the node selection to a drop down list of nodes that we know should work, the next wallet tagged wallet release will contain this workaround. There is a risk that the slots on he known nodes fill up obviously but we will try and increase those numbers and keep an eye where possible, doing this will get some delegated harvesting going on Testnet more widely. This fix has been made in a development environment is being tested at present.
Mid-longer term: Will be fixed in the next Rest + Server release and then worked into the Wallet to allow selection of any node, a more configurable form will also be provided to allow provision of the hostname and public key explicitly for any node that is not discoverable via the rest endpoint.
There is a weakness at present with getting the active status of harvesting on a node due to how some communications between REST gateway and Peer node work around the diagnostic call, this was the 2/2 that was highlighted in the release note and is planned for the next sprint, which will be released in the next Server + REST release (Testnet patch).
This makes it hard to display to a wallet user what the reliable active status is.
This is being tracked under: https://github.com/nemtech/symbol-sdk-typescript-javascript/issues/705
This was part of the 2/2 comment in the release note and planned to be released in the next sprint already.
The current way of querying the harvesting history is inefficient but is functional, this will be altered to make it easier to get full harvesting history by account in the next Server + REST release (Testnet patch). This was part of the 2/2 comment in the release note and planned to be released in the next sprint already.
Short term it is possible to see this on the account using Explorer or on the Wallet as you see from TomoTomo9696 here: https://twitter.com/tomotomo_9696/status/1326101606266408960 (edited)
NGL should organize & manage Github Issue.
There are many neglected issues. Unable to identify current issues.
Please clarify the known issues.
If there is a shortage of administrators, hire new ones.
The NGL should have enough money to pay for it.
Thanks, this is not a priority for the current sprint delivery. It is on the list as part of the clean up work at the end of the delivery
The team are addressing issues related to the features they are working on in the sprints and updating Github
If there is a specific issue you are concerned about, rather than a general feedback, please put the link up here and I’ll take a look
There is no answer to my issue either.
“Symbol is primed to facilitate tokenization and STO issuance”
But we can’t even examine the library.
How is the whiskey case going?
An updated version has now been released with patches for these issues and enables delegated harvesting.
The question that arises for me:
Too much work for too few developers?
(Documentation included)
And by that I don’t just mean the evolution of wallets …
thx
Previously, I signed up for the mobile version test via the google form to participate. I haven’t heard from them since. What happened to it?
When is Account and Mosaic Restriction going to be implemented?
In the final release?
The roadmap is the one that is reset at that point.
There is no reason to stick to a roadmap created in the past
Ask for a redesign that you can afford
Previously, I signed up for the mobile version test via the google form to participate. I haven’t heard from them since. What happened to it?
I am not sure on the old one. There will be a new list and details communicated with the release announcement (Friday this week or Monday next week). We needed to create new Apple store account(s) to pass their approval process etc, the old list is probably and old account as well.
When is Account and Mosaic Restriction going to be implemented? In the final release?
This will not be in the wallet for launch/final release. The feature will be built in (it was is a Should rather than a Must requirement on the requirements document) between now and launch, and tested. It will probably be in the first release after launch, we may be able to release an Alpha for Testnet before then but the team will also be focussed on resolving issues/bugs on the current features for the final release to support launch on the 14th Jan.
The roadmap is the one that is reset at that point. There is no reason to stick to a roadmap created in the past Ask for a redesign that you can afford
I’m sorry I didn’t really understand this question, I think it didn’t translate well maybe. I think perhaps the suggestion is changing the features for launch due to the launch date change. If that is not what is says please ignore this answer though. The extra time has been given to allow for soak testing and issue resolution of the completed features. If we keep adding new features, the time before that can start is longer which adds risk to launch etc.
There will be a roadmap communicated between now and launch for what happens after launch, which I think is the part of the map that is missing - launch is just an important step but there are further developments after launch as well and they need to be communicated.
Ahaha
Certainly it seems that it did not convey well
But I got the response I wanted
I can generally agree with that
Thank you
I hope it will be a reliable launch!
Resolve problems with existing functions until launch
I support this
Hi Team.
Congratulations on completing the sprint ver.
Do you have plans for a universal version release?
In the case of the Windows .exe file , a warning comes in every time of installation.
Hi @GodTanu,
I thought I’d catch these points while the team are doing the important work on the mobile apps. Thanks for the two points, both are correct and will be fixed.
We are just working through the final deployment tasks and validations for the mobile apps, they are ready for release and will be released in the next few hours (assuming nothing is found in validation).
Do you have plans for a universal version release?
The nightly build release is actually built in this way, no reason it can’t be released as a zip file the same as Nano Wallet was. The team have recorded an issue in for this and will try and pick it up next week:
https://github.com/nemgrouplimited/symbol-desktop-wallet/issues/721
In the case of the Windows .exe file , a warning comes in every time of installation.
This one is related to the installation files not being signed fully, they will also pick this up next week alongside the general issues resolution:
https://github.com/nemgrouplimited/symbol-desktop-wallet/issues/720
The mobile wallets have just been released (Android available right now, iOS coming)
In response to the decision to postpone the launch, we decided to repurchase xem
Pay tribute to the courageous decision
A new version of the wallets has been released and iOS will go into open beta shortly
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.