GRTiQ Podcast: 14 Adam Soffer

The following podcast is for informational purposes only. The contents of this podcast do not constitute tax, legal, or investment advice. Take responsibility for your own decisions, consult with the proper professionals, and do your own research.

Adam Soffer (00:23):

Yeah, I think Graph will continue to serve as the defacto query layer for all these web3 protocols, including Livepeer. I think over time as they support more and more protocols, it’s only going to grow and become more and more important and kind of an indispensable part of the web free tool.

Nick (01:14):

Welcome to the GRTiQ Podcast. Today I’m speaking with Adam Soffer, a software engineer and designer at Livepeer, a decentralized video streaming network built on the Ethereum blockchain. As you may have already recognized, Livepeer was one of the first 10 subgraphs to migrate from the hosted service to the mainnet. My interview with Adam is a GRTiQ Podcast first. Livepeer is the first consumer of The Graph that I’ve had the opportunity to interview. Our conversation covers many topics including Adam’s entry into crypto, what Livepeer is and how it uses The Graph, some interesting similarities between Livepeer and The Graph, and a very engaging conversation about subgraphs. We started the conversation talking about Adam’s educational and professional background.

Adam Soffer (02:08):

I studied computer science, I did a master’s in computer science, stats my educational background specifically was distributed computing, but after grad school I started working with a design and development firm where I basically helped lead digital transformations for companies that from startups and Fortune 50 companies and got to work with a lot of cool companies and build a lot of cool stuff. And I did that for about seven years before discovering Ethereum and falling down the crypto rabbit hole.

Nick (02:44):

All right. I’m going to ask a follow up question here. So before I do, do I have it right? You got a master’s degree in computer science?

Adam Soffer (02:51):

Yeah, it was a master’s in computer science, and there was a concentration on distributed computing.

Nick (02:58):

All right, so did you cover anything about crypto in any of the textbooks you read, or any of the lectures the professors gave?

Adam Soffer (03:04):

So I should be clear that I was done with grad school and my master’s in like 2012. So no, actually this wasn’t on anyone’s radar then. And probably like a few years later, people started writing papers on this stuff, but it was… Interestingly, one of my professors did a lot of research on protocols that some of these peer-to-peer networks actually use, like gossip protocol and stuff like that. But no, in 2012 no one was really teaching this stuff.

Nick (03:38):

Well, I didn’t realize it was that long ago, but that makes sense. So let’s turn our attention to how you got into crypto. Can you describe to us how that all happened?

Adam Soffer (03:46):

Yeah, so my first exposure to crypto was Bitcoin in 2011 or ’12, and I thought it was really interesting, but Ethereum just captured my imagination as a developer and as someone who just likes building stuff. And all the different things you can build with Ethereum, it was a light bulb moment when I first heard about Ethereum. And I think talking to other people, they kind of experience the same thing. Literally within 30 seconds of one of my friends describing the project to me, I was just totally enraptured by the idea. I think the fact that it’s open and permissionless is probably the thing that gets most people really interested in it. But as a builder, it’s the idea of Ethereum resonated more immediately than Bitcoin, but I think both are cool.

Nick (04:43):

Well it seems to me a guy like you with your education, you probably had a lot of different career paths you could have taken. So how would you explain why it is you chose a career path in crypto?

Adam Soffer (04:54):

At my old company, at this design and development firm I mentioned we, like every month or so, a bunch of us would get together and for drinks and just share cool stuff that we discovered throughout the past month and someone shared Ethereum, and it immediately captured my interest and this was 2016 and after I learned about it, I couldn’t really think about anything else. So I took to learning Solidity, and writing smart contracts, and building dapps, and this was just kind of all in my free time, but I didn’t pursue it professionally until I discovered Livepeer in, I want to say 2017.

(05:39):

I wanted to build a live streaming application and I wanted to see if there was a way to leverage decentralization and blockchain technology and Ethereum ’cause I had read about the crazy costs associated with building a live streaming app. And in my research I stumbled upon the Livepeer white paper and they had a beta app at the time, and so I basically started experimenting with building an application on top of Livepeer. And that’s kind of when, as I was building this application on top of Livepeer, I became more and more interested in the Livepeer protocol itself, and shortly thereafter decided to pursue building Livepeer full-time.

