1. Library
  2. Podcasts
  3. Demuxed
  4. Ep. #7, Live Video Streaming with Blockchain
Demuxed
43 MIN

Ep. #7, Live Video Streaming with Blockchain

light mode
about the episode

In the latest episode of Demuxed, Eric Tang of Livepeer joins Matt, Steve and Nick (filling in for Phil) to discuss how blockchain is creating new possibilities for peer-to-peer live video streaming. Eric describes how Livepeer uses a token system to incentivize increased capacity and network performance. He also explains how decentralized video streaming networks can change the way content creators interact with their audiences.

Eric Tang is founder of Livepeer, a decentralized video live streaming network based in NYC. Livepeer is based on peer-to-peer networks, and nodes that provide capacity are paid for with Livepeer Tokens, the network’s own cryptocurrency. Before starting Livepeer, Tang was co-founder and CTO for Wildcard, a mobile web browser replacement, and a lead engineer for Hyperpublic, a location-specific, open database acquired by Groupon.

transcript

Matt McClure: Hey everybody, welcome to Demuxed again. Phil couldn't be here today, unfortunately. He just bought a new house and is in the process of moving, so apparently all of his recording stuff is still somewhere in a pod or storage room. So, I'm sorry Phil, we still love you. But as a stand-in today, we have Nick Chadwick.

Nick Chadwick: Howdy.

Matt: Been working with Nick for five years at this point, in some way. With a brief hiatus.

Nick: Brief hiatus.

Matt: Brief hiatus.

Nick: I was technically born in England, too, so I think I'm a fine Phil stand-in. I also want Phil to know that I just moved houses and I didn't lose any of my recording equipment. That's because I don't have any.

Matt: But Nick is probably the best live-video streaming source of information that I have, so Nick is going to be our curmudgeon from the traditional live industry today.

Nick: Cur-mud, I like that term. Yeah, I'd say I did some live stuff at Zencoder. Did some live stuff at Brightcove. Did some live stuff at Twitch. So, yeah, I'll take it.

Matt: Nick Chadwick, by the way.

Steve Heffernan: He's also got the accent so it keeps the legitimacy of our podcast up a little higher.

Matt: Absolutely, yeah. Can't have the accent score fall too low on any given episode. Today, now that we've gone through all of that, today we have Eric Tang from Livepeer. You want to give us some information, Eric?

Eric Tang: Yeah, sure. I cannot speak in a British accent, so I'll stop right now. I'm from New York, and Livepeer's an open-source project. I've been working on this for about a year. Before that, I've been working in the tech industry for about 10 years.

Worked at some startups, started a couple of companies before. Had a short stint in San Francisco because one of our startups got acquired by Groupon. And so I've worked here for a little while and then moved back to New York.

Matt: So yeah, let's start off with a little bit of basics on what traditional live looks like.

Nick: Sure, let's roll back from traditional live. Because traditional live is like a broadcast system going to your television. That's not what we're talking about today, right? We're talking about traditional live-streaming-over-the-internet infrastructure.

You've got some camera, some giant setup or a small setup. But ultimately, the traditional internet video protocol for ingest has been RTMP. So you're going to take some source of video, some source of audio, and code them into H264, AAC, put them in an RTMP stream and send it somewhere.

Traditionally, RTMP servers like Red5 or Wowza, or even Nginx if you're into some of the more open-source stuff. There's a few different things out there. Then up in the cloud somewhere, on somebody else's computer, you're going to run a transcoder. We've kind of moved away from RTMP as a broadcast protocol over the internet and nowadays everyone's using something like HLS or Dash, which are segmented live formats.

You're usually going to use a few different rendition qualities to allow people to smoothly switch when their bandwidth can't handle the current quality that they're streaming at. So server side we've got to do a bunch of work to get that one input stream into a bunch of different output formats, occasionally different output bit rates and resolutions. And then that's served over something like a CDN.

Traditionally you'd send these files to Akamai or something like Fastly and then deliver that to your end users as a stream. If you're looking at something like Twitch, they might use their own CDN or have their own ingest servers or something like that.

But the high-level is the same. You have some unique identifier for your stream that lets you broadcast. Then a little bit of infrastructure around it that also monitors whether or not the stream is currently live or not. And then HLS or Dash, and a player. And that's kind of the state of the art right now for live streaming over the interwebs.

