Okay, this is gonna be an exciting one. We're gonna be talking about product development uh with uh quite an auspicious crew here. We've got Elliot from Expo, we've got Reed from uh Skylight Social, we've got Eli from uh Streamplace, and uh and then we've got uh Paul Frazee uh from Bluesky. So I'm gonna let him take it away. All right. Welcome. I should give you the mic. Oh yeah, we do need the mic. All right, welcome everyone. Thank you so much for being here. Um just to start, I would love to have you guys introduce yourselves uh a little bit about yourself, what you're working on.
And we'll go from there. All right, sounds good. Good. Well that's the other one. Hey, there we go. There we go. Well, hi everybody, I'm Paul Frazy. I'm the CTO at Bluesky. Um I think the specific reason I'm on the panel is because uh back when Bluesky was very small, I was the lead engineer on building the Bluesky application, which I did with Expo and React Native. And uh I'll just go ahead and spoiler alert. Wouldn't have been able to do it without the help of uh Expo and React Native. So I'm here to share that story.
My name's Eli Mallon. I'm the founder and uh CEO of Streamplace. If you're watching this remotely right now, that's that thing. And uh I also uh from from the start, um we have uh built Streamplace using Expo and React Native WebRTC and uh and some other technologies that we will get into. And I'm Reed, the CTO of Skylight Social, and we built Skylight on Expo. I've been using React Native since like 2017, and um when we thought about how to build this uh video app, we were like, okay, well we're gonna start with React Native. Um and then luckily for us, the video component itself was already a library that Expo was offering.
So we were able to get like a working prototype in two days and kind of release it before TikTok had gotten banned last January. Cool. So Paul, just to start with you, you mentioned you know Expo made a lot of stuff possible. And so I wanted to start this into the whole panel, but like what is Expo specifically made possible? What is App Proto made possible? I guess Bluesky is built on it, but like how have they kind of combined in building up Bluesky, especially in the early days. Yeah, so um should we assume that people know what Expo is?
I can't. Oh yes. Okay. Expo is a way to build cross-platform mobile apps were the main way of building mobile apps with uh JavaScript or TypeScript, and then they run on both iOS and Android. Yeah. Well, and so for us, um kicking off, we had 12 people maybe when we were first writing the uh Bluesky. Actually, not even that. I think we were maybe at like six when we were first building the application. And the reality is that when you have a code base that uh is an application for every code base you have is a different product, more or less.
So if you're trying to write for both you know free platforms really iOS, Android, and web, if you're building three different code bases, you basically have three different products with their own teams that are maintaining their own roadmaps, their own issue trackers and things like that, and you're kind of just working with each other on the concepts that you're gonna you know implement um on each one of them. Uh you see this sometimes actually when you switch between apps uh like um I think Twitter for a long time had a pretty different like you would get into the Android one be like, oh it's kinda different, actually.
That's interesting. Because it's a different product. It's a different team. Um so that was just not viable for us. We it was just me doing front end for a long time. And then as the complexity of the product continued to grow and more features came in, the challenge of the idea of having multiple code bases became even less viable even though we were getting more help. So having one code base to target all three of the platforms um using technologies that we were already familiar with, we certainly helped as well. TypeScript and React and um uh you know essentially CSS, a kind of a CSS variant.
Really helped us uh hit the timelines that we needed. And it's no joke, you can't ship just iOS or just web or just Android. Uh it's very, very limiting to do that, and people expect to have the platform be available in all three places. So I don't think we would have been able to accomplish the rollout that we needed to do and hit our business objectives if we weren't using Expo and React Native. Yeah. And so Eli, same question to you, although I'm curious also for Streamplace, which is obviously dealing with video, like how is that working with Expo and kind of shipping to multiple platforms?
Yeah, yeah. I mean, I mean the first part of the answer is the same, right? Like so uh building any kind of Twitch competitor, we very much needed an iOS, an Android app, and a website as quickly as humanly possible. And I just don't think there's uh maybe there's other other frameworks that would argue with it, but I think Expo is the most credible way to um to try and do all of those things. The the other piece for us, um a piece you know, part of Streamplace's strategy as a company is that live video infrastructure and software is very, very difficult.
One of the one of the harder things you can do in technology, uh and a lot of the other teams in the Atmosphere aren't very excited about taking that on. So from the beginning, we've really really wanted to um as much of our code as possible needs to live in libraries that are accessible to other applications that they can access. Um that eventually means, unfortunately, because Expo is not the only framework in the world, that does eventually mean we need to, and we have uh in various stages of development, we have sort of like React Native slash web library, that's the main one, and then we've got like a Flutter library in development, we've got a native Swift OS library in development.
We'll probably do something for Android at some point. But um in terms of getting the the biggest slice of the pie that we could as quickly as possible, um building that with um uh with Expo and React Native and building that library made a lot of sense. Uh unique challenges of dealing with video. Um I would say uh the we uh for us in particular. Um if you're watching the live stream now and it's working, which it seems to be mostly be doing so. Uh uh we uh I attribute that mostly to WebRTC playback. That's the technology we built on.
It's the same technology that's used to power Google Meet and any if you've had a if you've had a conversation in a web browser with somebody who was built on WebRTC. Um it's very good at, for example, if something goes wrong, recovers because it's trying to play back the video as quickly as possible. Um that's been a pain. Uh uh even with uh as much help as we can get from from the frameworks and stuff, um the we've had to to get something like picture-in-picture playback working. So when you navigate out of the app, you still have it up there in the corner.
We needed to use forked versions of different web RTC libraries, do our own native builds. Um building all of this in an open source way that theoretically other people could build, so that means um something we don't use from Expo is like the I'm blanking on the name, the like cloud build. Um, you know, because we need to be able to like build all of everything ourselves in a Docker container. So um uh yeah, yeah. I would say like once we got it all wired up, it worked pretty well, but um definitely like the build process was a big challenge.
Yeah. And then Reed, you're also dealing with video in a kind of different format. So I'm curious how you've dealt with that in similar and different ways. Yeah, I'm lucky that uh I think it wasn't that long before that you guys released a new Expo video package, and uh that helped me out a lot, obviously. Um it did allow me to start with like Expo Go. And um and like you're able to build these native modules in Expo. It's kind of the most important part of it that you can go to the native side instead of the JavaScript JavaScript side whenever you actually need it.
So you're kind of never limited on what you can do. Um but Expo Go is kind of like the preset group of modules, and uh it just allowed us to focus on the things that like the users were caring about because we kind of immediately had a lot of people who are like interested in using our app or using our app. Um we had about 150,000 users in the first three months, and um and so there wasn't a lot of time to work on anything except for things that the users were actively like in our comments about.
Um because of Expo is basically like we just got to work on like those specific behaviors. Somebody would report a bug and because we could do over-the-era updates, which are like JavaScript only updates, we could fix it like immediately and then comment back and then just move on to the next thing and just do that over and over and over again. Versus if it was a Swift app, we would have had to go through a whole app store deployment of several days before they ever got feedback and they would have just given up on us, basically in those three days.
Um that makes sense. And then so Paul, I'm curious, you mentioned earlier like you have to build for a bunch of different platforms and like now in the kind of mobile space, it's really easy to iterate on web, and kind of before Expo there was an easy way to iterate on mobile. But I'm curious why even target mobile in the first place. Like why is mobile kind of important to Bluesky as a platform? Well the web mobile experience uh in a web browser is you know pretty good, but there's a lot of interaction patterns that you just can't accomplish.
Um One hopes that PWAs will someday. Yeah, yeah. It seems to get jammed up, and it seems to be some kind of politics between Apple, I think, and Google. Like Google really wants it because they're sold on web tech, right? So I think it's Apple that's kind of jamming it up. But the um uh gestural interfaces are very much the expectation with mobile. And um I'm doing a mobile web application right now, and I'm uh had to uh stop and go, I can only tap. How do I design this? This is this is very interesting. Found some stuff, you know, but it's a little weird.
I also can't do vibrations, so there's no haptic feedback, which is the worst when you press on a button and it doesn't give you a little, oh gosh. So like you get a little bit crippled whenever because the web is they've Apple has been pretty opinionated about like the web should be for web documents essentially. It's just not their applications runtime. And so you gotta go native for that reason. That's that's reason number one, is the usability of the application. Reason number two is that people look inside of the app store to find the apps. That's just how it works.
If you're not there, then you don't exist. And I think that's pretty much it. You're you want to have a good experience. People aren't gonna accept less. There are still some people, I mean, the only people that are really hardcore on the web are the big real big nerds. So you you kind of have to meet people where they're at. And that's native. Yeah. And so then the same question for you, Eli. Like, why is native kind of mobile apps, why is that important for Streamplace? Yeah, uh, I would say it's just sort of table stakes to be taken seriously in terms of uh releasing something.
Um I mean the other piece, of course, is uh we want to be able to stream from phones. Um I think that you wouldn't be taken seriously as a streaming platform if you didn't have that capability. Um and so that was yeah very, very necessary to go to mobile. It it hasn't always been um uh the the difficulty of building this in sort of a library fashion for other mobile apps has been has been a particular challenge. Um I don't know if there's a good the there's uh the uh a funny story on like the interaction between Skylight was one of the first apps to to integrate Streamplace live streaming.
Uh and we accidentally did a thing where uh when you log into Streamplace, uh one of the first things we do is create a a place.stream dot actor, uh place not stream.chat dot profile record, because it just shows what chat color that you have. Uh and of course that makes perfect sense when you logged into Streamplace. Uh then we integrated into Skylight, and I didn't realize I had kind of put that in the library code instead of the app code. So as soon as you booted Skylight, you got a place.stream dot chat dot profile record, even if you hadn't interacted with like the Streamplace features within Skylight, uh, which made us seem uh uh sort of aping off Skylight's popularity a little bit because all of a sudden we were like the second most popular, we were like the most popular non-blue sky lexicon in the Atmosphere because of that integration, which uh I guess felt good, but wasn't really legitimate.
Um so yeah, in that context, like figuring out, but but I think you know, as much as like the Atmosphere stuff has been built to be interoperable, uh some of the norms around that kind of like what what does make sense there, right? Like probably if you're gonna go tap into chat and participate in it, then it would be appropriate for us to create that record, and we just like don't really have community norms around that kind of thing yet. So I don't know. I think I went away from your question a little bit. But that was that was a unique challenge.
Interesting. And that that was a really funny story that I'm guessing you're asking me the same question. Yeah, basically. I want to add the Eli story because what it initially started does was he thought he was being attacked like by the like a DD US attack. It was like, no, I just added the your uh library to our code base. Um but it was really important for us, probably even more so than these guys because the gesture of like swiping through TikTok is like so specific. Um it would have been possible doing the web. I tried like on day three uh to like try to do it, and it was like the way that Safari works is like you have to go click something to start playing a video.
They won't even let you kind of do this thing that TikTok does. Um so we don't even really have like that much of a web app, it's just all mobile for us. I seem and then just to follow up on that, like what was scaling like for you with X? Because you mentioned I think Bluesky also had this a bit just like going from kind of your user growth was so crazy and was Expo part of like enabling you to scale in that way. Uh yeah, I think so because it was we just were able to be so client focused because they had kind of like built all this infrastructure in a way that we could use it.
Uh we could really just focus on like the client and trying to reach parity on that side and client-based solutions. But then also when we did need like server code, there was like EAS hosting, and it was like we could just throw it in the same code base. It wasn't a whole separate thing for us. Yeah. And so then I'm also curious, just as a kind of state of the ecosystem, like if there's anything that you guys want to just think is really cool that you've seen in either that proto world or the expo world that you want to shout out or just are kind of excited to build with.
Oh well I mean my talk in what 15 minutes is like nonstop shout out. I can't give away my cable I don't want to spoil your talk. So I'll actually I I am going to pass because I have to so this is becoming part of the atproto world but uh media overquick is the sort of next generation way that we are going to uh replace both um sort of traditional uh HLS based video playback on the internet uh especially for live streams um as well as web RTC and and uh yeah it's just like all of the different arrows that we need used to use all of these different protocols for are moving toward media over quick um as well as to Cisco engineers recently put out a paper explaining how you would do atproto relay data over media over quick which totally blew up Streamplace's technical roadmap because I'm like oh I like I thought we would do mocks someday and it was like oh that'll be like a fun optimization but now it's like oh this is the only protocol we would ever need for everything on the the atproto data media data we can just like speak one language across absolutely everything.
So yeah every time I talk to anyone from expo I'm like please expo media over quick I like that the existence of that library is going to make my life so much easier. And also it'd be good for like people's battery life and everything but like mostly mostly meeting we'll work on it yeah. Yeah. I'll say on the expo side the liquid glass stuff that you guys have to just be able to get that and not and it doesn't it's not like super hard to configure you even get the accessory view stuff that's really nice to be able to kind of provide the high fidelity experience for iOS apps and stuff like that.
So then I'm curious also just to kind of for the whole panel like app proto conference is there a kind of weird or interesting way that you're using the protocol that maybe isn't exactly as it was designed but like works really well for your specific use case. I have a feeling Eli might have some specific that was the question that I should have told my story in response to I have another one though which is um so I found myself this is this is a little bit of a preview of my VOD talk uh in an hour or two but um I found myself in a situation where um so you know you've got one Streamplace architecture you've got one server that's ingesting the live stream and signing all of the segments that come in and then I needed to start uh archiving them and making it um available across lots of different servers uh especially so you can um provide what live stream engineers called D VR right so you can seek back from the live stream and go see what happened a couple minutes ago um in order to make that happen I needed to sync that data from the origin server to a bunch of other servers uh and I realized what I had was like all of these little blobs and I needed uh to have a sync protocol that could go from one server to another uh and make sure that they both got an up-to-date state uh and I started coding something I'm like wait a minute this is an atproto repository that's exactly what I'm doing.
So uh so that's that that'll be in the VOD talk. That's that's kind of how we're doing that. I have turned it off for relays because uh you get a new segment every second we would get throttled by the entire Atmosphere if we released that out. So currently that's like a new peer-to-peer atproto thing that I'm gonna be talking about in a little bit but uh yeah yeah uh but but it all because it's the same primitives it all does still work. So if you're a third party app that wants to integrate with Streamplace, you can subscribe to the fire hose on the Streamplace stream um and you use all the existing atproto libraries that you're already using for everything else.
So yeah, yeah interesting fit. I'm not sure how many things like that there are in the Atmosphere right now, but we're gonna see what happens if we do atproto but really really fast. Cool. I mean I don't know if you have any so I think um this is kind of I think related to Rudy's talk earlier that uh I believe these apps will kind of move somewhere between like a bespoke social app but also with like a bunch of extended secondary features to be kind of like a browser too. That's what we kind of saw from Skylight's users that it was like there really wasn't any reason not to show all the other stuff that's going on.
And it was actually really powerful for getting for like kind of delivering a core user experience where it's like hey look like this might be a video first app, but there's actually like these posts and they might be related to the stuff that you liked watching as a video. And so I think and this kind of then relates to Expo that if we're all kind of doing the same things we can have these libraries and we all end up with like these slightly different versions of browsers and stuff that's probably what the future looks like. Cool.
I don't know if you have anything weird ways. Using the protocol in unexpected ways. Yeah, we had another advantage on that. We actually, I mean, I guess I can use the answer's not really. But two things do come to mind. One of them is that I didn't think bridging to Activity Pub would work. I told Ryan, like don't even try it. And he proved me wrong like big time. That works shockingly well. So I suppose that in a way is a bit of an abuse of it, especially the you know, like the automatic kind of mirroring of the accounts and the infrastructure.
I kinda still can't believe that worked. Yeah. Woo. What was the other thing I was going to say? I think I lost it. So that's it. Yeah. And then kind of on that same note, I'm curious for all of you guys if there's anything that you could like snap your fingers now and just ignore all of the technical complic complexity and implementation if there's something you'd like to be in the ad protocol. Oh, that's interesting. I don't want to spoil the talk. That one won't spoil my talk. No, it's the permission data system. Yeah, I think everybody's kind of on the same page with that.
I mean the good news is that like um now it's a dedicated work stream, right? Um the Daniel proposed uh published his kind of informal version of the proposal that we're making and there's a number of different proposals also from the community that have been getting shared, so we're gonna be able to come out of the conference and start to side by side all of them and drive towards um actually having permission data. And so I've been saying like okay, by the middle of the year, let's try to have this thing actually in production and getting to go.
And um, I guess we'll get to look back on the video you know next year and see if I was right or not. But that's roughly I uh if I could snap my fingers now, I would have it. Because I think that's the last kind of really big fundamental piece to the technology before we can just start to build any kind of application we want. So I'm very excited for that. Cool. Um I've doing good at uh answering your questions one too early because I would say it's the expo media over quick thing. Um something else I'll throw out.
Uh there's um obviously always I I don't have the solution yet, but there's obviously always tons of room in taming OAuth complexity. That's one of the most you know uh difficult things for people to implement. Um in particular for us, uh there have been three Streamplace front ends uh created by uh third-party developers since the beginning of this conference two days ago, which I don't know if that's not like a good review of our front end that people are like I gotta make my own. Uh but it's but it's awesome that it's possible. Um but it it it's a really weird interaction because when you log into Streamplace itself, we do server-side OAuth uh and have uh uh you know access to your key, which is important for live streaming because we update stuff uh in your repository without you being there taking actions, right?
Like when you have a live stream going, it updates the the timestamps on it and and all of that is automated. Uh I have no idea yet what the relationship between that and like these third-party applications look like. Are they gonna owe off to Streamplace and then to something else and then through this other front end and like add another layer in there? Is there some way to do these automated interactions when you log in with the other app and you're you're streaming in? I I don't know. So like that's yeah, lots of complexity there that like we just need to figure out stories around all that stuff.
Yeah. Um I'd say for my side, the thing that I'd like to add to the protocol other than the permission data would be if we could basically bring like our AI with our data to these applications to have a kind of like an agent that you own. Um so it's not meta's intelligence or personalization system recommending you videos, it's your own, like paid for Claude or whatever um subscription. And I think in particular for us, we kind of figured out that one of the limitations we were gonna hit is how much personalization we could actually do um for Skylight.
And if we it would have made a pretty significant difference if we could have relied on the users themselves to kind of cause that personalization to happen to their app. Yeah, cool. And then uh one final question, I guess. I think there are a lot of people maybe watching who have seen the app proto, but haven't really like experimented with it. And I think X there is a bunch of technologies like Expo that make it easier, but do you guys have any pieces of advice for kind of developers who've looked at it but haven't yet played around with it or maybe just something that the app proto makes super easy that's exciting.
Okay, yeah. Well, I've got a little bit of a can line that I'll they'll hit you with on that. So like uh I would say that Expo and App Proto, the similarity between them is that they're both web heads invading other things, right? So like Expo is taking web technology and invading native application development and making it so you have one shared thing. And I think that the app protocol is the same story. It's the mentality and ethos of web application developers, people that believe in the open web, applying that to the server side of things.
The other commonality is that they both do a lot for you. They kind of help you get to where you want to go faster. And I think that as um Expo has matured a little bit longer than than App Proto has. As App Proto gets even more mature, it's going to feel even more kind of like backend as a service as a protocol in a way where you're getting accounts for free, you're getting access to the the network um by default. And increasingly hopefully helping with cold start uh you know um being able to tap into existing activity networks and things like that.
So yeah I guess the tip would be uh check the docs and ask the agents because they are getting hooked in. Cool. Eli same question. Yeah something I think is uh the that proto is super good for that I think is underutilized right now is uh real-time applications uh where you get immediately you get immediate um you know the the UI re-renders as soon as data comes in uh Streamplace chat when I first wired it up I thought I was like let's do it this will be funny this will be like a little hacky way we'll do it what I'm gonna do is just make a chat message and then push it to the user's PDS and then it goes all the way from the app PDS to the relay to the Streamplace app view and then there's another web socket that goes all the way back to the browser and we're gonna see like oh it'll be funny it'll be like so slow but it'll be like kind of like chat that's working and it's just great.
It just it just kicks ass. Like it's it's so fast. It is like the the finality in that like you we you know we we do the standard reactive rendering thing where you type in we we like render it in the UI as soon as you type it in but even if I didn't do that, the round trip from no uh a browser Streamplace PDS relay Streamplace browser is so it's like a second. It's like so fast and it feels like a totally responsive application. Yeah I I and I don't think um maybe the missing piece there is like there's not uh there's not necessarily like a a way for a standardized way for an app view and a browser to communicate.
So maybe that's like a barrier to people to get started with it. But like literally just like make the records JSON and send them down the WebSocket and it works super super well. Cool uh yeah and I'd say that as a React developer is like my background I got it I like learned about app proto from Dan Abramoff giving a talk and kind of recognizing the same principles that I loved about React were like kind of represented like the composition pattern of how you can have data from the these different lexicons and they all come together and um yeah I think it's just kind of like the same good concepts applied to the back end.
Fantastic. Okay well I think we're out of time but uh thank you guys all so much for being here and uh thank you all for coming.