Nick (06:27):

So the reason why we’re speaking and how we met is because Livepeer is one of the 10 subgraphs that recently migrated to the mainnet from the hosted service. So Livepeer uses The Graph Protocol. So what can you tell us about what Livepeer is?

Adam Soffer (06:45):

So Livepeer is a live video streaming protocol and it’s built on the Ethereum blockchain. Our mission at Livepeer is to build the world’s open video infrastructure.

(06:56):

So what does that mean? Basically, if you are a video developer and you want to add some sort of live video streaming functionality to your app, this is a very, very expensive thing to do. The reason it’s really expensive is because there’s this thing called transcoding, which basically when you’re live streaming you have to convert a live video stream to all the different formats so that it can be played on all the different devices. And that’s a very expensive thing because every video segment has to be transcoded, and if you’re a startup this can cost you like millions of dollars depending on how many users are using your app. And so Livepeer, basically through decentralization, is able to drive down these costs by creating an open marketplace where anyone around the world can run the Livepeer software and contribute their compute in service of transcoding live video for app developers. And Livepeer has proven to reduce the cost of transcoding by 10X and can potentially even reduce the cost by up to 50X.

Nick (08:05):

Obviously reducing the cost is a big deal. How would you frame the additional benefits of a permissionless and open source solution like Livepeer?

Adam Soffer (08:15):

Yeah, definitely. I think because it’s permissionless and open source, you don’t need permission to contribute your GPU to the Livepeer network in service of transcoding, anyone can do it. And similarly, if you want to build an application on top of Livepeer and use this service that the network provides, you don’t need any permission. You don’t need permission from the Apple App Store. The network is public, you can get started with a crypto wallet and Ethereum because these people running Livepeer software all over the world get paid in service of transcoding.

Nick (08:53):

So what examples can you give of people using Livepeer?

Adam Soffer (08:57):

Sure. So there is a protocol explorer actually that uses The Graph and on this explorer you can actually see an overview of the usage. So we just recently broke 2 million minutes of video transcoding per week. So that’s a lot of video, I think that’s years worth of video every week that’s being transcoded. And some of the applications that are using Livepeer are startups that built an application, but like I said, they were hit by these streaming costs at the end of the month and had to basically… in one case a developer had to actually pause their business operations ’cause they couldn’t afford the streaming bill at the end of the month. So they discovered Livepeer and were able to reduce their costs and resume their business operations. So there’s a few applications you can check out that are using Livepeer. There’s one called PlayDJ.tv, which is kind of like a Twitch but for DJs. There’s an application called Korkuma, vimm.tv, and a host of others. But yeah, like I said, there’s about 2 million minutes of video every week being transcoded on the Livepeer network.

Nick (10:12):

What can you tell us about your role at Livepeer?

Adam Soffer (10:15):

So I do software engineering and design and I focus on the user facing products. So for example, the Protocol Explorer, I help lead the design and build for that. Some of the commercial products that we’re building on top of Livepeer to sort of induce demand into the network. But yeah, I would say anytime you’re interfacing with Livepeer as a user, that’s something I would touch.

Nick (10:41):

So this seems like the most important question I can ask you. I think there’s going to be a lot of interest in this, how would you describe how Livepeer uses The Graph?

Adam Soffer (10:49):

Sure. So Livepeer has a protocol explorer where much The Graph Network explorer where you can view all the node operators, the prices they’re charging, their reward cut, their fee cut, and you can basically, anything on the protocol at the protocol level, you can use this application to view. And so we use The Graph to basically power that protocol explorer. So all that data that you view on the Livepeer Explorer is indexed and served by The Graph. So yeah, that’s basically how we use it. We wrote our own subgraph and it powers the Livepeer Explorer.

Nick (11:31):

Do you remember when you first became aware of The Graph and what you thought at the time?

Adam Soffer (11:35):