Matt: Well put. In some of that, already today we've seen some people start moving to peer-to-peer delivery or hybrid peer-to-peer delivery. Some people even touched on it yesterday during Demuxed, companies likes Streamroot and Peer5 are touching on that. I think even some bigger companies have started exploring this space as well. So, what is peer-to-peer delivery? And how's it being used in the wild right now? And how do you see that transitioning in the future?

Eric: I would say peer-to-peer delivery's actually not a new concept. We're seeing a resurgence of that in the past few years. The peer-to-peer technology wave really started back in the 2000s, I would say BitTorrent being the biggest one. And during that wave of technology we saw a lot of really interesting peer-to-peer use cases, even in video.

Skype was, at the very beginning, a peer-to-peer solution. They don't advertise that, so you never hear about it. Through that period a lot of the peer-to-peer technology kind of went through this problem of piracy.

There was a big industry backlash from the content-rights industry that essentially killed a lot of the businesses in the space. Also, people never figured out a good enough business model that would bypass its problems.

So I would say in the past few years the blockchain world really gave peer-to-peer technology a new... oh, it's blockchain and WebRTC. Two technologies together really gave peer-to-peer a new, second life. It's now a super vibrant ecosystem with a lot of really interesting companies and projects working on cool things.

You see yesterday Peer5 and Streamr, they're working on really cool things. They're essentially passing the packets around, especially in the live use-case where everyone is watching the same stream; it makes a lot of sense to not get all of your packets from the same origin.

Nick: Actually, extending on your brief little history there, I know it's super interesting what we saw back in 2010, sorry, early 2000s? What do we even call that?

Steve: Yeah, in the first bubble.

Nick: The thing after the '90s. To me, the Skype-versus-torrent use case is really informative to dig into just a little bit more. Because the reasoning that Skype was using for doing peer-to-peer delivery was to improve performance, mainly. That was their reasoning. And also protocols like SIP or things like ICE were enabling peer-to-peer direct calling.

That use case is more around, "If I get a direct path, I can improve the quality of our connection." Whereas something like a torrent was peer-to-peer for a completely different reason. Let's say it nicely. Let's say that the reason they were doing it was cost, right?

We don't want to store gigabytes of Linux ISOs on your servers and have everyone downloading them directly over HTTP or FTP. If you can use a torrent file, you can let your users share their bandwidth and reduce the cost of actually hosting that content.

There's kind of those two approaches to it. I think that's a really interesting way to frame some of our modern usages and looking at why people are interested in peer-to-peer, is there is that set of users that are interested in it for reducing cost. And there's that set of users that are interested in it for improving quality.

Eric: Absolutely. Especially when you look at the world, the infrastructure of the internet in the world. It's a very, very fragmented and broken system. The fact that it even works at all is like a miracle.

When you have all these disparate networks that have different capabilities, peer-to-peer comes in really handy. For example, in Brazil there hasn't been any great CDN solutions. So to deliver video at all, you're forced to use peer-to-peer solutions. The guys at Globo, they were forced to create these cool solutions to do peer-to-peer. This was like six, seven years ago.

Matt: I think you touched on a point that's been really interesting to watch around some of this peer-to-peer delivery stuff where you have a dorm in a region with traditionally really bad, so you have one small pipe into a fairly large dormitory. It's really useful, once you're inside that pipe, to share your content across everybody else inside your internet. Because you can actually get pretty good bandwidth between everybody in the rooms, but your actual link to the internet itself can suck. It's been an interesting use case about some of this.

Eric: Yeah, and I would say another interesting lesson that we learned from the last wave is that the scalability of the network is really critical. I would say that a lot of the live use cases did not get the scalability right and that's a lot of the reason why people ended up switching to other solutions.

Spotify started using peer-to-peer solutions to deliver songs to one another, between the peers, and they were doing that underneath the hood. No one knew about it. It turned out that it really affected their time to start. So they had to take it away and switch back to the traditional solution.

For torrents, it worked because there was no live constraint that you need, right? You can sit there for a long time and just wait for the file to come back. And if you don't care about the latency and you only wanted to save bandwidth, that really made sense.

I think in the protocol design this wave of technology is trying to solve some of these fundamental scalability and incentives issues so that we can get around this issue of latency and actually deliver good quality in a live environment.

Matt: Tangentially we've touched on the concept of decentralization, which has been a bit of a buzz word for the last five years specifically. Where we've really started to talk about some of the stuff around peer-to-peer delivery.

