Some people have experimented with using Nano on Android, but it is definitely not a friendly UI. We have plans in the future to make a version that will be scaled properly to mobile size, but that will take a while. We are just trying to get regular Nano to work first.
Getting the private key for delegate accounts has also been added.
Known issues include problem signing multisig transactions if using a remote host. If using local host, it should be fine. There seems to be some problem with the websocket channel for signing unconfirmed channels but we need to check into it more.
nice keep the hard work
Quantum_Mechanics
will be superrrrr
Important notes:
Apostille:
All old .nty files and apostilled files are now invalid because a few things changed in both.
Translations:
You can consult https://github.com/QuantumMechanics/NanoWallet/blob/master/src/app/modules/languages/en.js and translate it if you want to add your own language. Please try to keep html tags if any, just translate between them. Of course you are free to move those tags in the sentence to arrange it as your language need.
About apostille, I forgot to mention:
If you used old Nano versions and did apostilles, please clean data stored in local storage or it’ll cause errors.
For that simply open the developer / web console (you can find it in your navigator topbar under ‘tools’), paste:
localStorage.removeItem(“ngStorage-nty”);
Then press enter and refresh the window.
Hi,
Aliases are namespaces with an @ prefix. With the NIS api you can retrieve any account by the namespace it owns. For exemple @nw is a namespace owned by my testnet account TBCI2A67UQZAKCR6NS4JWAEICEIGEIM72G3MVW5S, so if I want to send to this account I just type @nw as recipient. I’ll add something about this in the FAQ module.
No going to be used in address book because you rent a namespace for a period of a year so it could most likely change of owner in the future
1 Like
Wow! I did not know it…
Thank you for teaching me.
I need to study more… ( ^ ^ ; )
Often I’m sorry
If it contains a ‘_’ in the name space,
Properly address can not be set.
Is the specification of which is also ‘Aliases’?
Ex ):
@godtanu
→ OK (TB235J-LAOGAL-DATDJC-7LXDMZ-SDMFBU-MDVIBF-VQPF)
@team_udon
→ NG (invalid NameSpace ‘teamudon’)
Get an ‘team_udon’ is ‘teamudon’ and displayed error messages.
1 Like
Going to fix that and add better validation for the namespace name, I forgot to do it ^^. Thanks
3 Likes
Apostille did not work.
Do I need to purge my account?
There is a need to read again .wlt File?
I am using the Firefox.
The collectively 3 file Apostille (image, image, add text)
It will remain throughout the run
You need to purge the nty data in local storage. To do that open your browser console (help: http://webmasters.stackexchange.com/a/77337), you’ll see some kind of “>” at the bottom of the console, there you need to paste:
localStorage.removeItem(“ngStorage-nty”);
Then press enter and reload the page.
2 Likes
I was posted ’issues16’.
Garbled characters Multibyte character File (Apostille).
Version 1.1.11
- Global code improvements: Faster and stabler
- Fix upgrade of NCC wallets
- Improve signature of multisig txes
- Improve transaction details
- Fix aliases with special chars
- New apostille certificate design
- Apostille improvements
- Better handling of nodes for harvesting
- Multisignature accounts delegated harvesting
- Store all nodes used for multisignature accounts delegated harvesting in local storage
- Automatically reconnect if your internet connection goes down
- Mainnet enabled
- Chinese translation (about 95% done)
- Minor design
- Minor fixes
Source code is now available: https://github.com/QuantumMechanics/NanoWallet
I’ll write the readme and publish documentation during week-end
2 Likes
Hi
I have a problem creating a new mosaic with Levy feature enabled. It’s not possible to select current mosaic from the dropdown list.
I’m trying to create new mosaic, say “test-mosaic”. I check the “Levy” checkbox. Dropdown selector with available mosaics appears. But I can choose only XEM as the Levy mosaic. Therefore I can’t set levy in my newly created asset.
I’d like to set up some levy to make sure that target account will receive equivalent portions of my asset and XEMs to make further transactions.
Not sure if it is NanoWallet or core API issue.
Hi,
In Nano you can only use Mosaics you own as Levy. Do you already have some ? If not there is no problem, you can only choose XEM
As far as I know, technically any transferable mosaic can be a levy for any other mosaic. It also use to be that a mosaic could be a levy of itself, but I haven’t tested that recently. Right now NanoWallet only supports adding a mosaics you already have in the dropdown to choose from as that is easier for most people than seeing a dropdown of all mosaics on NEM.
OK, I’ll try to explain this case in details.
Imagine that you are creating new mosaic. Name it, i don’t know, VirtualUSD (divisibility 0, total 1 000 000). To make it transferable we should send some XEMs in transactions alongside with our VUSD. Otherwise, end users will receive only VUSDs. They can not transfer it further because each transaction implies at least 2 XEM fee.
OK, we can make our newly created mosaic trully transferable if we include enough funds for the endpoint users to pay the fee. So, we need to add 200 XEMs to transfer 100 VUSDs in order to allow our recipient to make up to 100 further transactions with 1 VUSD each. But all 200 XEMs will be spent on these transactions. Therefore, again, the 2-tier recipients will not be able to transfer funds further because they will receive only 1 VUSD each and no XEMs at all.
We can add some levy to balance transactions. In our case if we set levy amount to 1 VUSD all the fees will be compensated.
For example,
- Main account sends 100VUSDs to user1 (user1 will receive 100 VUSDs + 200 XEMs).
- user1 sends 99VUSD to user2 (user2 will receive 99 VUSDs + 198XEMs), 2 XEMs fee and 1 VUSD levy will be subtracted from the user1’s account, total balance will be 0 VUSDs (and 0 XEMs).
- user2 sends 10VUSD to user3 (user3 will receive 10 VUSDs + 20XEMs), 2 XEMs fee and 1 VUSD levy will be subtracted from the user2’s account, total balance will be 88 VUSDs (and 176 XEMs).
It looks like the easiest and the most natural way to organize transfers from the scratch. In this case wallet for our VUSDs can be easily implemented.
Not a bug, when clicking on levy checkbox you can see that “right now, only owned mosaics can be used as a levy”.
To be honest I thought that the mosaic needed to exists to use it as levy… But I tried and it worked.
Added it to my to do list