I mentioned I worked at a design and development firm and I worked a lot with GraphQL, and React, and a lot of user interface engineering. And so I was familiar with GraphQL, and I was familiar with Ethereum and building dapps and writing smart contracts and all that. And The Graph, I think I just discovered it when they first launched their website on my Twitter feed or something. And the value proposition on their landing page was made immediately clear to me because I had felt the pain of building a dapp and querying raw blockchain data.

(12:11):

And so at Livepeer I mentioned we have this protocol explorer, which is a dapp, and at the time was querying data directly from the Ethereum blockchain, and it was noticeably slow and there’s also just certain data that was just inaccessible in the absence of running our own Indexer. So yeah, I immediately checked out their beta software and started running our own Graph node to test the software out, and I was just just so delighted by the developer experience and the help that the founding team was providing right off the bat, and solved an immediate need for Livepeer, which was improving the performance of the Livepeer protocol explorer and surfacing data that was previously inaccessible.

Nick (13:01):

A lot of members of The Graph community, myself included, when we think about consumers of The Graph, we think in terms of dapps. So is Livepeer a dapp? Is that the right way to think about that?

Adam Soffer (13:12):

There’s a lot of different names being thrown out there, how to characterize the type of service Livepeer provides. But I would actually categorize Livepeer the same as I would categorize The Graph, which is it’s a distributed work protocol. Some people call it a service protocol, but it’s infrastructure, it’s not a dapp. There is a dapp, the Livepeer Explorer, where you can view data, like protocol data, on the Livepeer network. But Livepeer itself is infrastructure, much like The Graph.

Nick (13:44):

Well let’s build on that. So help me understand what a protocol is.

Adam Soffer (13:49):

A protocol is basically a set of rules that a bunch of people agree on. So in the case of Livepeer and The Graph, there are these rules that are enforced by smart contracts that anyone running the Livepeer software or The Graph software basically opts in into just by using the software. And so that’s what is meant by protocol, just basically a set of rules that people agree on and are enforced by these Ethereum smart contracts.

Nick (14:25):

Let’s keep building on this, tell me how you define what a smart contract is.

Adam Soffer (14:29):

A smart contract is code on the blockchain that computers all over the world execute. There’s an analogy is like a vending machine. So when you use a vending machine you put money in and you get something out. Similarly, when you submit a transaction on the Ethereum blockchain, you are submitting a transaction fee in the form of ETH, and a function gets executed in that smart contract and it changes the state of the blockchain. So you put something in, you get something out essentially.

Nick (15:03):

So I don’t really know how Livepeer works in terms of its community and structure, but was there a personal draw or a personal interest of your own that pushed you towards wanting to work on The Graph?

Adam Soffer (15:14):

There was an interest to use The Graph because it was helpful to Livepeer. And I think The Graph and Livepeer are both part of this, like I mentioned, they’re both distributed work protocols, so they’re both part of this kind of web3 movement and both projects really want to see it succeed. And so I think both projects are learning from each other and help helping each other because we really want to see this web3 movement succeed. So yeah, if early on if I discovered a weird bug as I was building a subgraph I’d report it and help strengthen the software in the early days. Yeah, I would call myself an open source contributor and a consumer of The Graph.

Nick (16:06):

Well that’s such an interesting way to put it because you are a consumer of The Graph, but the way you frame that, I mean you’re also really an important member of The Graph community.

Adam Soffer (16:17):

I like to think so. Yeah, I’ve always been a huge cheerleader for The Graph since the early days. And as someone who’s… I was also an early proponent of GraphQL, and so as someone who’s really passionate about all the technologies that The Graph is moving forward, it’s a community that I really enjoy being a part of.

Nick (16:35):

So how important is The Graph to Livepeer?

Adam Soffer (16:39):

It’s really important for our supply side, and by supply side, I’m referring to all the network participants responsible for providing the service to developers, and developers are the ones that are building live streaming applications. So if you’re a developer, or you’re an note operator, we call them orchestrators in Livepeer. The explorer is really important because it allows you to view network health and see who’s getting paid, and it gives you a really good picture of the network. The absence of The Graph would make surfacing all that data, which is really valuable to like I said, the supply side participants, would make it really hard to service all that data, and they rely on it to adjust their prices, their reward cut, if someone else changes their reward cut. People want to see that, and all that data is indexed by The Graph, so it’s really important for our supply side at Livepeer.