Nick: All right, can you name a successful decentralized project?

Matt: I think BitTorrent is fairly...

Nick: A second one.

Matt: Does BitTorrent count for two, or?

Nick: It counts for one. Don't say WebTorrent.

Matt: Ultimately, Bitcoin and Ethereum. It's hard to not say that those aren't successful decentralized projects. I mean, it's up for debate even what they do right now and what the utility is. But they're clearly successful from the fact of, last time I heard, I don't know if this is true or just some Reddit gimmick thing, but Bitcoin now makes up the largest compute network in history, is that true?

Eric: Certainly by hash power, yes. And certainly by energy consumption.

Matt: I struggled to name successful decentralized companies. Is that because of a utility problem? Is that because of an application problem? Is that network dynamics and politics issues? What exactly do we mean when we talk about decentralization?

Because I think you can decentralize an application but it's still under your control. So it's centralized, just, federated server. Like IRC, you know what I mean? But what is it? What do we mean when we say it? And why is it important?

Eric: I would say the internet is a decentralized system. And in that sense it's very successful. We have different ISPs who own different regions in the world and they deliver packets, they help each other out and they have different deals.

In my mind, decentralization is some kind of common ground that people get together and nobody owns the whole system. Everyone kind of owns their own piece. But they decide on a set of rules to work together. And that's a very high level.

When it comes to a piece of technology, I think decentralization means agreeing on a specific technical protocol that makes the rules in place and unchangeable.

That's what introduces the efficiency of computing. You don't have to have people talking about stuff with each other, and just have computers do this protocol exchange. That's what's powerful about decentralization.

In terms of BitTorrent, that's what they did right. And I would say the thing about decentralization is, it's hard to have one company own that thing. I would say for entrepreneurs and especially us in Silicon Valley, the model has always been, start a company and let's create some project, let's raise money, and let's grow this company to a bigger and bigger scale. And I'm not sure if that's a great fit for a pure decentralized piece of technology.

Nick: Can you talk about Livepeer, then? I mean, what are you doing if not that?

Eric: Yes, sure. Of course, we're in the very early days. And we're also in the very early days of this new wave of decentralization. So that's my caveat.

But what we're trying to do today is to create somewhat of a software foundation. And we have seen this happen once with the Ethereum Foundation, where they are less of a company. They're pretty much a software foundation. They're not based in the US. Turns out, you cannot have a software foundation in the US at all.

Aside from regulatory hurdles, all we're trying to do is really just to be the maintainer of this piece of open-source software. And because of the existence of token, that allows us to survive and that allows us, that kind of funds the development of this protocol.

Just like the Ethereum Foundation, I think they hold onto about six or seven percent of the token and they gave away the rest. That aligns your incentive with everybody who holds the token. And they will help you increase the value of the token. Over time, the token increases in value, you can sell small bits of that to fund the development of your technology.

Your entire goal becomes just to make this technology as good as possible, so that the entire ecosystem benefits. And that benefits you as well. So there is a really great alignment.

Matt: Well, can we take a step back and talk about what exactly Livepeer does, what these tokens are, how your live-streaming situation works.

Eric: Yeah, sure. Livepeer is a peer-to-peer, decentralized video live-streaming network, incentivized by an Ethereum ERC20 token. And that's a mouthful.

What that means is, basically, at the core, Livepeer is really just a set of protocols. It's an agreement between computing nodes that says, "If I do this for a network, then I will get compensated by the network, for this amount of tokens." And that is printed in the protocol itself, no one can change it, anyone understands it.

There is a market dynamic for the price to be set. There you just have the open market kind of work its magic, and you have a price. And the software that we build is basically a client for that protocol, similar to BitTorrent, have different BitTorrent clients that you can run on your computer.

The difference between this and BitTorrent, I would say, is that BitTorrent does not have a token.

If BitTorrent had a token it would probably have had figured out a really great business model to allow the business to thrive.

Going back to how the technology works, anyone can run a node to do either transcoding or delivery of the live stream that any other person sends in. And they get compensated for the work that they do.

What the protocol does is it keeps everyone honest. It will verify that the work that someone has done is correct in a cryptographically secure way. So that everyone knows that you have done the right work. And if you have not done the right work, the protocol punishes you. It disincentivizes bad behavior in the network so that every one stays honest and does good work for the network, and it scales. And everyone's happy.

