SpankChain Development Update 007 — February 27, 2018

Published in

SpankChain

8 min readFeb 27, 2018

February was a productive month for the SpankChain team and community. We grew our contributing team to 30 people, launched our first dApp (CryptoTitties) and made a great deal of progress on the camsite. We’ve also been quietly building the most advanced state channels implementations on Earth. For this update we will cover the following:

Team
CryptoTitties
Camsite
State Channels

1. Team

To deliver on our ambitious roadmap we’ve been aggressively scaling up our team with a focus on working with the most talented engineers we can find. We are proud to announce that in the 3 months since our token sale, we have grown our contributing team from 12 to 30 people, with 20 of those being developers. We aim to maintain this team composition moving forward.

Now, not all of the 30 people are officially full-time SpankChain employees. This figure includes Dr. Alex Gouaillard (who helped build WebRTC into Chrome and Safari as part of the W3C working group) and 3 engineers from his consultancy, CoSMo, who we have contracted to build our video infrastructure. It also includes 3 engineers from Kyokan who most recently rebuilt Metamask, making them the most qualified in the world to build the SpankChain wallet. In a time when most teams are having trouble finding even a single competent developer, we consider ourselves lucky to be able to hire entire engineering teams who are dedicated and passionate about our mission.

We may come from different lands, but we all fight for the same cause.

2. CryptoTitties

The CryptoTitties launch has been an enormous success to date and shows no signs of slowing down. There have been 59 pairs of tits uploaded, 22.3 ETH tipped, and over 10,000 hits on the site. Performers have also been using it ways we didn’t foresee, such as selling their premium content through the site and giving away the proceeds to charity.

Overall, we feel that the overwhelmingly positive response has validated our hypothesis that “if you want people to learn about cryptocurrency, the easiest way to instill interest in learning is by giving them some.” To that end, we encourage everyone to continue sharing the gift of crypto with the SpankChain performer community.

3. Camsite

As most of you know, our Camsite has three main components: the webapp, the video, and the payments. Judging from our current development pace, we’re confident that we’re going to hit our early April launch target.

Webapp

After sitting down with a number of performers to discuss their favorite features and camsite must-haves, we crystallized the core features we wanted to include for our launch. One of the most important feature requests we received was making the room goals more progressive and modern so performers are better able to gamify the experience.

The performer can set up their camshow goals through our simple interface.

Another feature we’re working on is to add “previews” to our discovery page so users who hover over performer camshow thumbnail images will see the video come to life. Most sites have this feature, but what they don’t have is a smooth transition to the camshow video when the preview thumbnail is clicked. In our case, a lower resolution stream will start playing instantly when the thumbnail is clicked while the high resolution stream loads in the background.

Video

Our quest is to ensure that video streaming on our platform is robust, scalable, and most importantly — the highest quality possible.

Last month we used a RTMP/HLS setup during our AVN Livestream due to the increase video quality we were able to achieve compared to WebRTC. While HL increased the video quality, it also increased the latency to ~20 seconds, making it in our minds, obsolete for the experience and quality we are trying to achieve.

After hitting the whiteboard and bringing on the aforementioned team of video experts we’ve changed our tune, building a “cascading WebRTC (FSU)” infrastructure with an initial target to support up to 5,000 simultaneous viewers per stream.

Now, we know that the RTMP/HLS latency can potentially be reduced to somewhere in the neighborhood of 2–4 seconds with techniques like LHLS, but we believe that this amount of lag is still too high. For a highly interactive medium like live cams, getting immediate feedback from performers in response to tips and messages is critical to the user experience, so our aim to get latency to under two seconds.

We actually started down the LHLS route but it requires significant re-work on the server and the client, and a custom/proprietary client is not something we are interested in building and maintaining. Also, since WebRTC is already implemented in mobile Safari, it is only a matter of time (iOS 12) until webview support — looking at you CipherBrowser (Android support is already there). We plan to maintain HLS compatibility for legacy devices but the future is WebRTC.

We appreciate the community in helping out with video quality testing in the past but we know that this isn’t scalable. So alongside the our video implementation, we have also been working on infrastructure verification tooling. This is where KITE comes in. KITE is an open source, industry standard compliance tool which we are extending to support load testing and benchmarking.

We have been laser focused on shipping but it really comes down to creating the best user experience possible (who cares about shipping crappy products) so sometimes it is the little things that make a difference. We are excited to be innovating on instant thumbnail previews and “no load” live shows. Stay tuned for more!

Payments

The UI work for the SpankChain wallet is nearly complete. We iterated on our initial designs to provide better support for payment channels and settled on the SpankCard as a metaphor for the viewer’s payment channel with the SpankChain payment hub.

Everyone understands how payment cards work—you deposit money into it, you spend the money, and when you’re finished you can withdraw any remaining funds. Payments channels work basically the same way, so viewers need only concern themselves keeping their SpankCards topped up and tipping generously, not having to unnecessarily learn what payment channels are and how they work.

1. The viewer has funded their wallet, and now wants to load up their SpankCard (open a payment channel).

2. The viewer has successfully loaded up their SpankCard, and can now tip instantly on the site.

3. The viewer can also load up their SpankCard with additional funds as they go.

4. The newly deposited funds have been received and the viewer can continue watching and tipping!

5. The viewer can see their SpankCard activity broken down by camshow.

6. The viewer can zoom in on a specific camshow to see specific tips they made during the show.

In order to properly display tips, we came up with a payment metadata format to tell us what each payment was for. In the future, we plan to extend this to interoperate with payments received on behalf of our partnered merchant sites.

The code for the SpankChain hub is also mostly complete. We have implemented server-side authentication, endpoints to receive and verify payments, and also proper accounting so we can track performer earnings.

The next steps are to write front-end unit tests, end-to-end integration tests, and build our internal admin dashboard from which we can manage our hub and open payment channels.

4. State Channels

No joke, we actually have been building the most advanced public state channels implementations in the world.

At the beginning of the month our state channels dev team got together and iterated on a few designs for a general state channel framework which could be reused across various state channel implementations. This is important because right now, every time we want to deploy a new state channel implementation, we have to deploy all new contracts, which means more locations for funds to be held, a greater surface area for bugs and attacks, and expensive audits. Because we plan to rapidly upgrade our payment channels to support tokens, be bidirectional, and support atomic multihop transfers using hashlocks, we realized our lives would be much better if we had a single contract which would hold funds across all our channel implementations and act as the backbone for all our new channel deployments to connect to. So we started building it.

Not only did we build the general state channel framework and PoCs of unidirectional payment channels, bidirectional payment channels, and a cryptokitties battledome, but we also built something that until last week, had only been theoretical.

We’re proud to announce that we’ve built the most advanced public PoC of counterfactual instantiation on our general state channels framework. Counterfactual instantiation is a term coined by L4 and is used to describe the process of two parties in a state channel agreeing to be bound by a smart contract that doesn’t actually exist on the blockchain, but could be deployed in case of a dispute. What this gives us is the ability for two parties in a single state channel to enter into and exit out of any number of “sub-channels” governed by specific smart contracts without ever going to the blockchain at all. For example, I could open a state channel with the SpankChain hub, move some of my funds into a unidirectional payment sub-channel, and then when it comes time to upgrade to bidirectional channels I could exit the unidirectional channel and enter into a bidirectional channel, all offchain.

It’s hard to overstate the importance of this technique; being the first to master it will give SpankChain a significant advantage as we iterate through and upgrade our state channel deployments.

We’re incredibly grateful to the L4 team for their tireless research and look forward to collaborating with the greater Ethereum community to put general state channels and counterfactual instantiation into production.