Nick (19:04):

I’d like to get your perspective on something that I’ve heard on the podcast before. It’s this idea that it would be too expensive or too cumbersome to try to do what The Graph is doing inside your own business internally. How should we think about that?

Adam Soffer (19:19):

Oh yeah, running your own Indexer, and the absence of the service that the grasp provides would is it would just take so much engineering resources and time. And yeah, it would be hard to pull off and you would be on the hook for making sure that your Indexer is constantly running because if it’s not then your application can go down. And so yeah, no one wants to run their own Indexer. This definitely needs to be a public network, like web3 needs a query layer, there’s no question about. It’s kind of like imagine Web 2.0 with no Google or search engine, if everyone had to run their own Indexer to search HTTP resources like webpages and images and stuff, we take Google for granted but that’s a service it provides. And so the absence of a query layer and web3 is just a non-starter, really critical infrastructure.

Nick (20:21):

Yeah, that makes sense. So are there other options or solutions available to you if you didn’t want to use The Graph, could you go out and find or use something else?

Adam Soffer (20:29):

To my knowledge, I don’t know of any other query layer. It’s an immense undertaking what The Graph built, everything from its crypto economics to its execution, the client software. And I think most importantly the community. The community is huge and that’s a huge amount of… that’s what they built over the past few years is pretty monumental. I don’t know of any competitors, but I think if someone did want to build a competitor to The Graph, yeah, good luck.

Nick (21:02):

Well as I’ve mentioned, Livepeer was one of the first 10 subgraphs to move from the hosted service to the mainnet. I’d be really curious to know what your perspective, or what your experience of that migration was.

Adam Soffer (21:14):

It was pretty smooth. Edge & Node really helped with the migration process where they helped with… I mentioned that query fees are paid for in GRT, so they helped with setting up our wallet so that we can pay for these query fees. And yeah, it was a pretty smooth process. From a developer standpoint I literally had to change one line of code in the explorer so that instead of pointing to the hosted service, it points to this gateway into the decentralized network. So now instead of querying data from the hosted service, which is subsidized by Edge & Node it’s pointing to, like I said, this gateway service which routes request to the actual Indexers on the network in exchange for query fees. So yeah, from Livepeers perspective it was a pretty easy process. Edge & Node, it was a massive undertaking. It’s like I love that their branding is astronauts and outer space because it is a huge endeavor what they’re building out.

Nick (22:22):

I appreciate you sharing that because it’s true that The Graph brand is really reflective of The Graph mission. So you were involved with The Graph early on. I’d love to just hear any summary points or final observations about the subgraph migration and the journey it took to get there.

Adam Soffer (22:43):

I have an interesting, I think, experience with The Graph because I started experimenting with it early on. My first experience with The Graph was actually running at Livepeer we initially ran our own Graph node and we were indexing our own data, we weren’t even using the hosted service because it actually didn’t exist yet. And they launched the hosted service, which was awesome and super helpful ’cause we didn’t have to run our own graph node anymore and make, so that saved us a lot of time and resources. And then now it’s using the decentralized network, we’re using a gateway that they built, which is really exciting. I mean it’s really powerful to think that when you’re browsing the Livepeer Explorer and the web server is serving up data, that data is being paid for in micropayments to all these known operators around the world that are running Indexers.

(23:38):

And I think it’s just such a powerful paradigm, right? In Livepeer we have the same thing where if you go to one of these apps that are running on Livepeer, the video is being transcoded and paid for per pixel in ETH, right? That’s crazy to think about. And it’s getting paid to node operators all over the world and they didn’t have to ask any permission to contribute their resources and do this work. Yeah, it’s pretty neat. I think service protocols are kind of underrated right now, but over the next year, I think more and more people are going to realize how powerful they are.

Nick (24:22):

Do you think there’s anything to this idea that maybe people like you who are using the hosted service for free won’t want to pay query fees once you make the migration over to the mainnet?

Adam Soffer (24:33):