Nick: So, talk me through it. Okay, so I talked through the traditional live streaming approach. I've got my thing I want to live stream, and I push an RTMP feed somewhere. I learn about a stream being on Twitch, being on YouTube, somewhere else that I want to watch, and I pull it down from a CDN. How is Livepeer different? How does it change that flow? What do I do if I want to go live?

Eric: The input is still RTMP stream. So you use the OBS on your computer and you broadcast that stream into the network. Now, the network has, maybe it'll have a gateway to provide a URL so that you can send it in. Maybe you just already know some nodes that will send your stream to the rest of the network and they just give you an IP. Or you can run a node on your local computer and just send it directly to that node.

So anyways, the point is, the stream gets into the network somehow through a node. And at that time, the network basically does this election bit and figures out a transcoder to do the work for you. And this election is basically through the price that you are willing to pay and the price that every transcoding in the network decides to charge.

Essentially, you almost have this order book, kind of like a stock market. You have the ask price, you have the call price. And when this transaction happens, then the transcoding node starts to subscribe the stream from you.

They'll start transcoding and creating, in this case, an HLS stream. And they will either publish it onto another gateway so people can watch it, or if people wanted to watch it in a peer-to-peer way, they can just send it directly to them.

Nick: Okay, so then, when I want to watch, I have to go to this gateway and connect to that transcoder?

Eric: Correct.

Nick: The transcoder needs to publish it to either something like a CDN or something like a torrent, to me directly?

Eric: Right. The transcoder basically gives you, the publisher, a way to get the video. And then it's your job to tell everyone who wants to watch the video, "Here's how to watch the video."

Nick: Okay, so, Livepeer is really about solving the transcoding resource problem, right? If I'm someone like Twitch, I have resources dedicated to transcoding your stream and then pushing it to a CDN. And Livepeer is doing that part of it.

It's not necessarily the distribution network of the content. I still, as a broadcaster, need to understand how my users are going to be getting this content and how I'm going to be storing it and telling them about it.

Eric: Yeah, so, Livepeer as it stands today is basically a transcoding market, right? We broke down the project into six different phases. We're now in the phase one.

Nick: Okay.

Eric: In phase three we will be introducing incentives to do relaying, to do video relaying. Let me just step back and say that, to create this market, there are a couple of really important things that you have to get right.

One is, why are people running these transcoding nodes? You can say that the transcoding nodes are getting paid by the broadcaster and therefor they make a little bit of the fee. But that might not be enough of incentive to create a large scale.

If you look at other blockchain projects, and this is, I think,

the really magical thing about the blockchain is that you can create any economic incentive you want to incentivize a certain behavior. In the network. In all of your participants.

If the behavior that we want for this network, for the transcoding network, is for more transcoders to join the network and provide more scalability for the network, what we do is, the network itself will incentivize the transcoders to come and join the network.

What that means is, the network actually mints new tokens to award transcoders so that the transcoders don't get paid for just the fees they make from the broadcaster, but they also make money from the network as a whole, for providing this value. And this is the same thing as in Bitcoin.

When the Bitcoin miners validate transactions, they make fees from everybody who sent that transaction in. So every time you create a Bitcoin transaction you pay a little fee. But the miner also gets a cut from the network as the network mints new tokens. The miner who verifies the transaction gets that reward, and that's what incentivizes all these miners to join the network.

You create the biggest, that we talked about, the biggest computing cluster ever existing in history. That's something really cool. That kind of comes down to this idea of inflation.

In markets we have inflation. The Fed uses inflation to incentivize certain behavior. It just happens that they don't publish that beforehand and they just say it. It kind of happens. But for the blockchain, everyone knows and the rules are, all in code, and it's not going to get changed.

Nick: Talk me through a little bit about the security implications of it. I have a livestream I want to publish. First of all, how are you going to validate that I'm actually, as a transcoder, doing the work?

I've got x264 on my machine and I sneak a little fast setting in there, rather than a medium one. How do you validate a transcoded video frame?

Eric: That's kind of the core of the protocol, is to make sure that people are actually doing the right work. In the ideal world, since we're using Ethereum, you can just do all of this stuff in a smart contract in Ethereum. Ethereum will validate that you're actually doing the right work, and that's it.

Nick: A smart contract H264 encoder?

