Lightwallet STANDALONE 1.1 + 1.2

Releases
#13

I guess it’d be fine if a bat was included that started nginx and then opened firefox.

start nginx start http://127.0.0.1:7777

#14

good idea, will add at to next package build

#15

okay, just checking.

maybe something else? not sure.

#16

that is a great idea.

looking forward to it!

Also, on top of that, maybe if there was a logout or stop ngix button in the browser?

I know the shield takes us back and I like that, so not quite sure what it would be or how.

#17

I have a question regarding the Lightwallet.
Once the nginx Lightwallet is downloaded and started, it is available in the browser on 127.0.0.1:7777 and it can be used to connect to a remote NIS, for example on go.nem.ninja:7777
However, if the browser is used to go directly to go.nem.ninja:7777 the lightwallet is available as well.

So why is the nginx server used in the middle, between the browser and the NIS?

#18

it will NOT be available directly on the server in future, here’s the reason:

#19

Ah, ok, I see.
What would the typical use case for the lightwallet be in that case?

#20

I do not follow o0

Typical use case would be daily usage.

I only implied that you shouldn’t use lightwallet deployed directly on some node, as it might be fake.
You should use lightwallet that you run locally.

#21

zip of lightwallet 1.2 requires a password

#22

I am not sure what I am doing wrong, but when I attempt to create a namespace (provision namespace transaction)

I get an ‘invalid address’ for the Rental Sink address, so I can’t proceed to purchase a namespace.

#23

It says ‘failed at announce, invalid address’, for the address that starts TAMESP

#24

Ok now I am getting ‘not a valid name id part’ on any of the names I have selected.

I checked first to make sure the names haven’t already been registered

#25

omg now it says - ‘failure to send timestamp too far into the future’ this is a complete pain

#26

‘failed at announce, invalid address’

old version (and you’re posting in old thread, this one is current Lightwallet STANDALONE 1.4, 1.6, 1.7)

‘not a valid name id part’

as said - invalid name, most likely invalid characters, I believe this was in the tutorial…

‘failure to send timestamp too far into the future’

that one is actually a bug, as lightwallet should get time from nis server (right now it tries to use system time)
that means, your system clock is a bit off when compared with network time.

(fastest thing would be to synch your system clock, if win: http://www.tenforums.com/tutorials/6410-clock-synchronize-internet-time-server-windows-10-a.html)

I’ll try to fix time bug in one of following releases.

#27

someone is begging to be flagged for spam.

#28

I eventually managed to secure a namespace. I didn’t realize capital letters weren’t allowed.

Plus as suggested, I synced my PC clock with time.com, it was a few seconds out.

Not sure why you think my posts were spam patmast3r? My issues were genuine, but have been sorted now.

Thank you gimer for the advice.

#29

It’s no biggie but you made 4 consecutive posts instead of just using the edit post feature.

#30

Ok, let me rephrase my question.

With the community client, the lightwallet and the mobile client, NEM users can now choose between three possible clients. We should avoid to leave room for confusion. Be it for potential new users, newbies or stakeholders.

Therefore, I was hoping to receive some advice on when and in what situations (use cases) it is best to use which of the three client’s. Off course everybody can use all three daily, but what criteria can be used to make a choice?
In my opinion, possible confusion about this will limit the NEM success.

Thanks in advance to share your thoughts.

#31

  1. lightwallet does not have all the features yet (but that’s matter of time, as lightwallet development is much easier than ncc)

  2. no multisig setup (although it handles multisig accounts fine)

  3. no setup of delegated harvesting - some design decisions are needed

  4. no harvesting - related to 2) (lightwallet will have only delegated harvesting, no sense to have non-delegated harvesting inside lightwallet)

  5. no “boot” node feature - that probably won’t ever be avail in lightwallet

  6. no translations - YET! (it requires some changes to allow that)

  7. ncc has:

  8. only very basic support for namespaces and mosaics - and most likely that won’t happen soon

  9. no support for V2 transactions (sending mosaics) - same as above, probably won’t happen soon

  10. mobile - that’s not a competitor, rather supplement, no one likes to use web browser on the smart phone, dedicated apps usually work MUCH better

My humble opinion: lightwallet IS the future.

#32

word!