I don’t think that will be the case. I mean, the network is set up in a way where Indexers are competing with each other on price. So as a developer, you’re not going to be charged an exorbitant amount of query fees, especially compared with Web 2.0 counterparts. So it won’t be free, but it’ll certainly be very affordable, and it’ll be more affordable than Web 2.0 services, right? So yeah, I think a lot of companies probably got used to the free service, but it was communicated very early on that the plan was to migrate over to this decentralized network. And I think everyone was aware and supportive of this migration because the hosted service, as more and more subgraphs get deployed, it becomes more and more difficult for a single company and a single infrastructure provider to serve all those subgraphs. I don’t even think it might not even be sustainable. I think the only way you can really move forward is a decentralized network. So I don’t see any tension or anyone currently using the hosted service, I don’t think they’ll have any problems or issues migrating over.

Nick (25:50):

I want to talk a little bit more about Livepeer. How would you say Livepeer is different from centralized solutions that listeners may be more familiar with?

Adam Soffer (25:58):

Sure, so a traditional cloud provider that you would use today something like an AWS, or a Google Cloud, compared with Livepeer those are centralized providers where you have to provide an identity, your reliance on their infrastructure, maintained by a central authority compared with Livepeer, which is run by network participants all over the world where you don’t have to actually ask anyone for permission to use the network. So it’s permissionless, it’s more cost effective because these node operators that are running the Livepeer of your software, they’re all competing with each other on price and it’s more reliable. If one node operator goes down in the network, the video is automatically rerouted to another, and it’s highly scalable. So yeah, I would say if you’re weighing the options of going with something with a public network like Livepeer or AWS, I think the value props of the Livepeer network are reliability, scalability, price, permissionless. I think these are all properties by the way that are not just unique to Livepeer, but web3 infrastructure in general.

Nick (27:15):

Well Adam, as you know, myself and a lot of the listeners we’re very excited about the fact that Livepeer is a partner at The Graph and recently made the move to the mainnet. But I know there’s other exciting things happening over for the Livepeer community. What can you share about some of the exciting things happening over at Livepeer?

Adam Soffer (27:32):

I think the most exciting thing about Livepeer right now is we’re seeing a major uptick in usage. The last few years we’ve been building out the supply side and making sure that it’s usable by developers. And now that we have this working protocol and we’ve proven the affordability, the reliability, scalability, we can confidently go to developers and say, “Look, you should use Livepeer, it’s a superpower if you want to build a live streaming application.” And it’s really exciting to see companies discover Livepeer now. What’s really interesting about Livepeer is these aren’t necessarily blockchain companies. Yes, there are some blockchain companies, or projects that are building on Livepeer, but these are just developers that want to build cool apps that have some sort of live or on-demand video streaming component. And they’re coming to Livepeer because of all those value propositions I mentioned.

(28:29):

And so it’s just really exciting seeing a web3 protocol with a real use case. And the proof is in the pudding, if you look at the usage on the Livepeer Protocol Explorer powered by The Graph, it’s really if you look at the usage graph, it tells a really amazing story. It’s just like the growth is up and to the right, it’s very clear that there’s a lot of adoption. And I think that’s really good for not only Livepeer, but just web3 in general ’cause I think it’s one of the first protocols that is proving that you can use blockchain to do other stuff besides payment. You can drive down costs and create protocols that make it possible to build things that in the web2 Paradigm weren’t possible. Or, maybe they were possible but just not attainable for a startup, right?

(29:20):

In the past, if you wanted to build a Twitch application, you have to have really deep pockets. You have to basically be a [inaudible 00:29:28] company, right? If you look at all the live streaming apps out there, right? YouTube, Instagram Live, Twitch, there’s a reason why they’re all owned by these bank companies is because it’s just like you have to have billions of dollars in your bank account to maintain these types of live streaming applications. Livepeer through the power of blockchain and web3 and decentralization and crypto economics for the first time is allowing anyone to build that type of application affordably and at scale. That’s just really exciting to me as a builder. And I would just encourage anyone that wants to build a live streaming application to check out Livepeer ’cause it’s really a superpower.

Nick (30:08):

