2021 is coming to an end, and we are still silently building like we used to, from software, hardware, to product design; we are hard at work and got it all covered. BUIDL. BUIDL. BUIDL., as we say it in the space 😉 🔨 We owe you guys some updates, so here’s a recap of what we at Ryder have been working on the past quarter, what are we currently doing, and what’s in store for 2022. This might get long, so be ready! We hope that this update will give you, our maker community, the chance to understand what it’s like to be more involved with an organization like Ryder and hopefully, inspire you to come a board and contribute to our maker community.

As you may have noticed, a big chunk of Q3 has been spent on understanding the needs of an average Ryder user. We took a lot of time defining the commercial specification, which includes product positioning, device overview, projected end-users, technical lifetime, ecosystems, functional and mechanical features, technical protocols and standards, environmental conditions, projected unit packaging, distribution form, and more. At first, this can sound like a low-lifting task, but it isn’t; we underestimated it and took a lot of back and forth. The question is, do we want the first-time-right or second-time right for Ryder? The commercial specification will be released publicly as soon as we are able to do so.

Now to give you a scoop on how defining a Product Commercial Specification Document works, every idea that I, Marvin, Kiki, or a community member like Niclas suggest (maybe secretly love) gets beaten down into pieces by the hard logical facts of hardware reality. We all know that hardware is very different from software, not only for the apparent fact that we are dealing with something physical but also due to the design decisions that need to be made and carefully considered. By the end of the day, we need to weigh the pros and cons as there will always be drawbacks in every design decision we make. The most challenging decision is making a product that combines usability and security without sacrificing one over the other. As we felt that we were taking a lot of back and forth, we remembered that it would be best to return to our north star. Does this decision bring crypto to the masses? This approach helps us prioritize and choose features we believe will help us achieve our mission.

Hello on the Stacks Blockchain.

The most important technical milestones for Q3 and this quarter are firmware support for transaction signing and transaction decoding. Q3 marked the first steps of Ryder into the on-chain world. The first on-chain transaction signed by a Ryder prototype was broadcast on October 14th 2021, as seen on the STX explorer. But being able to sign does not get you all the way. Ryder firmware 0.0.4 can decode token transfer payloads, which is required to show you just how many tokens you are sending where. Kind of important! For those curious about the details: this includes turning public keys into Stacks addresses by means of an algorithm called Crockford’s base32. Stacks uses a unique flavour of this algorithm to generate STX addresses.

All well and good, but it is more fun to see it in action. Here is a video of Marvin sending a token transfer transaction to the Ryder, signing it, and receiving it back.

Firmware 0.0.4 can be tried out today! If you are a dev and you want to play with it now, upload the latest firmware to your Ryder prototype or download the simulator if you don’t have a physical one yet!

• send-stx CLI command draft PR: Light-Labs/ryder-cli-proto#10

• Firmware 0.0.4: https://ryder-proto-v2.ryder.id/pioneer/

• Simulators for 0.0.4 (Windows build coming): https://ryder.id/blog/ryder-q22021-recap/

While the firmware should sign all types of Stacks transactions, we are still working on contract call decoding; as you might have guessed, that gives Ryder the ability to show which contract you are calling and how. You should see the feature arrive in version firmware 0.0.5, which is also scheduled to be the first open-source release.

But that is not all! We want to make interacting with apps more straightforward and intuitive. We are excited to share an early concept of a feature called App Screens. Dapp interactions are composed of more contract calls that make something happen. For example, you might send a transaction that swaps one token for another on ALEX. Instead of showing a rather technical contract call with parameters, would it not be great if the display extended the app user experience? That is exactly what App Screens will do! Specific app contract calls will be turned into custom transaction screens that immediately determine what you are about to do.

Naturally, the details are still important and will be easily accessible and verifiable. You will be able to install App Screens for the apps that are important to you. Another upside to using an App Screen is the ability to more easily detect impostor apps, as App Screens are displayed based on the combination of the contract address + contract name + function name called.

There are a few more technical challenges that we are hoping to address soon, such as refactoring authentication to make it work with the current Connect of Stacks and working on a few minor bugs for the Windows 10 Simulator of Ryder.

In the meantime, here are some working concepts (subject to change) on Ryder’s Sending a Transaction.

Sending Transaction on concept Ryder Phone Application

Concept Ryder Phone Application waiting for transaction verification from Ryder Device

Ryder Confirming Transaction received from Phone Application.

Design is at the core of Ryder and it has been more apparent this quarter. By creating Ryder’s Product Commercial Specification, we further understood the current challenges of its existing form-factor. We, however, have done our best to keep to the belief that design will be one of the critical ways of bringing the interest of crypto to a whole new type of user as usability is our number 1 priority.

In terms of where we are and where we are heading, we are proud to say that we’re more than confident that we can bring Ryder to life as all the pieces are coming together. Various areas of development are happening in parallel. This means engineering for both software and hardware goes side-by-side with product development. John, who’s our technical consultant, is currently doing the technical documentation, which will be finished in two weeks; this will be the initial technical vision for Ryder where we see the device functionality and pre-select device components for manufacturing. From here, we have Kiki’s design which is subject to iteration based on the technical vision. We’re targeting end of Q12022 for the Ryder Devkits! We’re also in the process of vetting a few design houses that can help Manufacture Ryder, which will enable our team to bring Ryder to market faster and more reliably.

Thank you for following along our journey, we personally cannot wait for the stuff we have in store for 2022. If you’re keen to be a contributor please do not hesitate to reach out and join our maker community. 😉