Monthly Archives: August 2018

Yen: Binance… and Your Whole Wallet…

One of the fun things that we get to do is explore, very vigorously, the many available APIs that the cryptocurrency exchanges and one that we’ve been working on recently is Binance.

Now, obviously, we want to do this for a number of reasons… the first being that it’s the largest exchange on the planet… and that’s a good thing as we want to have our users be able to exchange and transact as much as humanly possible.

So, it was super-interesting to find out that Binance will spit out your entire wallet on every single call to their API. You can see a screenshot of the output below:

Now, why in the hell would they do that? I honestly don’t know. But, it’s interesting. They obfuscate the username and anything that could clearly identify the user (which is good hygiene and good security) but even if I buy a few dollars of a single token via their API (which we’ve been able to accomplish in our prototype) you get the entire dump of the user’s wallet.

The question, of course, is what one is to do with all of this information as there is a lot of data there. This is where things can a bit exciting, actually.

Imagine if we were able to make recommendations to you as to what you should buy based on your existing portfolio when compared to thousands of other users who hold similar tokens, coins, and values associated with?

If we recognized that you hold BTC, LTC, and Ethereum with about $10k in each with an average gain of 20% month-over-month but notice that 1,000 other users have similar wallets but alsohave ICX and, consequently, have seen a 40% month-over-month growth (assuming you have similar trading interests and investment amounts) we could strongly suggest to you to look into ICX as a diversification strategy.

If that sounds overly complex, then, yeah… it could be… but, it doesn’t have to be that way. I believe that Fantasy Football (and Fantasy Sports Leagues) do similar things in their suggested actions (recruiting new players, trading, etc…) based on network effects and user preferences.

Anyways, Binance likes to share your entire wallet. If that’s uncomfortable, then, well, now you know. And knowing is half the battle…. GI JOE.

– john

Yen: Making It Come To Life

The process of building is difficult and sometimes downright stressful… but it’s also incredibly rewarding as well, especially when your paper-napkin sketches somehow, eventually, evolve into something usable.

As you can see above, a low-fidelity concept of one of the group pages. Below, you’ll see it fleshed out with a bit more color:

(This isn’t final, of course…)

The simple experience of seeing something come to life is always fun and exciting.

Next up… coding this part of the app. Groups is going to be a huge part of the product and we can’t wait to really sink our teeth into the architecture and components.

We can’t wait for you all to create your own groups…! It’s coming along folks… 

– john

Yen: You Can’t Have Both… At Least Not Yet.

Some of the larger (and very exciting) challenges that we’re bumping up against are how to best present the data that we all will be creating every single day on this new social network.

And, our technical goal (singular) is very simple and straight-forward: We want to make our experience fast as !@#%.

To do this well we need fast and reliable architecture and a lot of this comes down to some very important choices early on. For instance, one of the very classic technical issues that social networks have to work through is what is called “The Bieber Problem”. 

Essentially, in the early days of Twitter, Facebook, and others, if a celebrity like Justin Bieber updated a handful of times in quick succession, it could take down the entire network.

This is because he had millions of followers and each person that was following him was immediately presented with a new data set (e.g. update or post). Do this a few times and you get a massive data issue.

The architecting of feeds, consequently, is of paramount importance (and this is partly why decentralized protocols can’t manage this at scale… at least for the time being).

More specifically, do we display data on “write” or “read“?

If Charlie Lee buys some Litecoin (or, *gasp*… Litecoin Classic… … …) do we present that information instantaneously on all of his followers feeds (on “write”) or do we wait for the user to refresh their feed and then pull the update from the data structures (on “read”)?

Twitter, at least in the beginning, was a “write” type of system and architecture. Facebook, in contrast, has a more algorithmic and weighted feed and does “read” (although both are now pretty heterogeneous). 

If you’re curious about these types of things like “fan out on read” vs “fanout on write” then you can read this seminal piece by Yahoo!:

In any case, these are the things that Peter and I are thinking through every single day as we build and it’s important to note that, for us, it’s more important that we have an amazing user-experience first and foremost before we begin to apply technically-heavy decentralization protocols that could easily reduce a successful encounter with the app.

An aside… I get a good laugh when I hear of other “crypto social networks” tout their decentralized infrastructures because there is no way that they’ve even thought through the user experience vs scaling debate, at least practically-speaking.

There just isn’t a good solution… at least not yet. You compromise. You trade one for the other. Either you wait a few days to see your update post or you see it immediately. I prefer the latter.

– john


Notifications are something John and I have spent more than usual suffering over. 

We want to make sure that there is enough contextual relevancy when you see a notification. 

Which allows you to actually take action.

We don’t see this time spent as bad, we just want to make sure everything we do is awesome.