Well, I agree with you, Adam, that is very exciting stuff. So thank you for sharing. I’d like to know what your long-term vision for Livepeer is.

Adam Soffer (30:16):

I really do believe Livepeer will become the defacto open video infrastructure. Our mission is to become the world’s video infrastructure. And so what does that look like? Livepeer right now offers video transcoding, which is the most expensive part of the video stack. But there’s other things that you need as a video developer, there’s like CDN solution. One of the things I’m really excited about at Livepeer is we’re building an AI service on the Livepeer network, so you could do things like scene classification and object recognition. If you’re building a live streaming app for kids and you’re an app developer and you want to sensor like adult content for instance, you can opt into that scene classification service and build something like that. So I’m just really excited to continue to build out the video stack and become this open video infrastructure and I’m really excited to see what people will build on this.

Nick (31:13):

What’s your advice to listeners that want to learn more about Livepeer and get involved in the community?

Adam Soffer (31:18):

Sure. The first thing I would recommend you check out is a Livepeer primer. It’s a 10 minute primer, it’ll just give you a really good overview of Livepeer, how it works and what it does. And you can check that out at Livepeer.org/primer. And if you want to get involved in the community, if you want to get involved video mining, or staking, or contributing to the open source, join our Discord. You can find the Discord on the Livepeer website at livepeer.org. And make sure to follow Livepeer on Twitter, the Twitter handle is LivepeerOrg.

Nick (32:14):

Would describe The Graph and what does somebody with a non-technical background or doesn’t really understand crypto?

Adam Soffer (32:32):

Yeah, good question. To dumb it down, it’s an indexing protocol, so much when you go into a library, libraries index books to make it easier for people to find what they’re looking for so they can walk into a library and really quickly find exactly what it is they’re looking for. Likewise, The Graph makes it really easy for developers to query data because it provides this indexing layer. So I made the analogy to Google, imagine if there was no Google and you wanted to search for some topic on the web. If there’s no query layer, if there’s no one indexing that data to make it readily available for you to search, you’re going to have a really hard time finding what it is you’re looking for. So yeah, The Graph basically makes it really easy for developers to store and serve data in a way that their applications can consume.

Nick (33:33):

What about a subgraph? How would you describe a subgraph to that same person?

Adam Soffer (33:37):

A subgraph is an instruction set and it’s written by a developer and it instructs the Indexer exactly how data should be organized. So I made this analogy with Google and Web 2.0, you can kind of think of the Google algorithm, the way that they index all the data on the web as a subgraph. Someone had to write the instruction set that basically informs Google how and what to store this data. Similarly, if you want to index data on Ethereum, you can write a subgraph, deploy it, and when you deploy it, an Indexer will basically fetch data from a smart contract on the Ethereum blockchain in real time. So as events come in, the Indexer will grab the data associated with that event and store it. And basically what data gets indexed and stored is defined in a subgraph. So in short order, it’s an instruction set for an Indexer.

Nick (34:50):

I mean, is the way to think about the subgraph is it’s retrieving data from the smart contracts stored on blockchains. Is that the right way to think about it?

Adam Soffer (34:57):

Yeah, say it’s constantly crawling and watching for events being emitted by smart contracts. So anytime you submit a transaction on the Ethereum blockchain, an event gets emitted and the smart contract actually is what holds that data. And a subgraph basically is the instruction set for the Indexer, and the Indexer is basically watching for these events and extracting that data and storing it on The Graph Network. So that’s easily accessible by developers.

Nick (35:26):

A subgraph needs to be written, it needs to be created, somebody had to bring it into existence. Have I got that right?

Adam Soffer (35:32):

Yeah. Subgraphs are written by developers, so at Livepeer we wrote a Livepeer subgraph, Uniswap. The Uniswap team wrote a Uniswap subgraph. And each of these subgraphs are watching… like, the Livepeer sub is watching Livepeer smart contracts, and they’re watching events as it pertains to the Livepeer protocol. The Uniswap subgraph is watching all the Uniswap subgraphs and indexing Uniswap data. If you want to get meta, The Graph actually has its own subgraph and is watching for events being emitted by The Graph’s smart contracts, and that’s actually what powers The Graphs network page. And so as a developer now you’re able to query data from any one of these subgraphs and you get kind of a web of subgraphs and it becomes as more and more subgraphs get deployed you have this really rich graph of data, and that’s why it’s called The Graph because all the subgraphs combined gives you this singular graph of data.

