Blockchains need to be mobile

Lack of mobile access is the biggest hinderance of adoption in the blockchain space right now. Status is a group that’s got the right idea - so many incredible ICO’s and protocols being built, but at their core they cannot serve a world that is mobile first. 

There’s a couple reasons for this -

  1. Frankly, we cannot reasonably scale to a mobile, global world (a good thing right now). Lightning network, sidechains, sharding, proof of stake.. We’ll get there.
  2. P2P transactions on these new protocols are impossible in the iOS and Android stores. The apps that offer services (Coinbase, have centralized servers that serve as a central point of failure.

As an iOS developer, I want to be able to download a library that gives me the ability to create a decentralized app using any blockchain I deem useful. I don’t want to depend on a centralized service to be the payment processor. I don’t want the responsibility of managing wallets, security, auditing, KYC etc. 

The question is, how can we enable Decentralized AirBnB, Decentralized Uber, Decentralized Tinder or Decentralized Soundcloud; By decentralizing would bring costs down for the customer or money into the pockets of the creators?

This is a problem that my friends and I have been deeply thinking about solving. We’re starting with one basic fact - Any mobile device can sign and send a transaction over HTTPS. Client security is incredibly important, but should any security leaks happen, it will be contained to the device itself.

I’ll continue writing about this as we flesh out the model a bit more deeply, but we’re excited about the possibility of enabling the ability for any mobile developer to create a decentralized application in today’s existing infrastructure.

Getting Started With Ethereum

I've been interested in the cryptocurrency space since I read Satoshi's white paper about 4 years ago. I was mainly an observer and hodler while being generally excited about all the amazing things the core developers were producing. I remember being at the Bitcoin Miami Conference in 2014 and watching the announcement for the pre-sale and thinking to myself, "This must be some vaporware scam". That was not uncommon at the time (Side note - incredible to see how much the industry has matured since then!). 

When I learned to program a little over two years ago I gained a new appreciation for Apple. The ease in which someone with zero coding experience or technical knowledge can get a basic app running on their phone is pretty incredible. I believe this went a long way in the incredible growth for the language for new and experienced developers alike. It's a big reason why I believe Chris Lattner when he talks about Swift's world domination plan.

To be fair, Ethereum and cryptocurrencies in general are far from Swift/Xcode levels of drag and drop simplicity. That being said, when it comes to getting your hands dirty, creating meaningful code and seeing the results quickly the Ethereum community is leading the way. In the spirit of this, I'd like to share the resources that I've come across that have been most useful for me in learning over the last month.

I'll be under the assumption that you know how to work your way around the Terminal and are familiar with how cryptocurrencies work at a high level. 

  • You need to explore the and Solidity websites first. They have great documentation with code to copy pasta and use yourself. I want to highlight the create your own cryptocurrency page in particular. Reading through that really helped me understand how Ether and gas are used to create and send custom Tokens. 
  • So you've read through all the docs and have an understanding on with how Solidity works. What next? I learn quickest by watching videos - I've watched almost all of the create your own token Youtube videos. By far the most useful one I watched was Jordan Leigh's two part video called Introduction to Ethereum Smart Contract Development With Solidity. You get a great primer on having a good workflow for developing DApps along with great random pieces of information.
  • On his Youtube page Jordan has a few videos that end up linking to a website where he created a web series that you need to pay 3 Ether to have access to the entire series. They are fairly short - between 7-15 minutes each. He flies through the content so between pausing sometimes it would take me up to 45 minutes to finish a video. It's useful content but 3 Ether seems a bit pricey for me. He also says he'll do 20 videos (10 are up) but I'm not sure what his timeline for following through with that is. Using Metamask for the first time is a cool experience as well.
  • You've started coding and compiling your Solidity contracts and having issues debugging? Etherem Stackexchange has already been invaluable for me. You should read through the most popular questions and answers too. I've been lurking there hoping there are questions that are simple enough for me to answer, but have not completed that quest yet.
  • The advanced examples on the website are incredible and mind blowing. The series from Jordan pointed me there and it's one of the best resources for advanced contract building you'll find.
  • It's important to keep up with the community and for me, Twitter is the best way. I am extremely excited for Casper to finally be released. I have curated a broad cryptocurrency list with almost 300 people primarily from bitcoin and Ethereum. If you don't want to deal with the noise (there is a lot) I recommend subscribing to my Nuzzel Newsletter or curating your own. Nuzzel is an amazing product and the newsletter shows the most shared links on a given Twitter list so you won't miss much.

These are all the tabs I have open when I'm in Ethereum mode. Feel free to reach out on Twitter.


Figuring out on-boarding for your product is hard. It’s the first time someone experiences it and first impressions matter. It’s one of the things we keep coming back to — I believe that it’s one of the most important parts of an app. It’s in those first 30 seconds or so that you need to convince someone that there’s a reason to come back.

Building a social network, some of the factors that my team and I have talked about are —

  1. How long should the on-boarding process be?
  2. Where are they at that moment they download?
  3. What kind of investment do we ask of our users to give them a reason to come back?
  4. How are they feeling? Are they sober, drunk, sad, excited?
  5. How much do we teach them about what we think makes TimeSet special?
  6. Should we encourage them to create content for us right at the start?
  7. Do we emphasize our network, and the people using it?
  8. Should we encourage them to subscribe to BucketLists and/or follow users?
  9. How much does the user know about our product when they download it?

So far we’ve tried several things with our on-boarding. At first it was a simple sign-up. No real on-boarding process, but when you reached the first screen we had some quick tutorials pointing to various parts of the app that you could read or tap through.

We realized we weren’t asking anything of our users when they first logged in — so we decided to go to the opposite end of the spectrum.

Our core functionality is taking a photo to complete a goal in a BucketList. We created an elaborate explanation of what a BucketList is, and heavily encouraged our new users to post to our “On-boarding BucketList”. It had 3 goals:

  1. Take a photo of what’s in front of you
  2. Take a screenshot of your home screen
  3. Take a screenshot of what you’re listening to

We assumed that because these were such simple, easy goals that it wouldn’t be too much of a hurdle to complete when someone is using the app for the first time.

We were wrong.

We noticed immediately that encouraging someone to post to a social network that they know nothing about, with no understanding of the context or consequences of that post was a bad idea. It was too much of an ask. It made people uncomfortable, and many times said, “Wtf why am I being asked to post something?”. So we axed it and went back to the drawing board.

Our next iteration will be much more simple and much less of an investment for new users. We don’t have many users, and our strength is the small network that we’ve created. Most of us post every day, and check the feed constantly.

We asked ourselves,

We ARE a social network, so why don’t we bring users into ours? They can see the awesome, funny stuff we post and feel like they are a part of a community right when they log in.

It made sense after 2 other tries of messing it up. In our next update, when a new user signs up we will show them two screens:

  1. One of our most popular, active and interesting BucketLists where they tap subscribe to the ones they are most interested in
  2. Our most active users, where they can tap follow so their posts populate the feed as well

On top of this, when a user visits or creates a BucketList for the first time, we will play a quick tutorial that is easily digestible and highlights the core functionality of a BucketList. We believe this approach provides several benefits to a new user:

  1. Most importantly, it highlights our community of people posting who have created interesting BucketLists.
  2. It allows their feed to be populated with goal completions and posts right from the start.
  3. Subscribing and following are familiar, comfortable actions.
  4. It gives a new user a reason to come back a few days later when someone has completed a BucketList (We send a notification when someone has completed one for the first time).

We hope that this new on-boarding will increase the odds that a new user “gets” TimeSet, regardless of where they are experiencing it.