SpankChain Development Update 006 — January 31, 2018
Payment Channels
Payment channel development is moving forward. We have started working with the Kyokan team to upgrade the core Machinomy library and get it ready for production, and also to help with SpankWallet (formerly Vynos) UI development.
Mobile Payment Channels
In case you missed it, we announced our support for what we believe is the best Ethereum based mobile wallet (and web browser) out there, Cipher Browser. We extended a $300K open source development grant to Pete Kim to continue developing CipherBrowser and to assist in integrating our payment channels wallet in the near future.
CipherBrowser has quickly become our new favorite toy here at SpankChain, and at AVN this past week we were super excited to onboard all our adult industry friends!
SpankWallet Design
The SpankWallet will be the first Ethereum wallet with support for payment channels. As we demonstrated in our tech demo, it allows users to interact with our Payment Channel contract and make signed off-chain payments to our SpankChain Hub.
Getting the experience right the first time is a critical component to our infrastructure since it fundamentally changes how we interact in the adult space. In place of the status quo credit card based systems and fee structures for each website, users with a SpankWallet will be able to immediately start using and making payments on the SpankChain platform with limited setup, and thereafter to our partner sites, such as TrenchcoatX and beyond. The user’s Ethereum address with an option username on top is their identity, as SpankWallet acts as a passport to the entire SpankChain ecosystem.
Below we will walk you through a user onboarding flow:
Streaming Video
Leading up to AVN we conducted several test of our streaming system. Most of our initial testing with the community revolved around WebRTC. For the AVN awards, we ended up using our RTMP → HLS implementation:
Our RTMP → HLS setup uses OBS Studio to broadcast an RTMP stream to an RTMP encoding server that trancodes the stream to HLS. The HLS files are then stored on caching servers (CDNs) that serve the static video files. This setup produces quality results and we are looking to see how we can optimize for scale as well.
We eventually chose to stand-up a live streaming stack using RTMP/HLS. As you all noticed our HLS stream quality was significantly better and was able to scale to hundreds of congruent streams. The total viewing Time of the stream was 52 d 12h 17m with an average viewing time of 20m 19s.
As soon as we got back from the AVN awards, we hit the whiteboard. We have brought in video streaming experts and we’re working with multiple vendors to make sure that our video streaming platform is robust and scaleable, and most importantly that it has the highest possible quality.
In the above session we were focused on questions like:
- What are the trade-offs regarding video latency vs quality for RTMP/HLS and WebRTC? How do these trade-offs affect scalability?
- What strategies could we use to optimize either of those protocols (for example LHLS, or cascading WebRTC)?
We’ll let you know what we discover in our next dev update!
Connect with SpankChain
For more information about the SpankChain project:
- Check out our white paper
- Watch our introduction video
- Follow us on Twitter
- Join us on Discord
- Subscribe to our subreddit