Nick (36:35):

I love that idea. I hadn’t ever thought of it that way and it’s brilliant. So thank you for sharing that, Adam. So are the subgraphs typically written by the developer, or the user, or is that a service that The Graph provides? How should we think about who’s taking the lead on writing subgraph?

Adam Soffer (36:56):

Yeah, so it’s Livepeer, The Graph is open and permissionless and anyone can write a subgraph and deploy a subgraph. In the case of Livepeer, I wrote the Livepeer subgraph that powers the Livepeer protocol. Someone on the Uniswap team wrote their own. There are even firms that I’m sure provide writing subgraphs as a service, right? It’s kind of like a whole… you can kind of imagine it becoming a whole industry where people actually provide subgraph services where people just write subgraphs. But yeah, it’s up to the developer that’s interested in a certain data set to write the subgraph.

Nick (37:32):

Well, every interview I do, I learn something new each time. Today I’m learning new things about subgraphs, and another learning is I didn’t know that I could use somebody. So for example, if you wrote the subgraph for Livepeer I could go on The Graph and I could use that data for my own purposes, my own dapp, or whatever it might be.

Adam Soffer (37:53):

Yep, that’s right, it’s open, anyone can build an application powered by these subgraphs and query them directly. In the case of the hosted service, that’s a free service, but with the decentralized network, all you’ll need is an Ethereum wallet to pay for the query fees.

Nick (38:11):

Adam, two more questions about subgraphs. And again, this has been so illuminating, I really appreciate you taking the time on this particular topic. So as someone who’s written a subgraph, as you said, you wrote the subgraph for Livepeer, what can you tell us about that experience, and then what advice would you have for any listener that also wants to get involved in writing subgraphs?

Adam Soffer (38:30):

Sure. So The Graph team as you know created a really awesome developer experience, so if you’re comfortable writing JavaScript TypeScript and you’re familiar with the Ethereum blockchain, you’ll have a pretty easy time writing a subgraph. But basically the process is, you first have to identify, okay, what data do I need to power this application that I want to build? So we can use the Livepeer Explorer as an example. The Livepeer Explorer, we want to display all the orchestrators, which are the node operators in Livepeer, and we want to be able to show all the Delegators and display all the Delegator data.

(39:12):

And so okay, we know we want to display all that data, what are the smart contracts that are emitting this data? So identify the smart contracts, which are basically represented by a string. And in your subgraph you write down those smart contract addresses, and then you have these things that are called mappings, which are basically any time an event gets triggered in the smart contract, you want to tell the subgraph exactly what function to run so that it can grab the data emitted by that smart contract and store it somewhere. And that gets written in what’s called AssemblyScript, which is like a flavor of JavaScript. So yeah, it’s writing code, right? But like I said, if you’re comfortable with JavaScript and what smart contracts are, then it’s pretty accessible, I would say.

Nick (40:06):

And then last question on this topic of subgraphs. So you wrote the subgraph for Livepeer, the subgraph migrated to the mainnet. What’s the state of affairs now? Are you paying Indexers for data from your own subgraph? How should we think through how that’s all working?

Adam Soffer (40:26):

Yeah, so Livepeer was one of the migration partners, so it’s one of the subgraphs that’s actually being indexed on the decentralized network. So yeah, Indexers on The Graph Network are actually indexing the subgraph that we wrote, and they’re incentivized to because they can earn fees by doing so as long as there’s people that are interested in that data. You don’t have to by the way, you don’t have to as an Indexer, you don’t have to index every subgraph out there, right? It’s up to you what you want to index and you can index what you feel will bring you the most query fees and rewards. But there are Indexers that are indexing the Livepeer subgraph and getting paid query fees.

(41:06):

