July 27, 2023 • 32 mins
This week on API Intersection, we welcomed Varun Singh, Chief Product & Technology Officer of the Daily. Daily is a company that powers real-time audio and video for millions of people globally. Their user base consists of many developers who use their APIs and client SDKs to build audio and video features into applications.
We delved into the significance of APIs in the video streaming industry and the crucial design considerations when integrating with such systems. Varun shed light on the challenges that APIs address in the video industry, such as achieving low latency in live streaming and real-time communications and efficiently managing multiple streams while ensuring a seamless user experience, especially when scaling to accommodate large numbers of participants.
"Previously, video streaming was primarily focused on platforms like Netflix and YouTube. However, with the pandemic, real-time video communications have become more prevalent due to the surge in video calls, which means more and more APIs being created to support that," shares Varun.
Find Varun and his teams work on LinkedIn and at Daily.co.
_____
To subscribe to the podcast, visit https://stoplight.io/podcast
--- API Intersection Podcast listeners are invited to sign up for Stoplight and save up to $650! Use code INTERSECTION10 to get 10% off a new subscription to Stoplight Platform Starter or Pro.
Offer good for annual or monthly payment option for first-time subscribers. 10% off an annual plan ($650 savings for Pro and $94.80 for Starter) or 10% off your first month ($9.99 for Starter and $39 for Pro).
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:01):
I'm JasonHarmon and this is API intersection
where you'll get insights from experiencedAPI practitioners to learn best
practices on thingslike API design, governance, identity,
versioning and more.
(00:22):
Welcome back to API Intersection.
As always, I'm your host, Jason Hartman,CTO from Stoplight.
It's been a little bitsince I've said the phrase today
we're going to do somethinga little different
because I felt like I was beaten to death.
But we really are doing something in two
plus years of the podcastwe really haven't gotten into.
I think we talk a lotabout kind of REST and craft,
(00:43):
you willand all these sort of synchronous APIs.
Sometimes we talk about eventdriven stuff, but today we're going
to really get into kind of real timeand sort of streaming protocol stuff
with quite the expert on the subject.
Mr. Varun same.
Varun, thanks for joining us.
Thank you.
Thank you for inviting me.
Jason. Absolutely.
(01:05):
So, you know,Varun had kind of come to us,
you know, talking about coming on andit was a really easy one to say yes to.
And we kind of looked and he's got 12 IETF
and W3C specifications, numerous patents.
So when it comes to kind of real timestreaming, I think we got the guy here
(01:25):
to bring
us a little bit about kind of your journeyin this streaming stuff
and what put you in your current roleas Chief Product and Technology
officer at Daily, thank you very much.
And yeah, it's been a journey.
I started, you know, about 20 years ago,
straight out of schoolworking for a semiconductor company.
And at that timethe whole range was megapixel cameras.
(01:47):
If you remember, cameras, phones becamesmartphones, smartphones carried cameras.
People started to take pictures.
And that was juxtaposition by a Web 2.0,like emerging in the same period.
I used to work for a companycalled SD Micro Electronics,
and then at Nokia, both of those roles,I was working on cameras
(02:08):
and the camera hardwareand the software that goes with it,
and that's how I got
into the space and my background beforethat was like communications.
I came from an electrical engineeringbackground and such
as, you know, historic playlike two, 15 years ago,
like we had this issue with Nokiabeing like, outcompeted by Apple and such.
(02:30):
So at that time I kind of leftthe industry to pursue a Ph.D.
and I started to work on real timecommunications
because that was the evolutionof like taking cameras
from like taking still picturesand recording and storing it
locally on your device,still like live streaming it
or like communicating with another personacross the across the Internet.
(02:51):
So things like Skypeand what really changed like 15 years ago
was the insight that we've been buildingreal time communications in silos.
So you had the Cisco's, you had the Skype,you had the my Microsoft Messengers.
They were all building these attacksindependently,
trying to solvethe same problem repeatedly.
And people envision that a
(03:11):
Web point, a web 2.0 had to, like, achieveits full success.
It would have to be ableto, like, work with these protocols
so that anyone could build.
Like right now we are using Xen Kastor,you know, like the fact that we are able
to communicate and a product like Xen,Kastor does not have to rely on like
Skype or Zoom or anything.
It can actually usesome of the native APIs available.
(03:34):
So the question became like,what is the big gap between like
these siloed solutions and how to make itaccessible through three APIs?
So that was the work that happenedten years ago,
and that's why the idea of documents
and the W3C specifications came outlike the industry got together.
You know,
while biggest companies
said, okay, we solve these problemsrepeatedly by ourselves,
(03:55):
of course, with cross-pollination,how do we make it accessible?
I eventually graduated with my Ph.D.
around the same timewhen the protocols came to light,
I built a company called called Statoil.
You can think of it as like analyticsfor real time communication.
So just like GoogleAnalytics is for web called stats.
As far as for real time and R&R businessfor four, seven, eight years.
(04:19):
Eventually we exitedjust before the pandemic.
So maybe not the best timing.
You know, we've been,
you know, trying to grow this productfor four, five, six, seven years.
And, you know, if you're venture backed,there's a big emphasis
to actually like keep doingtriple, triple, double, double.
We did a couple of triples and doubles,but at some point we flattened out
because the market kind of maturedand we can see it grow
(04:44):
faster.
And then the pandemic happenedand like everything grew.
That brought me to my current roleat Daily
Deli was a customer of cloud statsfor several years, but
because of the pandemic,it fueled its growth.
And Deli is basically an API for real timecommunication
for the widest set of use casesthat you want to build on video.
(05:07):
And lastly, it's a third gen
iteration.
So the first gen was ten years agowhen when real time communications
first appeared or a bunch of companiesthat started then.
Then five years later,
the second gen of companies and thenthe third gen which is which is daily.
And I think the big differencebetween the third
and the first gen was like developertools.
(05:28):
Ten years ago there was no react,there was no React native
like people were writing vanilla jazz.
So the type of APIs are builtfor that period of time versus today,
where you have universal,you have next years,
you have like React Native,you have Android iOS, you want to like
be able to satisfy all these thingsand people want to use no fear and react.
(05:49):
Where do you want to use components,Hooks, all that stuff are used.
The lower level API, which is led directly
to asa product company, which builds APIs.
We have to satisfy like a
slew of things depending on, you know,
you're basically, you know, codewas, is like, oh, I want to like control
(06:11):
every aspect of my experience, bothor both ends of the spectrum.
So that's how I got into my current role.
Very cool kind of progression.
I like that connectionof like how videos changed
as sort of the mobile worldand the web has changed, but
full disclosure hereI am not a video or streaming guy.
(06:33):
I don't know much about this and askyou like a million dumb questions today.
And my hunch iswe have a lot of perfectly fine.
So I guess the first one isare we talking about like the stuff that,
you know, when I watch Netflix or YouTube,is it that or is it zoom or is it,
you know, what kind of sort of streamingthings are you talking about?
(06:53):
That's a good question.
And I think the way we think about it,
there are scanned media or stored media,which is what Netflix is all about.
Like, you know, you're watching a show,the show exists somewhere.
They can actually use things
like distribution networks, iTunesto kind of push it as close to the edge
so that you get you as an end userget a great performance.
(07:15):
That's one aspectand that's what we call stored media.
It's been happeningfor almost 30 years now.
The technology has improved vastlythat you can like actually do a very quick
like changes in quality
which are not perceivable to the human,
even if you have a network issue.
So that's more or less solved problem.
There are a bunch of companiesthat try to do that.
(07:38):
A lot of the magic is in the contentdelivery network.
So video content delivery networks,the second one, which is live streaming.
So, you know, we just had the NHL playoffsand the NBA playoffs this last week.
And if you're watchingsomething like that, I think there
the biggest thing is that it can be storedbecause you're watching it.
(07:58):
And then the questionis how far behind real time can you be?
It can't be really,really live like it can be.
But like most often it's
like a couple of seconds behind,mainly because they want to,
you know, for legal reasons, but also theywant to distribute it widely.
That's called live streaming.
Typically today, most of their technology
(08:20):
is 5 seconds behind.
So basically, if a goal happens,
you you can see it on your screen, five,5 to 10, 15 seconds behind real time.
The main notion that is thatyou should even be screaming goal
before your neighbor dies or vice versa.
Your neighbor should be screaming goalor scorer before before you fight.
(08:42):
So that's like the biggest challengein that in that framework.
And the third one,which is like real time communications
where you are seeing something liveand what we've seen over the last
ten years is that we start with two peopleand I call like, like just like Skype
and whatever came after two peoplehaving a conversation
(09:02):
and then people said, Oh,we want to use it in a work setting.
Can we have five or six people?
And in a call during the pandemicthat became, you know, town halls, 15
people, 30 people, and now we routinelysee like ten people in a call.
The questionnow becomes like all these use cases,
like the live streamingbefore that I talked about where
there are millions of peoplewatching this like the game.
Can you do that in real time?
(09:23):
Can we use the protocols that we usefor like having real time communication?
And herewe're talking about 200 milliseconds
delay by like between you and I,we probably like tens of milliseconds
because weare roughly in the same part of the world.
But Max, like, you know, if you're halfwayaround the world, a speed of light,
you can go faster than the speedof light and cables and all those things.
(09:45):
So, you know, you're about 300,400 milliseconds behind,
but still good for interactivityin case you want to raise your hand and,
you know, like if you're having a big townhall, you know,
10,000 people watching the CEO speakand someone wants to ask a question,
you should be able to raise your hand,get on the floor through the green room
or whatever, and ask the question liveand then hear the answer.
(10:06):
So those are the use casesthat a lot of people are aspiring for.
And I think the the blurry linesbetween these three use cases
like the live stream,the CAM media, the live streaming
and real time communications are blurringlike becoming blurred.
People want to usenot three different protocols
or three different technologiesor three different vendors to do it.
(10:27):
People want to roughly use this one API,one render, and does it matter?
Should it matter that I'm connected to youin real time or I'm connected to
like a sporting event, sporting event andor like getting something from Netflix?
Like basicallythe API should be I'm playing video.
The sort of source could be,you know, live or real time.
(10:48):
AR Can Yeah,I was going to ask that to looking through
some of your IETF work in these things,I saw a lot of like RTP Web RTC, things
like this in these kind of categories,like what are sort of the common protocols
and where do you see thatthings are perhaps converging?
It's a good question, and I thinkeverything that is old becomes new again.
(11:09):
So RTP is like 30 years old technology,and it started
for broadcast or multicast.
And if you know, like if you know
your IP addresses, you know, there's likea set of multicast addresses at the end
which are not accessiblemostly because like the ISP's don't
allow like transmission, like if you're onVerizon, Verizon will not allow like a,
(11:32):
like a multicast beyond its boundary,but for security reasons.
But also
they don't want to send media outsideand like then get media from outside.
So it's time for multicast.
And a lot of the design thing decisionswe made for RTP were based on multicast.
However, like by 2000 to the 1992when they built the protocol
by 2001, 2002 multicast was kind of dead.
(11:55):
It was only used in IPTV.
So you are cable TVnetwork was probably is probably
still using broadcast to likesend your cable TV over over cable.
But you know it's comingdirectly from your provider
and that's typically the personyou bought the Internet from anyway. So,
so that still exists and still continues.
(12:16):
And when I talked about earlier,like MSN or Yahoo
or like all these messengers from,you know, 20 years ago,
they all actually used RTP,including Skype
at some point
started to use RTP because that'swhere all the engineers knew it, right?
Like if
you move from one company to another,you can like learn a new protocol.
Like it'll just takeyou like two years before you're like,
(12:37):
competent in that new thingand you're just re learning something.
So like, RTP is like the standardwhat Web RTC was.
And like, people talk about Web RTCboth as a protocol
and as an API,and they use them interchangeably.
So there are two aspects of Web RTC.
One is the API, which was standardizedand implemented by the browsers.
(12:58):
Of course, you know, the browser API
is called Live Web RTC, it's insidechromium.
It's also insidelike all chromium derivatives.
So Brave edge are all these browsershave it and then Mozilla has of
has their own version of web already Cand Safari has a
somewhat different version,but the API is a standard,
so it doesn't matter which browser you useor if you take that library
(13:21):
and they compile it into Android and iOS,you still have like the same APIs
because the Web APIshave a corresponding C++ layer.
So you can call these APIs anywhere.
And then APIs inthis case are not sufficient
because there's a protocol that like sendsthe media over the Internet.
So those areso that's the Web RTC protocols
(13:45):
and Web RTCprotocols are actually all old protocols.
As I said before,you know, all these companies had Cisco
Skype had their versions of their product,
and they're all slightly differentversions of RTP with extensions.
You know, if you're doing
two cameras, one camera every likeno one uses the standard process
(14:07):
or the standard protocolsbecause there's always something
that they need to do extra.
Either their codecs are different,like each two six, 4 to 6 five.
So back in 2010,when we decided to work on this,
people realized that there wasa lot of competence across the industry,
but no one had a standardized wayof doing certain things.
So the whole thing aboutWeb RTC protocols is just
(14:30):
the whole industry coming togetherand saying, like these variants
and these extensions of the protocolswill do these things.
And then that meant like you nowhad Cisco, WebEx, Zoom,
all of these folks using roughlythe same kind of things behind the scenes.
Yeah, it's funny, as I was kind ofskimming around trying to not sound like
a total idiot on this subject and knowvaguely what you're talking about.
(14:52):
I was getting flashbacks of likereal player and some of these old things
that are in and using all this stuff.Yeah.
Real player is a good exampleof like all the things becoming new.
So there was a thing in RealPlayercalled DSP real time streaming protocol
and it uses RTP underneath web RTC usesRTP underneath.
So it's RTP by itselfas a unit block is quite versatile.
(15:16):
Of course,it was built for a different time, so
and for all things becoming new now,there's a whole new initiative
called Middleware Quik.
And if you quick is like this new protocol
that is over UDP instead of TCP
and it's UDPthree uses quick, for example too.
And there's a whole reasonwhy we use UDP now
(15:39):
or instead of TCP for all these things.
So people are reimaginingthe world of RealPlayer,
which actually had real timestreaming over.
UDP will say, Oh, can we bring back theseold things 20 years later
and web RTC alreadydoes UDP So can we marry this whole world
where the almost all of the webword work as UDP and real time
(16:01):
and everything would work overUDP underneath
somewhat optimized for TCP,
but you know, no demise is complete.
Uh, yeah.
I love going back and and watching like
computer scientistfrom like the sixties seventies
talk about ideas and things they hadand you realize there's nothing new.
(16:23):
Everything's reinvention.
Everyone thought of everythinga long time ago.
It's just taken a while for thingsto mature, and maturity usually just means
going through two or three life spansof every iterating on the same thing.
So sounds familiar from my world.
Yeah.
And although I would saywhat's changed from the sixties
is how easy it has becometo, like, build these things for sure.
(16:45):
Yeah. Developers are super powered now.
Spoiled.
I remember back in the nineties, menlike you want to learn something,
you got to buy a book,you got to buy software.
Now everything's open source, freelydocumented, wonderful.
Languages.
Probably have no excuse
for not knowing this video stuff,but I just never had a job doing it.
Yeah,
I guess what are
as things are kind of coming togetherthese days
(17:07):
and perhaps converging a bit like whatdo you see as kind of the big challenges?
I mean, I look at like these reportssaying like, you know, 80% of the Internet
traffic is video streaming and stufflike this, that it's just like
there's got to be crazy challengesassociated with that.
Yeah, I think ten years agoit was all about streaming.
The things like Netflixand YouTube were like the the 80%
(17:30):
the pandemic shifted that to, you know,like the number of video calls
we had on every day,like when we were in the office
or even like before, like people did,like maybe a few calls a day.
Some of them some people did one a weekor further apart.
But we are down doing,
you know, everyone's doing itat least one or more calls for per day.
(17:50):
So the real time videos
is more prevalent. Now
I am going to go back to the threeuse cases
the can media,live streaming and real time.
I think what the biggest challenges thatpeople are thinking of newer experiences
where they're thinking aboutlike how you and I are having this
(18:12):
interaction while, you know,there could be a hundred thousand people
watching this and people think of Twitchbeing like one way to do this
and people like, Oh,how do I bring Twitch to my community?
I don't necessarily want to use Twitch,but I want to like
have my experience,which does sort of roughly the same thing.
But I also want like peopleto have interactivity,
like, you know, be able to clapor like do emotions.
(18:34):
And if you just look at the announcementfrom WBEZ last week, like, you know,
Apple came out
with like screen chatting,large screen chatting, like your video.
You have your slides, you can go backand forth between between that,
you have a TV, Apple TV, and you can useyour camera like as a as a device.
(18:54):
And then it will you can do share plays.
So like there are so many such use cases
that people are thinking aboutand vision is coming in.
Now people talk about the metaverseat length for both home use cases.
And so video is just going to,you know, everyone's going to have videos
and this is outside of like all the ring
devices that we have or like the doorbells
(19:15):
and like the surveillance stuffthat's happening, packed cameras and such.
So video is just like immense.
And depending on what slew
of use cases you look at, you just seevideo
emerge more and more across the US.
So the biggest challenge is likeif I'm thinking of
like a use casethat goes beyond just the solitary.
(19:36):
So like if I'm just doing surveillanceand the doorbell, you know, you say, okay,
that's maybe one use case, but suddenlyyou say, like, I think the doorbell,
you're not at home,you're at work, you have to open the door.
Now, you want to havethis interaction now.
It's not just like recording surveillance,but it's also like a real
time interaction.
And you want sometimes now with an email,people like, Hey, I want to like be able
(19:58):
to detect, you know, someonepassing by to a bunch of alerts,
send a thing, maybe patch the user in
to talk
to this personwho may not have rang the bell as yet.
Right. So
in that case, you're thinking of theseas three different technologies
or two different technologies, artists,is that it should be one technology.
(20:21):
It could be, you know,it could be several vendor, like it
shouldn't be several vendors,but like the vendors
need to be thinking about like,how do I solve this
problem without actually having thedeveloper go to think too much about it?
So when I said earlier,
so just like a callback to one API,
basically saying it shouldn't matter,I'm talking to, you know,
(20:43):
like a server recordingor like basically an email algorithm
which like finds the thingthat triggers a communication
or repressed ableto like get the person into the call.
All of that, like from an engineeringperspective, should be hidden.
And that's how we get
accelerated into like people buildingmore robust, unique use cases.
(21:05):
Because if everyone's trying to solvelike what I call protocol shenanigans,
like you go from one protocol
to another, then, you know,they all they don't always work together.
Then you spend a lot of time debugging
and trying to likemake them kind of massage them into place.
And that can be the same with multiplevendors.
You're like, Hey,this thing has a different state.
(21:26):
It gets triggered at a different point.
The state machines don't match.
How do I make the state machines matchso that I can make them work together?
I think those are the biggestchallenges and
we have a perception that, you know,having very simple APIs that solve
all these problems under the hoodkind of takes away some of that
(21:48):
mental gymnastics that you
might have to do to like kind ofget these things to work together.
Yeah, it was easy enough to seeand kind of surveying this stuff.
I mean, even just video encoding
formats, it's mind bogglinghow many of these things are all
like I it's just like a topicI hadn't paid attention to in a long time.
I was curious though, you know,
(22:09):
in the more kind of synchronousand like event driven things,
there's always this challenge of ofhow do you kind of design how these
things are going to work or look at scalewhen you have lots and lots of them
so that people can find the right thing,understand how to use it.
Are there sort of common issues like thatin the streaming world?
I mean, it's kind of weirdbecause it's like you're basically
(22:30):
just grabbing whatever video comes at youand throw it the other way
in some sense. But,
you know, when youthink about like starting from scratch,
providing a developer experiencefor integrating with these things,
what are the design challenges?
Yeah, if you come from anit should be model of thinking
it's slightly differentbecause like an it should be the resource
(22:52):
needs to be like replicatedin many places, right?
Like you basically sayoh someone let's say
even in the case of Facebook
messages or whatever, like the thing islike someone writes a message,
you push it to the webserver, the web server, replicate that
in one or more placesin databases and caches, so many places.
And then someone who's reading itlike pulled it.
And the design problem that is like,how quickly are you,
(23:14):
you know, like ingesting this dataand how quickly are you like
exposing this informationlike a new message, right?
So like you have pub sub like aas a design parameter where you're like,
I'm publishing information,I'm subscribing to this information.
And if the system knowsthat there is a live subscription
on this publish, then there's a fast track
to like
(23:34):
kind of make this messagego faster to that subscription
while you're still also putting itto disk.
There's a lot of HTP stuffthat you can use
for like standard messagesif you are like thinking about data.
Unfortunately, that same thing
for real time is a work in progress.
So what we call selectiveforwarding units,
(23:57):
they've existed for about like ten,12 years.
It started with like thoughthere used to be something called
Multi controlunit Amcos and SFE was now the thing.
There was like if you rememberwhen when we had offices and rooms
and room systems, like you went to a roomand you had a video system that insisted
on saw people on television,typically they would composite the video.
(24:20):
So like if you want,
if there are five people in a video,there were like there was some server
in the cloudthat would composite them together,
like small, big,whatever, whoever is speaking someone,
but like the algorithm would control it,but you would only get one stream.
So even if there werefive people on the video,
the compositingin the cloud was doing that.
And that made sense.
Like if you're Ciscoand you're selling servers,
(24:41):
it's our job to like kind of sell you likeit made like you could buy a heavier,
more expensive server, which would do like20 people or 40 people.
So like there was business need and Ciscowas in the business of selling servers.
I didn't like that was what they diduntil like ten years ago
when select the forwarding unitsand like as you're scaling,
(25:01):
you have 20 people you can't actuallycomposited anymore, right?
Like it's too much computing resources onthe cloud and someone has to pay for it.
So people realize that instead oflike having very large servers, what if we
distributed these arrows across the worldand they selectively forward?
So like if you are on a big call,
let's say a Peloton ride, like that'sa very good example, like there's a train,
(25:23):
are you looking at the train or but you'realso a group of cohort of friends
who are likewho are doing this exercise together.
But there are also like 50 other peoplewho you don't know who are on the call
to like it becomes like,I want to watch the trainer.
I want to have a synchronized livecommunication with my friends,
which is private.
We don't want to train our dog.You have that.
(25:45):
But then there's also like the
for the other peoplethat I want to see in small like.
So you basically have this threemodalities now that that's happening.
One, follow the trainer
common with your friendsand then watch the rest of the class.
Now, in this case, as you were like,think about,
you know, which ones can be delayed,what are the latency
(26:06):
guarantees for each subset.
And that's what the selected forwardingunit would do.
So basicallythe end point would have more control.
You know, I as an end user who's onthe bike, can decide who I want to watch
at what priority, and you kind of movethe logic away from that server side
(26:26):
largelyto the endpoints because the endpoints
and then you need that magic, right?
Like if I have about connection, I still Iif I can't carry all those 60 streams
but streams, should I prioritize,which stream
should I see in high resolutionat high frame rate.
Which onescan I do at low resolution law firm.
Which one's going to turn off. Right.
Like I can turn off the classif I don't have enough bandwidth
(26:49):
and I just want to list
like and if I really low thenI should just see the the the trainer.
And if I can't see the trainer,then I should either listen to the trainer
or I should just see the trainerand turn off
and like some of that magiccan happen on the on the cloud.
So basically
for this,you can do something off the shelf.
There are some open source things.
Of course, you can build on top of. But
(27:12):
but some of these things,like if you talk about mesh as if you
which is like you have a sphereand then you how do you scale
like you can horizontally scale somethingor you can vertically scale something.
And typicallyif you want to get 100,000 people
watching some stream simultaneously,you'll horizontally scale it, right?
So that is like the magic that we bring iswe have something called mesh as a few,
(27:35):
which allows you to like horizontally,so be horizontally scale so that you don't
have to worry about like you have tenpeople in the call or 100,000.
We will figure out how to do that.
We give you enough APIs to expresslike what are the priority levels?
You figured out how much bandwidthour servers figured out
for how much bandwidth you haveso that we can downstream
(27:55):
the appropriate amount of dataso that you can have a good experience.
Developers can say like, you know,in the worst case, what would they want?
But they prefer video or audio.
So in the worst case,
then we can use their input as guidance.
So there we can.
The server is going to decidewhat to do in those circumstances.
(28:16):
Yeah, all this stuff makes my head hurt,
which I.
I noted that you've also are workingon a book
on kind of this live streaming typetech stuff.
You're going to tell us a little bitabout that.
Yeah, we, uh, we are cooperatingwith the Dummies franchise,
(28:36):
so there's a dummies for interactivelivestreaming that will come later
this summer.
The idea here was to, like, put together
these three aspects, like
the different various use
cases people have, both for livestreamingand in real time.
That's one part of the book.
The second part isthe protocol shenanigans.
Like there's so many protocols
(28:57):
that all four letter acronymsand you have to learn so much before.
How do you like reconcile all of thatinto like one holistic viewpoint?
So mental model for that?
And thirdly, like,
what would the API look for look like?
So we've had the product out for overtwo years now.
So writingthis book is a point in time to say
(29:20):
that, you know,this is not really that complex.
The use case has have emergedand people are thinking about
this experience more widely than
people know,and there are simpler ways of doing this.
So one mental model or one API and one
and if you care about the underpinnings,it's one protocol
(29:41):
that drives all of this.
So normally this is the part of the showwhere I ask
guests, you know,where do you think if you had to
point someone in the right directionon where to get started, where they go,
my hunch is
you might just answer, read the book,but I'm going to throw it out there.
You know, for someone just getting goingin this, you know, What's your advice?
(30:04):
Yeah, I mean, we have
really good blog posts on daily codethat you can go and find so that you try
a less interactive livestreamingdeli code.
You'll find it.
I think Dr.
Start DailyKos is like a really goodstarting point for this.
If you're really curious, like
about the underpinnings of this,you should read for the for the book
to come out.
(30:24):
It explains and like Good Graphicsfor Dummies, for example.
So like, you know, we've tried to likego with that idea that make it accessible
to people who are interactingwith the technology for the first time,
and it should be out in the next 60 days.
So also probably by the timethis goes to air.
(30:46):
Yeah, well, I identify with feelinglike a dummy today on this subject,
so I think you might have picked the rightcategory of book,
but thank you so much for kindof giving us some insight to this stuff.
And I guess for folks, you kind ofwant to learn more here, few more.
I think you're kind of mentionedthe daily blog are
there are other placespeople should follow you.
(31:08):
O follow us on Twitter,Follow us on Mastodon.
We're on all socials, including LinkedIn.
You should you should type daily Dot SEO
and you should find us or daily article.
Thanks again for joining us for him.
Thank you, Jason. Thanks.
Thanks a lot for inviting meon having this conversation.
(31:29):
It's been fun.
Thanks for listening.
If you have a question you want to ask,look in the description of whichever
platform you're viewing or listening onand there should be a link there
so you can go submit a questionand we'll do our best to find out
the right answer for you.
(31:56):
API Intersection Podcast listeners
are invited to sign up for Stoplightand save up to $650.
Use the code intersectionten to get 10% off a new subscription
to stoplight platform starter or pro.
Take a look at this episode'sdescription for more details.
I'm JasonHarmon and this is API intersection
where you'll get insights from experiencedAPI practitioners to learn best
practices on thingslike API design, governance, identity,
versioning and more.
(00:22):
Welcome back to API Intersection.
As always, I'm your host, Jason Hartman,CTO from Stoplight.
It's been a little bitsince I've said the phrase today
we're going to do somethinga little different
because I felt like I was beaten to death.
But we really are doing something in two
plus years of the podcastwe really haven't gotten into.
I think we talk a lotabout kind of REST and craft,
(00:43):
you willand all these sort of synchronous APIs.
Sometimes we talk about eventdriven stuff, but today we're going
to really get into kind of real timeand sort of streaming protocol stuff
with quite the expert on the subject.
Mr. Varun same.
Varun, thanks for joining us.
Thank you.
Thank you for inviting me.
Jason. Absolutely.
(01:05):
So, you know,Varun had kind of come to us,
you know, talking about coming on andit was a really easy one to say yes to.
And we kind of looked and he's got 12 IETF
and W3C specifications, numerous patents.
So when it comes to kind of real timestreaming, I think we got the guy here
(01:25):
to bring
us a little bit about kind of your journeyin this streaming stuff
and what put you in your current roleas Chief Product and Technology
officer at Daily, thank you very much.
And yeah, it's been a journey.
I started, you know, about 20 years ago,
straight out of schoolworking for a semiconductor company.
And at that timethe whole range was megapixel cameras.
(01:47):
If you remember, cameras, phones becamesmartphones, smartphones carried cameras.
People started to take pictures.
And that was juxtaposition by a Web 2.0,like emerging in the same period.
I used to work for a companycalled SD Micro Electronics,
and then at Nokia, both of those roles,I was working on cameras
(02:08):
and the camera hardwareand the software that goes with it,
and that's how I got
into the space and my background beforethat was like communications.
I came from an electrical engineeringbackground and such
as, you know, historic playlike two, 15 years ago,
like we had this issue with Nokiabeing like, outcompeted by Apple and such.
(02:30):
So at that time I kind of leftthe industry to pursue a Ph.D.
and I started to work on real timecommunications
because that was the evolutionof like taking cameras
from like taking still picturesand recording and storing it
locally on your device,still like live streaming it
or like communicating with another personacross the across the Internet.
(02:51):
So things like Skypeand what really changed like 15 years ago
was the insight that we've been buildingreal time communications in silos.
So you had the Cisco's, you had the Skype,you had the my Microsoft Messengers.
They were all building these attacksindependently,
trying to solvethe same problem repeatedly.
And people envision that a
(03:11):
Web point, a web 2.0 had to, like, achieveits full success.
It would have to be ableto, like, work with these protocols
so that anyone could build.
Like right now we are using Xen Kastor,you know, like the fact that we are able
to communicate and a product like Xen,Kastor does not have to rely on like
Skype or Zoom or anything.
It can actually usesome of the native APIs available.
(03:34):
So the question became like,what is the big gap between like
these siloed solutions and how to make itaccessible through three APIs?
So that was the work that happenedten years ago,
and that's why the idea of documents
and the W3C specifications came outlike the industry got together.
You know,
while biggest companies
said, okay, we solve these problemsrepeatedly by ourselves,
(03:55):
of course, with cross-pollination,how do we make it accessible?
I eventually graduated with my Ph.D.
around the same timewhen the protocols came to light,
I built a company called called Statoil.
You can think of it as like analyticsfor real time communication.
So just like GoogleAnalytics is for web called stats.
As far as for real time and R&R businessfor four, seven, eight years.
(04:19):
Eventually we exitedjust before the pandemic.
So maybe not the best timing.
You know, we've been,
you know, trying to grow this productfor four, five, six, seven years.
And, you know, if you're venture backed,there's a big emphasis
to actually like keep doingtriple, triple, double, double.
We did a couple of triples and doubles,but at some point we flattened out
because the market kind of maturedand we can see it grow
(04:44):
faster.
And then the pandemic happenedand like everything grew.
That brought me to my current roleat Daily
Deli was a customer of cloud statsfor several years, but
because of the pandemic,it fueled its growth.
And Deli is basically an API for real timecommunication
for the widest set of use casesthat you want to build on video.
(05:07):
And lastly, it's a third gen
iteration.
So the first gen was ten years agowhen when real time communications
first appeared or a bunch of companiesthat started then.
Then five years later,
the second gen of companies and thenthe third gen which is which is daily.
And I think the big differencebetween the third
and the first gen was like developertools.
(05:28):
Ten years ago there was no react,there was no React native
like people were writing vanilla jazz.
So the type of APIs are builtfor that period of time versus today,
where you have universal,you have next years,
you have like React Native,you have Android iOS, you want to like
be able to satisfy all these thingsand people want to use no fear and react.
(05:49):
Where do you want to use components,Hooks, all that stuff are used.
The lower level API, which is led directly
to asa product company, which builds APIs.
We have to satisfy like a
slew of things depending on, you know,
you're basically, you know, codewas, is like, oh, I want to like control
(06:11):
every aspect of my experience, bothor both ends of the spectrum.
So that's how I got into my current role.
Very cool kind of progression.
I like that connectionof like how videos changed
as sort of the mobile worldand the web has changed, but
full disclosure hereI am not a video or streaming guy.
(06:33):
I don't know much about this and askyou like a million dumb questions today.
And my hunch iswe have a lot of perfectly fine.
So I guess the first one isare we talking about like the stuff that,
you know, when I watch Netflix or YouTube,is it that or is it zoom or is it,
you know, what kind of sort of streamingthings are you talking about?
(06:53):
That's a good question.
And I think the way we think about it,
there are scanned media or stored media,which is what Netflix is all about.
Like, you know, you're watching a show,the show exists somewhere.
They can actually use things
like distribution networks, iTunesto kind of push it as close to the edge
so that you get you as an end userget a great performance.
(07:15):
That's one aspectand that's what we call stored media.
It's been happeningfor almost 30 years now.
The technology has improved vastlythat you can like actually do a very quick
like changes in quality
which are not perceivable to the human,
even if you have a network issue.
So that's more or less solved problem.
There are a bunch of companiesthat try to do that.
(07:38):
A lot of the magic is in the contentdelivery network.
So video content delivery networks,the second one, which is live streaming.
So, you know, we just had the NHL playoffsand the NBA playoffs this last week.
And if you're watchingsomething like that, I think there
the biggest thing is that it can be storedbecause you're watching it.
(07:58):
And then the questionis how far behind real time can you be?
It can't be really,really live like it can be.
But like most often it's
like a couple of seconds behind,mainly because they want to,
you know, for legal reasons, but also theywant to distribute it widely.
That's called live streaming.
Typically today, most of their technology
(08:20):
is 5 seconds behind.
So basically, if a goal happens,
you you can see it on your screen, five,5 to 10, 15 seconds behind real time.
The main notion that is thatyou should even be screaming goal
before your neighbor dies or vice versa.
Your neighbor should be screaming goalor scorer before before you fight.
(08:42):
So that's like the biggest challengein that in that framework.
And the third one,which is like real time communications
where you are seeing something liveand what we've seen over the last
ten years is that we start with two peopleand I call like, like just like Skype
and whatever came after two peoplehaving a conversation
(09:02):
and then people said, Oh,we want to use it in a work setting.
Can we have five or six people?
And in a call during the pandemicthat became, you know, town halls, 15
people, 30 people, and now we routinelysee like ten people in a call.
The questionnow becomes like all these use cases,
like the live streamingbefore that I talked about where
there are millions of peoplewatching this like the game.
Can you do that in real time?
(09:23):
Can we use the protocols that we usefor like having real time communication?
And herewe're talking about 200 milliseconds
delay by like between you and I,we probably like tens of milliseconds
because weare roughly in the same part of the world.
But Max, like, you know, if you're halfwayaround the world, a speed of light,
you can go faster than the speedof light and cables and all those things.
(09:45):
So, you know, you're about 300,400 milliseconds behind,
but still good for interactivityin case you want to raise your hand and,
you know, like if you're having a big townhall, you know,
10,000 people watching the CEO speakand someone wants to ask a question,
you should be able to raise your hand,get on the floor through the green room
or whatever, and ask the question liveand then hear the answer.
(10:06):
So those are the use casesthat a lot of people are aspiring for.
And I think the the blurry linesbetween these three use cases
like the live stream,the CAM media, the live streaming
and real time communications are blurringlike becoming blurred.
People want to usenot three different protocols
or three different technologiesor three different vendors to do it.
(10:27):
People want to roughly use this one API,one render, and does it matter?
Should it matter that I'm connected to youin real time or I'm connected to
like a sporting event, sporting event andor like getting something from Netflix?
Like basicallythe API should be I'm playing video.
The sort of source could be,you know, live or real time.
(10:48):
AR Can Yeah,I was going to ask that to looking through
some of your IETF work in these things,I saw a lot of like RTP Web RTC, things
like this in these kind of categories,like what are sort of the common protocols
and where do you see thatthings are perhaps converging?
It's a good question, and I thinkeverything that is old becomes new again.
(11:09):
So RTP is like 30 years old technology,and it started
for broadcast or multicast.
And if you know, like if you know
your IP addresses, you know, there's likea set of multicast addresses at the end
which are not accessiblemostly because like the ISP's don't
allow like transmission, like if you're onVerizon, Verizon will not allow like a,
(11:32):
like a multicast beyond its boundary,but for security reasons.
But also
they don't want to send media outsideand like then get media from outside.
So it's time for multicast.
And a lot of the design thing decisionswe made for RTP were based on multicast.
However, like by 2000 to the 1992when they built the protocol
by 2001, 2002 multicast was kind of dead.
(11:55):
It was only used in IPTV.
So you are cable TVnetwork was probably is probably
still using broadcast to likesend your cable TV over over cable.
But you know it's comingdirectly from your provider
and that's typically the personyou bought the Internet from anyway. So,
so that still exists and still continues.
(12:16):
And when I talked about earlier,like MSN or Yahoo
or like all these messengers from,you know, 20 years ago,
they all actually used RTP,including Skype
at some point
started to use RTP because that'swhere all the engineers knew it, right?
Like if
you move from one company to another,you can like learn a new protocol.
Like it'll just takeyou like two years before you're like,
(12:37):
competent in that new thingand you're just re learning something.
So like, RTP is like the standardwhat Web RTC was.
And like, people talk about Web RTCboth as a protocol
and as an API,and they use them interchangeably.
So there are two aspects of Web RTC.
One is the API, which was standardizedand implemented by the browsers.
(12:58):
Of course, you know, the browser API
is called Live Web RTC, it's insidechromium.
It's also insidelike all chromium derivatives.
So Brave edge are all these browsershave it and then Mozilla has of
has their own version of web already Cand Safari has a
somewhat different version,but the API is a standard,
so it doesn't matter which browser you useor if you take that library
(13:21):
and they compile it into Android and iOS,you still have like the same APIs
because the Web APIshave a corresponding C++ layer.
So you can call these APIs anywhere.
And then APIs inthis case are not sufficient
because there's a protocol that like sendsthe media over the Internet.
So those areso that's the Web RTC protocols
(13:45):
and Web RTCprotocols are actually all old protocols.
As I said before,you know, all these companies had Cisco
Skype had their versions of their product,
and they're all slightly differentversions of RTP with extensions.
You know, if you're doing
two cameras, one camera every likeno one uses the standard process
(14:07):
or the standard protocolsbecause there's always something
that they need to do extra.
Either their codecs are different,like each two six, 4 to 6 five.
So back in 2010,when we decided to work on this,
people realized that there wasa lot of competence across the industry,
but no one had a standardized wayof doing certain things.
So the whole thing aboutWeb RTC protocols is just
(14:30):
the whole industry coming togetherand saying, like these variants
and these extensions of the protocolswill do these things.
And then that meant like you nowhad Cisco, WebEx, Zoom,
all of these folks using roughlythe same kind of things behind the scenes.
Yeah, it's funny, as I was kind ofskimming around trying to not sound like
a total idiot on this subject and knowvaguely what you're talking about.
(14:52):
I was getting flashbacks of likereal player and some of these old things
that are in and using all this stuff.Yeah.
Real player is a good exampleof like all the things becoming new.
So there was a thing in RealPlayercalled DSP real time streaming protocol
and it uses RTP underneath web RTC usesRTP underneath.
So it's RTP by itselfas a unit block is quite versatile.
(15:16):
Of course,it was built for a different time, so
and for all things becoming new now,there's a whole new initiative
called Middleware Quik.
And if you quick is like this new protocol
that is over UDP instead of TCP
and it's UDPthree uses quick, for example too.
And there's a whole reasonwhy we use UDP now
(15:39):
or instead of TCP for all these things.
So people are reimaginingthe world of RealPlayer,
which actually had real timestreaming over.
UDP will say, Oh, can we bring back theseold things 20 years later
and web RTC alreadydoes UDP So can we marry this whole world
where the almost all of the webword work as UDP and real time
(16:01):
and everything would work overUDP underneath
somewhat optimized for TCP,
but you know, no demise is complete.
Uh, yeah.
I love going back and and watching like
computer scientistfrom like the sixties seventies
talk about ideas and things they hadand you realize there's nothing new.
(16:23):
Everything's reinvention.
Everyone thought of everythinga long time ago.
It's just taken a while for thingsto mature, and maturity usually just means
going through two or three life spansof every iterating on the same thing.
So sounds familiar from my world.
Yeah.
And although I would saywhat's changed from the sixties
is how easy it has becometo, like, build these things for sure.
(16:45):
Yeah. Developers are super powered now.
Spoiled.
I remember back in the nineties, menlike you want to learn something,
you got to buy a book,you got to buy software.
Now everything's open source, freelydocumented, wonderful.
Languages.
Probably have no excuse
for not knowing this video stuff,but I just never had a job doing it.
Yeah,
I guess what are
as things are kind of coming togetherthese days
(17:07):
and perhaps converging a bit like whatdo you see as kind of the big challenges?
I mean, I look at like these reportssaying like, you know, 80% of the Internet
traffic is video streaming and stufflike this, that it's just like
there's got to be crazy challengesassociated with that.
Yeah, I think ten years agoit was all about streaming.
The things like Netflixand YouTube were like the the 80%
(17:30):
the pandemic shifted that to, you know,like the number of video calls
we had on every day,like when we were in the office
or even like before, like people did,like maybe a few calls a day.
Some of them some people did one a weekor further apart.
But we are down doing,
you know, everyone's doing itat least one or more calls for per day.
(17:50):
So the real time videos
is more prevalent. Now
I am going to go back to the threeuse cases
the can media,live streaming and real time.
I think what the biggest challenges thatpeople are thinking of newer experiences
where they're thinking aboutlike how you and I are having this
(18:12):
interaction while, you know,there could be a hundred thousand people
watching this and people think of Twitchbeing like one way to do this
and people like, Oh,how do I bring Twitch to my community?
I don't necessarily want to use Twitch,but I want to like
have my experience,which does sort of roughly the same thing.
But I also want like peopleto have interactivity,
like, you know, be able to clapor like do emotions.
(18:34):
And if you just look at the announcementfrom WBEZ last week, like, you know,
Apple came out
with like screen chatting,large screen chatting, like your video.
You have your slides, you can go backand forth between between that,
you have a TV, Apple TV, and you can useyour camera like as a as a device.
(18:54):
And then it will you can do share plays.
So like there are so many such use cases
that people are thinking aboutand vision is coming in.
Now people talk about the metaverseat length for both home use cases.
And so video is just going to,you know, everyone's going to have videos
and this is outside of like all the ring
devices that we have or like the doorbells
(19:15):
and like the surveillance stuffthat's happening, packed cameras and such.
So video is just like immense.
And depending on what slew
of use cases you look at, you just seevideo
emerge more and more across the US.
So the biggest challenge is likeif I'm thinking of
like a use casethat goes beyond just the solitary.
(19:36):
So like if I'm just doing surveillanceand the doorbell, you know, you say, okay,
that's maybe one use case, but suddenlyyou say, like, I think the doorbell,
you're not at home,you're at work, you have to open the door.
Now, you want to havethis interaction now.
It's not just like recording surveillance,but it's also like a real
time interaction.
And you want sometimes now with an email,people like, Hey, I want to like be able
(19:58):
to detect, you know, someonepassing by to a bunch of alerts,
send a thing, maybe patch the user in
to talk
to this personwho may not have rang the bell as yet.
Right. So
in that case, you're thinking of theseas three different technologies
or two different technologies, artists,is that it should be one technology.
(20:21):
It could be, you know,it could be several vendor, like it
shouldn't be several vendors,but like the vendors
need to be thinking about like,how do I solve this
problem without actually having thedeveloper go to think too much about it?
So when I said earlier,
so just like a callback to one API,
basically saying it shouldn't matter,I'm talking to, you know,
(20:43):
like a server recordingor like basically an email algorithm
which like finds the thingthat triggers a communication
or repressed ableto like get the person into the call.
All of that, like from an engineeringperspective, should be hidden.
And that's how we get
accelerated into like people buildingmore robust, unique use cases.
(21:05):
Because if everyone's trying to solvelike what I call protocol shenanigans,
like you go from one protocol
to another, then, you know,they all they don't always work together.
Then you spend a lot of time debugging
and trying to likemake them kind of massage them into place.
And that can be the same with multiplevendors.
You're like, Hey,this thing has a different state.
(21:26):
It gets triggered at a different point.
The state machines don't match.
How do I make the state machines matchso that I can make them work together?
I think those are the biggestchallenges and
we have a perception that, you know,having very simple APIs that solve
all these problems under the hoodkind of takes away some of that
(21:48):
mental gymnastics that you
might have to do to like kind ofget these things to work together.
Yeah, it was easy enough to seeand kind of surveying this stuff.
I mean, even just video encoding
formats, it's mind bogglinghow many of these things are all
like I it's just like a topicI hadn't paid attention to in a long time.
I was curious though, you know,
(22:09):
in the more kind of synchronousand like event driven things,
there's always this challenge of ofhow do you kind of design how these
things are going to work or look at scalewhen you have lots and lots of them
so that people can find the right thing,understand how to use it.
Are there sort of common issues like thatin the streaming world?
I mean, it's kind of weirdbecause it's like you're basically
(22:30):
just grabbing whatever video comes at youand throw it the other way
in some sense. But,
you know, when youthink about like starting from scratch,
providing a developer experiencefor integrating with these things,
what are the design challenges?
Yeah, if you come from anit should be model of thinking
it's slightly differentbecause like an it should be the resource
(22:52):
needs to be like replicatedin many places, right?
Like you basically sayoh someone let's say
even in the case of Facebook
messages or whatever, like the thing islike someone writes a message,
you push it to the webserver, the web server, replicate that
in one or more placesin databases and caches, so many places.
And then someone who's reading itlike pulled it.
And the design problem that is like,how quickly are you,
(23:14):
you know, like ingesting this dataand how quickly are you like
exposing this informationlike a new message, right?
So like you have pub sub like aas a design parameter where you're like,
I'm publishing information,I'm subscribing to this information.
And if the system knowsthat there is a live subscription
on this publish, then there's a fast track
to like
(23:34):
kind of make this messagego faster to that subscription
while you're still also putting itto disk.
There's a lot of HTP stuffthat you can use
for like standard messagesif you are like thinking about data.
Unfortunately, that same thing
for real time is a work in progress.
So what we call selectiveforwarding units,
(23:57):
they've existed for about like ten,12 years.
It started with like thoughthere used to be something called
Multi controlunit Amcos and SFE was now the thing.
There was like if you rememberwhen when we had offices and rooms
and room systems, like you went to a roomand you had a video system that insisted
on saw people on television,typically they would composite the video.
(24:20):
So like if you want,
if there are five people in a video,there were like there was some server
in the cloudthat would composite them together,
like small, big,whatever, whoever is speaking someone,
but like the algorithm would control it,but you would only get one stream.
So even if there werefive people on the video,
the compositingin the cloud was doing that.
And that made sense.
Like if you're Ciscoand you're selling servers,
(24:41):
it's our job to like kind of sell you likeit made like you could buy a heavier,
more expensive server, which would do like20 people or 40 people.
So like there was business need and Ciscowas in the business of selling servers.
I didn't like that was what they diduntil like ten years ago
when select the forwarding unitsand like as you're scaling,
(25:01):
you have 20 people you can't actuallycomposited anymore, right?
Like it's too much computing resources onthe cloud and someone has to pay for it.
So people realize that instead oflike having very large servers, what if we
distributed these arrows across the worldand they selectively forward?
So like if you are on a big call,
let's say a Peloton ride, like that'sa very good example, like there's a train,
(25:23):
are you looking at the train or but you'realso a group of cohort of friends
who are likewho are doing this exercise together.
But there are also like 50 other peoplewho you don't know who are on the call
to like it becomes like,I want to watch the trainer.
I want to have a synchronized livecommunication with my friends,
which is private.
We don't want to train our dog.You have that.
(25:45):
But then there's also like the
for the other peoplethat I want to see in small like.
So you basically have this threemodalities now that that's happening.
One, follow the trainer
common with your friendsand then watch the rest of the class.
Now, in this case, as you were like,think about,
you know, which ones can be delayed,what are the latency
(26:06):
guarantees for each subset.
And that's what the selected forwardingunit would do.
So basicallythe end point would have more control.
You know, I as an end user who's onthe bike, can decide who I want to watch
at what priority, and you kind of movethe logic away from that server side
(26:26):
largelyto the endpoints because the endpoints
and then you need that magic, right?
Like if I have about connection, I still Iif I can't carry all those 60 streams
but streams, should I prioritize,which stream
should I see in high resolutionat high frame rate.
Which onescan I do at low resolution law firm.
Which one's going to turn off. Right.
Like I can turn off the classif I don't have enough bandwidth
(26:49):
and I just want to list
like and if I really low thenI should just see the the the trainer.
And if I can't see the trainer,then I should either listen to the trainer
or I should just see the trainerand turn off
and like some of that magiccan happen on the on the cloud.
So basically
for this,you can do something off the shelf.
There are some open source things.
Of course, you can build on top of. But
(27:12):
but some of these things,like if you talk about mesh as if you
which is like you have a sphereand then you how do you scale
like you can horizontally scale somethingor you can vertically scale something.
And typicallyif you want to get 100,000 people
watching some stream simultaneously,you'll horizontally scale it, right?
So that is like the magic that we bring iswe have something called mesh as a few,
(27:35):
which allows you to like horizontally,so be horizontally scale so that you don't
have to worry about like you have tenpeople in the call or 100,000.
We will figure out how to do that.
We give you enough APIs to expresslike what are the priority levels?
You figured out how much bandwidthour servers figured out
for how much bandwidth you haveso that we can downstream
(27:55):
the appropriate amount of dataso that you can have a good experience.
Developers can say like, you know,in the worst case, what would they want?
But they prefer video or audio.
So in the worst case,
then we can use their input as guidance.
So there we can.
The server is going to decidewhat to do in those circumstances.
(28:16):
Yeah, all this stuff makes my head hurt,
which I.
I noted that you've also are workingon a book
on kind of this live streaming typetech stuff.
You're going to tell us a little bitabout that.
Yeah, we, uh, we are cooperatingwith the Dummies franchise,
(28:36):
so there's a dummies for interactivelivestreaming that will come later
this summer.
The idea here was to, like, put together
these three aspects, like
the different various use
cases people have, both for livestreamingand in real time.
That's one part of the book.
The second part isthe protocol shenanigans.
Like there's so many protocols
(28:57):
that all four letter acronymsand you have to learn so much before.
How do you like reconcile all of thatinto like one holistic viewpoint?
So mental model for that?
And thirdly, like,
what would the API look for look like?
So we've had the product out for overtwo years now.
So writingthis book is a point in time to say
(29:20):
that, you know,this is not really that complex.
The use case has have emergedand people are thinking about
this experience more widely than
people know,and there are simpler ways of doing this.
So one mental model or one API and one
and if you care about the underpinnings,it's one protocol
(29:41):
that drives all of this.
So normally this is the part of the showwhere I ask
guests, you know,where do you think if you had to
point someone in the right directionon where to get started, where they go,
my hunch is
you might just answer, read the book,but I'm going to throw it out there.
You know, for someone just getting goingin this, you know, What's your advice?
(30:04):
Yeah, I mean, we have
really good blog posts on daily codethat you can go and find so that you try
a less interactive livestreamingdeli code.
You'll find it.
I think Dr.
Start DailyKos is like a really goodstarting point for this.
If you're really curious, like
about the underpinnings of this,you should read for the for the book
to come out.
(30:24):
It explains and like Good Graphicsfor Dummies, for example.
So like, you know, we've tried to likego with that idea that make it accessible
to people who are interactingwith the technology for the first time,
and it should be out in the next 60 days.
So also probably by the timethis goes to air.
(30:46):
Yeah, well, I identify with feelinglike a dummy today on this subject,
so I think you might have picked the rightcategory of book,
but thank you so much for kindof giving us some insight to this stuff.
And I guess for folks, you kind ofwant to learn more here, few more.
I think you're kind of mentionedthe daily blog are
there are other placespeople should follow you.
(31:08):
O follow us on Twitter,Follow us on Mastodon.
We're on all socials, including LinkedIn.
You should you should type daily Dot SEO
and you should find us or daily article.
Thanks again for joining us for him.
Thank you, Jason. Thanks.
Thanks a lot for inviting meon having this conversation.
(31:29):
It's been fun.
Thanks for listening.
If you have a question you want to ask,look in the description of whichever
platform you're viewing or listening onand there should be a link there
so you can go submit a questionand we'll do our best to find out
the right answer for you.
(31:56):
API Intersection Podcast listeners
are invited to sign up for Stoplightand save up to $650.
Use the code intersectionten to get 10% off a new subscription
to stoplight platform starter or pro.
Take a look at this episode'sdescription for more details.
Popular Podcasts
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
24/7 News: The Latest
The latest news in 4 minutes updated every hour, every day.
Therapy Gecko
An unlicensed lizard psychologist travels the universe talking to strangers about absolutely nothing. TO CALL THE GECKO: follow me on https://www.twitch.tv/lyleforever to get a notification for when I am taking calls. I am usually live Mondays, Wednesdays, and Fridays but lately a lot of other times too. I am a gecko.