Eric: Maybe not for a couple years. What we did is we figured out a way to basically securely sample your stream so that we're not validating the entire stream. We're validating maybe one out of 100 packets, right? Or one out of 100 frames.

We have a decentralized verification system so that the decentralized verification system runs the same transcoding that you, as the transcoder, has run. And we compare the hashes on the chain.

Now, the hash comparison is much, much cheaper than running the actual transcoder. So now the problem comes down to, how can we trust the validator? How can we trust the verifier who's doing the verification work? Because, you know, if I was a transcoder and I want to do bad work, I can just run a verification node and verify my own work. And I can cheat, right?

Steve: Are you essentially duplicating the work, then, too?

Eric: Duplicating the work for one out of, say, 100 frames.

Steve: Okay.

Eric: Right. So there you have a decentralized verifier election system. We're planning to use this project called TrueBit which is a really, really cool Ethereum project that basically gives you this interface of a computation verifications module. So that anyone can run an offline piece of computation and have it verified on chain.

That kind of gets around the scalability issue for Ethereum. But until that project is live, and we're working with them closely and we're helping, we're trying to help them to get this live.

We're using this thing called Oraclize which is a project from London, I think. And they're another project that kind of does this in a slightly more centralized way. I think they basically spin up an AWS node in a secure way, and you give them a docker image that has your code in it. It runs that, gets back a result on chain and you verify the result on chain to make sure everything's fine.

And when I say you, I mean a participant of a transcoder. Livepeer as an organization, we don't run any software. We just write the software and people who participate are doing this.

Matt: How do you pass in encoder settings, for example? Or do you? Is this just when you use Livepeer, you guys say, "Here are the bit rates that we produce on our network. Take it or leave it"? Or when I say I want to start a live stream, "Here are the settings I would like." Because that could change the pricing dynamic for the encoders drastically, right?

Eric: Absolutely.

Matt: If you're just saying, I want one rendition of 540p.

Eric: Yeah.

Matt: At half a bit.

Nick: 540p's a fun resolution. I'm not sure I've heard about that one before.

Matt: That's my favorite, slightly less than 720? When I wasn't pirating movies, that was always the...

Nick: Oh, was that DVD-native resolution?

Matt: It looked fine on the TV that I had that only maxed out 720 anyway. When I wasn't pirating movies at the time.

Nick: Ripping them for your own personal use?

Matt: Yes, exactly. Fair use man, fair use. So, let's talk through that. How does that work, when do you say, "Here's what we deliver on our network."

Eric: Right.

Matt: "Here's what we encode to." And also, "Here's what you can send us," because that changes the equation too. How do you guys handle that?

Eric: The network itself essentially becomes a marketplace, right? Any encoder can join the network and they can say, "These are the settings that we provide." And anyone, any broadcaster can pick certain settings, and the protocol itself essentially just matches the supply with the demand so the encoder settings can be put in.

Now, of course, for Ethereum today, you cannot put too much data onto the chain, otherwise it gets really expensive. We saw yesterday at the Twitch presentation they had this huge command line string that they use to transcode the video. And even for that string, it would be too big for the Ethereum network to handle, per request. So right now what we do is, we do preset settings. And you just have an identifier for those settings.

Steve: That makes sense.

Eric: Yeah.

Steve: It seems like you would want to guarantee something along the lines of, like, they are using FFmpeg. Or something, because you want some level of consistency between all these things. And you can't guarantee that, unless you're actually using the same tool, right?

Eric: Absolutely, yeah. That's one of the hurdles that we have to cross, which is the bit-level consistency. Because we're taking a hash of the output chunk, so we have to make sure every single bit is the same.

That just comes down to the software version and the exact same setting that you run. So, when you're a transcoder and you come online, you have to run a bunch of tests to make sure you're actually running the same software that the broadcaster expects.

Nick: Interesting. But doing them at arbitrary time slices would be exceptionally challenging. Because the encoder might be deterministic given a certain input sequence. But it's not going to be deterministic if you randomly sub-sample the input sequence. That's going to be a big challenge.

You might want to look at using something like a VMAF validator instead, where basically you take a frame from the original stream, take a frame from the generated stream, run them through a VMAF tool. And you can basically say, if you're outputting all black, then your stream's no good. And this is the VMAF that we're getting from you and put that onto the blockchain.