But yeah, they’re basically, the ones that are running the Livepeer subgraph, they’re watching for the events that are being emitted by the Livepeer smart contracts. And those events are basically specified in the Livepeer subgraph, which is, like I said, is basically just an instruction set.

Nick (41:26):

Yeah, to hear you say it that way. It’s almost like each Indexer is its own search engine.

Adam Soffer (41:32):

Exactly, yeah. A lot of people refer to The Graph as the Google of blockchains. You can kind of make the case that a single Indexer is its own Google, and there’s a bunch of Google’s competing with each other, and the sum of its parts are basically what makes The Graph so special and awesome.

Nick (41:55):

Based on your knowledge of The Graph and your familiarity with the community, what’s your advice to Delegators when it comes to selecting an Indexer to work with?

Adam Soffer (42:04):

Yeah, I can give my perspective also as someone who works for delegated proof of stake protocols, and you have to do your research, but the things to look for are generally performance. Like, are they actually doing a good job on the network? And usually the amount of fees that they’re earning is good proxy for this. If they’re earning a lot of fees, that means they’re getting a lot of work and they’re retaining it. And the only way you can get work and retain work is if you’re high performing. So look at how many query fees it’s bringing in, the amount of stake a node operator has definitely use that as a signal because it’s kind of like social proof, if there’s a lot other people staked to it must be good. But it’s not telling the full story, so don’t just blindly stake with an node operator that just has a lot of stake and don’t make that assumption.

(42:56):

Look into if the Indexer has a lot of information about their setup, and what they stand for, I would research into the organization or individual that’s running it. Do they have good values? Do they have high integrity? You know, don’t want someone that’s just going to change the reward cut or fee cut on you without communicating ahead of time, right? Stuff like that. So yeah, those are all things to look for. And Discord is definitely a good place to ask questions, and obviously these protocol explorers, so The Graphs protocol explorer is definitely also an invaluable tool.

Nick (43:35):

Well, I appreciate those insights and I’m sure listeners will as well. We’ve referenced the similarities between Livepeer and The Graphs several times. How would you contrast the role of Delegator in the Livepeer network versus The Graph Network?

Adam Soffer (43:50):

Both protocols have a lot of similarities. I think I would say they’re pretty much the same thing. Their role is to help strengthen the network. So in the case of Livepeer as Delegator you’re incentivized to stick with a node provider that’s doing good, good work and providing a high quality of service because that means more fees for you. Likewise, as a Delegator on The Graph Network, you want to stake with a Delegator that’s performing well because you’ll get a percentage of those query fees. So yeah, they both kind of perform this quality assurance role where the more stake a node operator has the more work it’s going to get. And you want the best performing nodes to get the most work because that’s good for the demand side. So yeah, I would say they both kind of play that role of quality assurance and strengthening the network and securing the network.

Nick (44:48):

Adam, you’ve been so gracious with your time, really enjoyed this conversation. Maybe one last question and it’s this, what’s your long-term vision for The Graph?

Adam Soffer (44:58):

Yeah, I think The Graph will continue to serve as the defacto query layer for all these web3 protocols, including Livepeer. I think the need for query layer is only going to grow stronger over time. And I think what’s really cool about The Graph and Livepeer as well is that… these service protocols is that they’re secured by the Ethereum blockchain, like both projects use Ethereum as a sort of marketplace, but you don’t have to build an application on Ethereum to use The Graph or Livepeer and I think that’s really powerful. The Graph is serving lots of different blockchains and protocols. It supports IPFS, Ethereum, and a host of other layer one and layer two blockchain protocols as well. And so I think over time as they support more and more protocols, it’s only going to going to grow and become more and more and important, and an indispensable part of the web3 toolkit.

Nick (46:07):

Adam, I love the vision there. Thank you for sharing that. For the listeners that want to follow your work and keep in touch, what’s the best way to do it?

Adam Soffer (46:14):

I can be found on Twitter. My handle is Adam Soffer, just my name. And I’m very active on the Livepeer Discord. You can find me on there as well. And if you’re a video application developer, or you’re just a developer and you’re interested in building a video app, I would encourage you to check out Livepeer and get in touch with me I’d be glad to help you get set up.