Hello EOS community, today I am here to share with You latest updates. When I wrote my first article on Medium https://medium.com/@cryptofairy/eos-on-my-ledger-nano-s-wallet-5b7c5bb6d0ae, I wasn’t expecting such a positive reaction from the community. So I decided to carry on and share my progress.

The previous article was about the working prototype. The prototype is a good buzzword but is not useful for end users, so I have struggled a lot. There were conceptual issues, technical issues, UX issues and the icon, LOL.

So, I’ll start with the icon. On Reddit, I saw a negative comment regarding the icon, and I couldn’t agree more. The community, was the one to launch EOS mainnet, I think it will be fun to involve the community in this process. Here are the requirements:

* 16x16px GIF image format.

* Only black and white colours, without 50 shades of grey.

* White background, black logo shape.

Drop me a line: fairy.crypto.fairy@gmail.com.

Conceptual issues. It’s not enough to ship the application. Way more important is to think about the following: WHOM, HOW and WHERE it will be used.

When WHOM is self-explanatory, the HOW part, on the other hand, is more tricky. EOS is different from other blockchain platforms, as there is no particular transaction to send coins, to vote, etc. All of them are defined by smart contracts, which can be changed because of some reasons. So we have to predict such scenario in the future.

Regarding the WHERE part, currently, I see two options, web & desktop. So have to think about communication model between those two and Ledger. There should be the right technical approach for that. More details below.

Technical issues. Transaction size in EOS is not limited, so due to that, we can have transaction size measured in MB. On another hand we have Ledger with limited RAM capacity of 4Kb and most of it is eaten by the application itself. So the data should be processed on the fly without caching.

Data. In order to be easily adapted by different UI wallets transaction, data should be encoded by well-known standards. For that, I have used ASN1 DER encoding rules. There are a variety of existing libraries that are written on js, Python, C++, etc.

Browser support. To have communication with the browser, U2F protocol was used. More information about it you can find here https://npmccallum.gitlab.io/post/u2f-protocol-overview/.

SLIP-0044 support. It was not a big deal, but I think I need to mention it. Now the application is generating key-pairs according to this hierarchy.

UX issues. The following improvement of existing prototype is a dead end from UX perspective. So the application was rewritten from scratch, and now it has become more user-friendly. Data represented on a display is more consistent.

Security issues. All cryptographic staff should be one on the Ledger side, no client-side preprocessing is allowed. And this was done during prototype development. Another interesting security aspect is UI. Before signing any transaction, Ledger should display all relevant data to a user in a consistent way to be approved and signed.

Summary. The work is slowly moving to the end. Xoxoxo. Gossip cryptofairy.

PS: Video https://youtu.be/3dQlDW3BfsA

PPS: If you feel like contributing — contribute. 0x1874989cCb31eEf7ED4ac1ac000EB3D476263B16