The Problem
My journey into crypto began from an outside and frontend experience. I’m a farmer turned photographer turned designer turned frontend engineer turned fullstack engineer. I’m also a serial entrepreneur always dreaming up my next big thing and trying to explain its glorious ins and outs to my less interested friends and family.
Bridging the gap between the technical and the usable, the doable and the needed has become my full time job in all the other small tasks I find myself busy about day to day.
Nowhere else have I found the contrast as strong as in crypto. I adore this space, it’s energy and potential, the fire around the ideas and the dangers lurking around every corner. Yet too nowhere else have I found such a tremendous gulf between where I work and find my interest and where normal everyday people live. Often it’s a seemingly hopeless divide where conversations most often end abruptly with myself being written off as a risky money hungry idealist probably contributing to an apocalyptic one-world-order and myself frustrated with the amount of stubbornness, misinformation and arrogance around a topic they are truly uninformed in.
My battleground for this divide though has most often and strongly been side project applications, and most specifically Stellar application entries in their build challenges. Here I’ve found my place to explain the ins and outs of the technology and use case through services like BillingFox, games like Colorglyph or even low level tools like the a GraphQL interface for Stellar’s Core and Horizon PostgreSQL databases.
All of this work, problem solving, explaining and shipping has greatly helped in my ability to both understand the concepts myself but also to explain them to others. However for me there remained one large obstacle. Onboarding. Getting users, moms and dads, sisters and brothers, friends and family connected with their own Stellar accounts able to really consume crypto services in a much more intimate way. This is a huge problem for crypto right now, it’s in a very infant, low level stage where access to the network requires a lot of due diligence that frankly very few people are qualified or competent to handle. The sad thing though is that there really aren’t many options for us, it’s very much a “too bad so sad” atmosphere out there. Good luck and hope you don’t screw up. Fear and poor practices abound and the unsuspecting user is just so incredibly likely to get it wrong at one point or another.
And that’s just for the average Joe Shmoe on the street. App developers don’t have it much better. Do you ask users to bring their own accounts and be responsible to store their own secrets safely? Do you yourself create, maintain and manage an ever increasing number of accounts only too mess up one day perhaps even through no fault of your own? Negligence abounds and especially for the solopreneur or small team mistakes are bound to happen. However the data you’re dealing in must be treated better. There are lots of ideas, solutions and proposals out there for how best to handle these problems and I too have given it a lot of thought and energy. Today I’m happy to reveal a collection of code which I will be implementing into an upcoming revision and rebuild of Colorglyph which aims to elegantly and definitively solve the problem of onboarding my users directly into the Stellar platform.
The Solution
My answer is really quite simple. Offload each responsibility in question to whomever is most qualified to handle it. This shifts the whole problem then from ensuring those parties which are not qualified to not get things wrong to clearly identifying responsibilities and then appropriately assigning them to the most qualified parties.
This idea is nothing new, in fact you’re already implementing a lot of this logic into both your daily lives and any applications you already maintain. I don’t grow much of my own food or own a coffee plantation, I offload that responsibility to those qualified like farmers, Starbucks and Aldi. Neither do we expect our users to process their own credit card payments nor do we often directly do that ourselves. We use services like Stripe or PayPal who are far more qualified to deal with that complex problem.
My proposal is simply to follow suit and offload the responsibility of crypto account management to a service qualified to do so. For me that would be Auth0, my goto solution for all things identity and security. I already use them exclusively for application onboarding through their Lock service, why not simply extend that functionality to encompass Stellar account creation, maintenance and management. Seems obvious enough but as there are no off the shelf solutions for such an addon service one had to be concocted from scratch.
Introducing StellarAuth
At first blush this may not seem super special but believe me, this is huge. Allow me to explain.
TL;DR
- User authenticates via Auth0
- Login triggers a Webtask to generate a Stellar account and assign it to the authenticated Auth0 user
- User action (Clicking “Verify Account”) triggers another Webtask in which a Stellar account creation transaction is posted which will create and fund the new account
- User is now free to send transaction XDRs (limited to medium threshold operations) from the client to another Webtask which will verify account ownership, sign and submit the XDR to Stellar. Notice there is an additional Authy 2FA step to submit transactions. This step isn’t strictly necessary as the account is fully secured but as an extra measure and good practice for this example it is enforced.
TS;WM
There are a lot of smaller details within both the client and server side of this solution which are very much worth noting and which I will write about at length in a part 2 of this article in the coming weeks. For example how is it I’m able to manage seeming fee-less transactions from the client account? Stay tuned.
