What do you mean? Slatepack (RFC0015) flow is the approach now.
Well, RFC0015 solves the problem of unifying the underlying transport layer for building TXs in Grin.
What I was talking about is the UX for building these TXs: how to unify synchronous and asynchronous approaches in the UI, how to guide user through both of them and so on.
Does it makes sense for you?
Just a question, does the slatepack transaction flow is the same of the grin-wallet? I.e., check for online TOR address before printing the slatepack block?
Eventually, yes, it will be as it is right now in
grin-wallet. I’m evaluating the exact approach on how to get there and probably I’ll split this into two pieces: introduce async version only first (slatepack exchanges manually) and only then will add grin addresses via TOR.
Yes I see what you mean, cool. Feel free to ask for feedback on UI/UX.
Hi everyone! It’s time for the update!
Last couple of weeks I did some experiments on how best to structure transacting process using Slatepack and I hope you will like it.
The flow explained
- Initiate Send. On the initial screen Alice enters an amount and choose fee she would like to pay. Then when she presses “Send” it would navigate her to the next screen.
- Sending Screen. On this screen Alice would see a little guide on what to do next and her part of the transaction in the form of Slatepack. She now needs to share it as a text or as a file with Bob.
- Initiate Receive. Button “Receive” in the bottom left was only used for information purposes, but not anymore! Now it would navigate Bob to “Receiving screen”.
- *Receiving Screen. Here Bob sees a little guide and the text area which he can fill manually, paste from clipboard or open a file (depend on how Alice has shared her slatepack). When Bob enters the slatepack from Alice he press “Generates response” and shares it back with Alice as a text or as a file.
- Finalizing. Alice receives Bob’s slatepack and enters it on the “Sending screen”. Then she presses “Finish transaction”.
- Posting. After finalization app would automatically show a confirmation dialog after which transaction would be send to the node.
Also, if a user opens a slatepack from another app (as it is the only way right now) in Ironbelly it would automatically navigate to the needed screen!
I’m doing final tests at the moment and hope this or next week this functionality will be in App/Play stores!
My next big goal is implementing Grin addresses in Ironbelly!
Besides here is a couple of things I’ve been doing as well or will be doing:
- New website
- Bringing back to life end-to-end tests, so I can do less manual testing and iterate faster.
- Researching solutions for app translation.
- Small redesign and ideas for dark mode.
If you have any question - join Ironbelly Telegram channel https://t.me/ironbelly
I think it looks great Looking forward to the addresses
moved topic to #techtalk
Hi everyone! It’s time for the update!
So, recently version 4.0.0 was released to both Android and iOS.
- Slatepack support via files or copy/paste.
- Transation flow is redone, now it’s more intuitive (I hope) and has more guidance.
- Part of the app, when wallet is created is redesigned.
- Analytics was completely removed per community request
- Default Ironbelly node was changed to
- Small UI / UX improvements
Right now I’m concentrated to bring TOR and Grin addresses to iOS, later to Android. I’ve decided to start with iOS, cause Grin++ team is working on bringing it to Android first, hence Grin community could have earlier Grin addresses support for both platforms.
My pace is currently somewhat slow because my laptop got broken recently and I’m using my old laptop till it gets fixed. It is not really good for this type of depelopment, though, but do not worry, I will compensate for this time later and even after my funding period will be finished. I’m still commited to deliever the features I’ve decribed in the proposal till the next Hard Fork.
Thanks for reporting bugs and submitting feedback!
I think the primary innovation here for grin is to be able to send slatepacks over animated QR codes (https://github.com/divan/txqr). Almost every phone has a front-facing camera, so the transport medium is there. This could be easier than juggling files on phones.
As a user, I’d expect that if I point my front-facing camera at another phone, the two phones would able to communicate by reading each-others animated QA codes. The phones will vibrate to give feedback once the interaction is complete.
Why not NFC as Apple Pay and Google Pay?
Cameras are more ubiquitous.
NFC would be great for devices that support it. I would develop the QR scanning first and then NFC second. Admittedly, NFC would be the most ideal user experience.
So, it’s time for another update!
Last couple of weeks I’ve been working on adding Grin addresses to Ironbelly. I’m glad to share with you all that now it’s working on iOS and Android support is coming very soon!
Right now I’m polishing a couple of edge cases and after that is done I will release 4.1.0 with Grin Addresses support for iOS.
Here is a sneak peek: https://streamable.com/s53vgz
Nice job, looks great @i1skn!
How do Grin addresses work? I’ve not been keeping up. Doesn’t grin require interaction? So how does the address work (is it a tor address)?
Take a look here
Hey everyone, it’s time for another update!
As of now both Android and iOS latest versions support Grin Addresses and Slatepack
Besides there is a couple things I’ve packed into the latest release as well:
- Automatic background update of the transactions state, so no need to pull down manually!
- Android should have a slightly faster Fingeprint unlock mechanism.
- Implemented automatic screenshot taking before each release (Apple rejected a build recently because the screenshots were not up to date)
- And as always minor cosmetic lift-up and optimizations
Here is my current roadmap:
- Bring QR codes for encoding Slatepacks and Grin addresses (should be in the next release)
- Introducing PIN instead of a password, which would allow to increase level of security and create a better UX for unlocking.
- Ability to change PIN
Also, I’m planning to release version 5.x of the wallet with a complete support of the upcoming hardfork on time!
After the upcoming hardfork Ironbelly would not support http and file transactions in favor of Grin addresses and Slatepack.
Keep going! Ironberry’s first mobile phone Wallet
Hi everyone! It’s time for another small update!
While new 4.2.0 version of Ironbelly is rolling out to the stores, I wanted to share that it has full support of QR codes for send and receive using both Grin addresses and Slatepack. Also, QR codes are fully compatible with the new Grin++ Android wallet, so you should be able to transact between these two without problems!
Next stop is improving security and unlocking experience!
Stay tuned, cause we are running a marathon here, not a sprint