That way you can say, this peer is consistently delivering lower scores than we anticipate given their stream quality. That way you're getting around that determinism issue by basically saying, well, we ran an encoder with similar settings, we got a VMAF that was way higher than the VMAF we got from your stream. You're cheating.

Eric: Yeah, that's really interesting. That comes down to the difference between a heuristic-based valid verification versus a deterministic verification, right? And we're starting off with the easier solution, which is deterministic.

I think the heuristics are really, really interesting fields because that also makes the verification work a lot cheaper. Which is good for the network. The fact that we are an open-source project means anyone can contribute.

Nick: Patches welcome.

Matt: Would running VMAF actually be cheaper than checking all the segments?

Nick: Depends on how optimized your implementation is, I guess. But actually, I might want to roll back something I just said. If you are outputting an HLS stream with two-second segments, or four-second segments, you could sub sample randomly and say, I'm going to re-encode this entire segment with the software. If you did the entire segment, then it should be deterministic.

Eric: That's what we do now.

Nick: That would work.

Eric: Where we just basically pass the segment and then you just do another segment.

Nick: That could work.

Eric: Might not be the most scalable solution, but we're going to get there. That actually touches on the fact that why we are decentralized. Now all of a sudden we have all these participants. You have all these stakeholders in your project who all want your projects to succeed.

The same as Ethereum. When they started out it was three guys checking code, checking code across the world. And more people found out about it, more people got involved.

I just know so many, so many smart hackers working on Ethereum full-time because they got some tokens early on. An their token appreciated so much and they have dedicated their life now to make Ethereum better.

Nick: I think the next question I want to ask is, what has the response been from the older order? We got it up next on our slide there.

Matt: There are other tokens doing similar things. Right, you've got Golem as kind of one of the older ones that's also a distributed compute network. They focus generally on 3D rendering.

Recently, Render Token, which very similar to Golem, also typically used for 3D rendering. So both of those seem like it's in the same vein. So I'm curious, big differentiator here that you're specifically creating essentially just RTMP. Like a marketplace for getting an RTMP ingest point and then the transcode behind that?

Eric: There's actually a bunch of projects working on different parts of the tech infrastructure stack, right? You have the Golems and the other two we mentioned. Even Falcoin and Swarm is working on file storage, which is another important piece of computing infrastructure.

You can say that Ethereum is, they call themselves the world computer. It's for calculation and computing. And I think over the very, very long term, everything kind of emerges. And I would be so happy if there was a common infrastructure that all we have to do it write an algorithm and put it into the air and it just works for everyone. That would be amazing. But until that happens, we have to build solutions to solve these problems.

You guys know how complex the video stack is. I've been three days of this, and it's like, it's insane. It makes my brain hurt. So I think there's going to be enough problems for all of these different use cases to solve for the blockchain. Which means we have to basically rewrite the entire stack. And that's going to take a lot of effort and a lot of manpower.

Vitalik did a talk at Disrupt SF a couple months ago, maybe a couple weeks ago. And he said Ethereum is going to take at least 10 years to mature and it's going to take a long time. So I think all of these projects have their place and we're all helping each other and we're all using each other's libraries just to make this ecosystem grow.

Matt: As a nerd, I'm always very interested in everything that's going on in the crypto world. It's super buzzy right now.

It does feel a lot like when I see a lot of these projects, like, this is reinventing a wheel that I didn't know was broken. And sometimes it actually is.

Sometimes there is a real improvement. Sometimes with some of these things it feels like somebody just slapped an ICO white paper on a perfectly fine existing problem. And then raised a bunch of money and, yeah. You know what I mean? Sometimes some of these things feel a little bit disingenuous. But I'm curious.

That leads nicely into, how does the old guard feel about this? Because I think some people could say, "If it ain't broke, don't fix it." I think some people would argue it is broken, we need to fix it. I think other people would argue there are some problems here, but is this blockchain the solution?

Because I think that, on the other side of things, there is just the world that's just like, "Rub some blockchain on it." Anything, right? Blockchain light switches, you know? So I'm curious what the response has been from the old world, here?

Eric: By the way, I recently heard a dental blockchain project. It was just literally a blockchain for the dental industry. And they went ICO and are doing pretty well in the marketplace.

But let me take a step back and say, for sure, the industry right now is very over-hyped. There's a lot of enthusiasm in the space and I think some people are taking advantage of the market. And that's very sad to see for someone who's been in this space for a while.

But it's just like any market, right? When a market becomes over-hyped, then bad actors come in and then you go through a boom and bust.

And then the great technologies...

Nick: Also, the government has a tendency to step in.

Eric: Yeah, that's great. I mean, I'm happy to see good regulations come in because right now we're essentially operating in a very uncertain market. The more certainty we have, the better. As project maintainers, as operators, then we know the rules to operate. Then we can push our projects forward in a much better, more stable way.

So I welcome that. But looking at the dot com bubble, it's the same thing. People got really excited about technology and the internet, invested way too much money in stupid projects, and a lot of them went away and the market crashed.

That was sad because of the scale that it had happened. It's not just rich people that lost their money. A lot of people really lost their life savings, and that was very sad. And so I hope that the crypto world doesn't get to that point.

I do hope that there may be a market, a steady correction that happens over time, so that the bad projects can be weeded out and the good technologies prevail.

I really believe that the blockchain technology on the whole is kind of the next enabler of scalability for the internet as a whole.

Nick: Is anyone using your stack yet in the real world?

Eric: We have a test network that's live. We have some interesting developers who are really interested in doing this. I think it's going to take a while for the traditional video industry to start embracing decentralized technology. And that's okay.

Because there is already a very lively and burgeoning, decentralized ecosystem where people are writing completely decentralized applications to run only on people's end devices and have no backend servers. The entire backend is just the blockchain, which nobody owns. And when you're working in this environment, and if you want to have video, you have to use Livepeer. There's no other solution.

Nick: You're going to corner the market.

Matt: From the video perspective, I mean, you've been at FOMS for two days and then Demuxed for a day. I'm sure you talked to some people in the industry about this. What's the response been? Any takeaways? Thoughts? Anybody slapped you?

Eric: I think people are excited. I don't think the decentralized world is a threat to the traditional video industry at all, because it's just a completely different use case. I would say if anything it's the large content platforms that might get threatened most immediately.

If I was creating video on one of these big platforms, whether it's YouTube or Facebook, I kind of don't have a lot of control of how I want to engage with my audience. I'm basically at the mercy of these big platforms and they can do whatever they want. They can censor me, they can shut me down, they can take as much of the ad dollars as they want. They completely control the situation. I have no power at all as a content creator.

But in a decentralized world, that completely changes. Now you are talking to your viewer in a very direct peer-to-peer way.

If they can find your content and they're willing to give you 10 cents, you're going to get that entire 10 cents. That's a big change for these content creators.

I know a lot of internet content creators are looking into the blockchain space a lot.

Steve: That is the key, though. "If" they can find your content. That's kind of what the big platforms bring today, is they bring the audience, right?

Eric: Absolutely.

Steve: And so there's that transition that has to be, the first benefit is just the cost. It's going to be way cheaper, I would assume, using these technologies. And then if somebody can build a platform that helps then bring the audience in, in this kind of world, then that's when you can really see these benefits, right?

Eric: Yeah, for sure. And there are projects in this space that are solving that specific problem. Which is slightly different than from what we're solving. We're just solving it from an infrastructure level, and make the video tech work. But the creator incentive is a slightly different problem.

I know this project called Stream Token, I think. They're actually based out here. They're working on a streaming token that will basically connect the creator directly with the viewers. And I think that's a pretty cool project.

Matt: Well, it's a bold vision. It's a bold vision. Yes, if I'm hearing this right, in this future, 20 years from now, I'm going to upload a video that's going to get transcoded with something like Livepeer. It's going to host it on some Falcoin thing, it's going to get delivered via WebRTC, like something like Peer5 is doing. And then maybe the Stream Token is involved, and it's all going to be just this decentralized video infrastructure across the board? Is that what I can expect?

Eric: One day, I hope, right? And if you imagine if the internet infrastructure was really smart, if the hosting and everything was not owned by anybody and it was really smart and it knew how to do all this stuff, that's kind of what you get. You upload some video and it just does its magic and you see on the other side. I don't think that's crazy to hope for.

Steve: Cool.

Matt: Okay, well, thank you so much, Eric. This has been really interesting. I'm excited to one day welcome my decentralized overlords.

Eric: You could be a participant.

Matt: Yeah. I think the decentralized bus is just going to run me over. But I look forward to decentralized Demuxed where everybody's going to buy their Demuxed coins. All right, well, thank you, guys. I really appreciate it.

Eric: Yeah, thank you guys for having me.