Podcasts about smoke signals

Sherman Alexie joins Tad to discuss The Absolutely True Diary of a Part-Time Indian, The Lone Ranger and Tonto Fistfight in Heaven, Smoke Signals, You Don't Have to Say You Love Me, comics and more!Consider becoming a patron!Support the show

On this episode of ABL Live, we covered a variety of topics, including the drama surrounding the White House "Signal" group chat that was leaked to the media, the Department of Education reckless spending, the hate hoax involving a noose in Pennsylvania, the Department of Justice potentially restoring certain felons' right to vote, and much more!

Breaking News: Media's Smoke Signal, Plus Crucial Wisconsin Special Election.Live with Sens Ron Johnson & Rick Scott | Triggered Ep228 Live from Rumble Studio Go to http://www.HenryUSA.com for a free catalog and decals and to learn more about this great American company! --- Just visit http://allfamilypharmacy.com/DONJR and use code DONJR10 for 10% off your order. Learn more about your ad choices. Visit megaphone.fm/adchoices

PODCAST RECOMENDATIONS:***********************Making Our WayMakeShiftMaking ItClamp PodcastForge Side ChatKnife TalkFull Blast with Geoff FederWorkshop Therapy with Andrew HatchWeld.com Podcast with BeauHustle & Grind with Noah & RyanTriple T with Jerid & DenisKnife PerspectiveWorking Hands PodcastWhats cooking in the shopSPONSORS:**************Maritime Knife Supply: https://www.MaritimeKnifeSupply.comBaker Forge & Tool: https://www.bakerforge.com/Pelican Paste: https://pelicanpaste.com/KHDailyKnives: https://khdailyknives.com/shop/Rock Solid Scales: https://rocksolidscales.com/The Drop Point Newsletter: https://thedroppoint.com/Bald Man Knife and Tool: https://www.BaldManKnifeandTool.com**************SUPPORT:**************https://www.patreon.com/workforitSOCIALS**************HouseMade YouTube: https://www.youtube.com/c/housework123HouseMade Instagram: https://www.instagram.com/house__work/Bryan Kohn Instagram: https://www.instagram.com/b.kohnknives/Bryan Kohn YouTube: https://www.youtube.com/channel/UCOdEhPeKNd8iI1eGM0QFjnAPICKLE: https://www.instagram.com/pickle_kutterz/Advertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacy

Mitchell & The Dubs Cartel - Smoke Signals & Cheap Thrills Woke up in a lawn chair, sand in my jeans, Last thing I remember, I was chasin' a dream. Bottle in my left hand, spliff in my right, Pretty little thing said she'd stay for the night— But she gone... like my last twenty bucks, Now I'm skippin' town, guess I ran outta luck. Ohhh, I hear the sirens singin' my name, Ohhh, but I never play that game… Smoke signals, cheap thrills, runnin' from the law, One step ahead, but I'm bound to fall. No money, no plan, just a song in my head, Live fast, love loud, wake up half-dead. Met a rasta man said, “Boy, you look lost,” Told me ‘bout Jah, then he stole my sauce. Bought a ticket south, but the train broke down, So I'm thumbin' rides with a dog and a clown. Got a tattoo from a dude in a van, Spelled it wrong but—man, I'm a fan! Ohhh, I hear the waves call my name… Ohhh, but they never sound the same… Smoke signals, cheap thrills, runnin' from the law, One step ahead, but I'm bound to fall. No money, no plan, just a song in my head, Live fast, love loud, wake up half-dead. They say “slow down”—I say “why?” The reaper got a ticket but he waitin' in line… Roll me up, let me float like a kite, I'll be back when the stars burn bright… Yeahhh… cheap thrills… Oooohhh… no regrets, no refills…

On this episode, I'm joined by Jeff, guitarist of Smoke Signals, to chat about his favorite coffee, play some Newfie trivia, discuss the all-ages scene, and hear about Beyond The Mind EP.During the episode, I was drinking Super Naturel from Escape.Episode Links:https://escape.cafe/https://www.instagram.com/smokesignalshc/https://www.instagram.com/beansandbreakdowns/Start making podcasts-https://www.riverside.fm/?utm_campaign=campaign_5&utm_medium=affiliate&utm_source=rewardful&via=grayson-carpenter

Kacper "prefetcher" Staroń created the PinkSea oekaki BBS on top of the AT Protocol. He also made the online multiplayer game MicroWorks with Noam "noam 2000" Rubin. He's currently studying Computer Science at the Lublin University of Technology. We discuss the appeal of oekaki BBSs, why and how PinkSea was created, web design of the early 2000s, flash animations, and building an application on top of the AT Protocol. Prefetcher Bluesky Github Personal site Microworks (Free multiplayer game) PinkSea and Harbor PinkSea PinkSea Bluesky Account PinkSea repository Harbor image proxy repository Harbor post from bnewbold.net imgproxy (Image proxy used by Bluesky) Early web design Web Design Museum Pixel Art in Web Design Kaliber10000 Eboy Assembler 2advanced epuls.pl (Polish social networking site) Wipeout 3 aesthetic Restorativland (Geocities archive) Flash sites and animations My Flash Archive (Run by prefetcher) dagobah Z0r Juicy Panic - Otarie IOSYS - Marisa Stole the Precious Thing Geocities style web hosts Neocities Nekoweb AT Protocol / Bluesky PDS Relay AppViews PLC directory Decentralized Identifier lexicon Jetstream XRPC ATProto scraping (List of custom PDS and did:web) Tools to view PDS data PDSls atp.tools ATProto browser Posters mentioned vertigris (Artist that promoted PinkSea) Mary (AT Protocol enthusiast) Brian Newbold (Bluesky employee) Oekaki drawing applets Tegaki chickenpaint Group drawing canvas Drawpile Aggie Other links Bringing Geocities back with Kyle Drake (Interview with creator of Neocities) firesky.tv (View all bluesky posts) ATFile (Use PDS as a file store) PinkSky (Instagram clone) front page (Hacker news clone) Smoke Signal (Meetup clone) -- Transcript You can help correct transcripts on GitHub. Intro [00:00:00] Jeremy: Today I am talking to Kacper Staroń.  He created an oekaki BBS called PinkSea built on top of the AT protocol, and he's currently studying computer science at the Lublin University of Technology. We are gonna discuss the appeal of oekaki BBS, the web design of the early 2000s, flash animations, and building an application on top of the AT protocol. Kacper, thanks for talking with me today. [00:00:16] Prefetcher: Hello. Thank you for having me on. I'm Kacper Staroń also probably you know me as Prefetcher online. And as Jeremy's mentioned, PinkSea is an oekaki drawing bulletin board. You log in with your Bluesky account and you can draw and post images. It's styled like a mid to late 2000s website to keep it in the spirit. What's an oekaki BBS? [00:00:43] Jeremy: For someone who isn't familiar with oekaki BBSs what is different about them as opposed to say, a photo sharing website? [00:00:53] Prefetcher: The difference is that a photo sharing website you have the image already premade be it a photo or a drawing made in a separate application. And you basically log in and you upload that image. For example on Instagram or pixiv for artists even Flickr. But in the case of an oekaki BBS the thing that sets it apart is that oekaki BBSes already have the drawing tools built in. You cannot upload an already pre-made image with there being some caveats. Some different oekaki boards allow you to upload your already pre-made work. But Pinksea restricts you to a tool called Tegaki. Tegaki being a drawing applet that was built for one of the other BBSes and all of the drawing tools are inside of it. So you draw from within PinkSea and you upload it to the atmosphere. Every image that's on PinkSea is basically drawn right on it by the artists. No one can technically upload any images from elsewhere. How PinkSea got started and grew [00:01:56] Jeremy: You released this to the world. How did people find it and how many people are using it? [00:02:02] Prefetcher: I'll actually begin with how I've made it 'cause it kind of ties into how PinkSea got semi-popular. One day I was just browsing through Bluesky somewhere in the late 2024s. I was really interested in the AT Protocol and while browsing, one of the artists that I follow vertigris posted a post basically saying they'd really want to see something a drawing canvas like Drawpile or Aggie on AT Protocol or something like an oekaki board. And considering that I was really looking forward to make something on the AT Protocol. I'm like, that sounds fun. I used to be a member of some oekaki boards. I don't draw well but it's an activity that I was thinking this sounds like a fun thing to do. I'm absolutely down for it. From like, the initial idea to what I'd say was the first time I was proud to let someone else use it. I think it was like two weeks. I was posting progress on Bluesky and people seemed eager to use it. That kept me motivated. And yeah. Right as I approached the finish I posted about it as a response to vertigris' posts and people seemed to like it. I sent the early version to a bunch of artists. I basically just made a post calling for them. Got really positive feedback, things to fix, and I released it. And thanks to vertigris the post went semi-viral. The launch I got a lot of people which I would also tie to the fact that it was right after one of the user waves that came to Bluesky from other platforms. The website also seemed really popular in Japan. I remember going to sleep, waking up the next day, and I saw like a Japanese post about PinkSea and it had 2000 reposts and 3000 likes and I was just unable to believe it. Within I think the first week we got like 1000 posts overall which to me is just insane. For a week straight I just kept looking at my phone and clicking, refresh, refresh, refresh, just seeing the new posts flow in. There was a bunch of like really insane talented artists just posting their works. And I just could not believe it. PinkSea got I'd say fairly popular as an alternative AppView. People seem to really want oekaki boards back and I saw people going, oh look, it's like one of those 2000s oekaki boards! Oh, that's so cool! I haven't seen them in forever! The art stands out because it's human made [00:04:58] Prefetcher: And it made me so happy every single time seeing it. It's been since November, like four months, give or take. And today alone we got five posts. That doesn't sound seem like a lot but given that every single post is hand drawn it's still insane. People go on there and spend their time to produce their own original artworks. [00:05:26] Jeremy: This is especially relevant now when you have so much image generation stuff and they're making images that look polished but you're kind of like well... did you draw it? [00:05:39] Prefetcher: Yeah. [00:05:40] Jeremy: And when you see people draw with these oekaki boards using the tools that are there I think there's something very human and very nostalgic about oh... This came from you. [00:05:53] Prefetcher: Honestly, yeah. To me seeing even beginner artists 'cause PinkSea has a lot of really, really talented and popular people (and) also beginner artists that do it as a hobby. Ones that haven't been drawing for a long time. And no matter what you look at you just get like that homely feeling that, oh, that's someone that just spent time. That's someone that just wanted to draw for fun. And at least to me, with generative AI like images it really lacks that human aspect to it. You generate an image, you go, oh, that's cool. And it just fades away. But in this case you see people that spent their time drawing it spent their own personal time. And no matter if it's a masterpiece or not it's still incredibly nice to see people just do it for fun. [00:06:54] Jeremy: Yeah. I think whether it's drawing or writing or anything now more than ever people wanna see something that you made yourself right? They wanna know that a human did this. [00:07:09] Prefetcher: Yeah. absolutely. [00:07:11] Jeremy: So it sounds like, in terms of getting the initial users and the ones that are there now, it really all came out of a single Bluesky posts that an existing artist (vertigris) noticed and boosted. And like you said, you were lucky enough to go viral and that carried you all the way to now and then it just keeps going from there, [00:07:36] Prefetcher: Basically if not for vertigris PinkSea (would) just not exist because I honestly did not think about it. My initial idea on making something on ATProto and maybe in the future I'll do something like that would be a platform like StumbleUpon -- Something that would just allow you to go on a website, press a button, and it gets uploaded to your repo and your friends would be able to see oh -- you visited that website and there would be an AppView that would just recommend you sites based on those categories. I really liked that idea and I was dead set on making it but then like I noticed that post (from vertigris) and I'm like, no, that's better. I really wanna make that. And yeah. So right here I want to give a massive shout out to vertigris 'cause they've been incredibly nice to me. They've even contributed the German translation of PinkSea which was just insane to me. And yeah, massive shout out to every single other artist that, Reposted it, liked it, used it because, it's all just snowballed from there and even recently I've had another wave of new users from the PinkSea account. So there are periods where it goes up and it like goes chill -- and then popular again. Old internet and flash [00:08:59] Jeremy: Yeah. And so something that you mentioned is that some people who came across it they mentioned how it was nostalgic or it looked like the old oekaki BBSs from the early internet. And I noticed that that was something that you posted on your own website that you have an interest in that specifically. I wonder what about that part of the internet interests you? [00:09:26] Prefetcher: That is a really good question. Like, to me, even before PinkSea my interests lie in the early internet. I run on Twitter and also on Bluesky now an account called My Flash Archive, which was an archive of very random, like flash animations. And I still do that just not as much anymore 'cause I have a lot of other things to do. I used to on Google just type in Flash and look through the oldest archived random folders just having flash videos. And I would just go over them save all of that or go on like the dagobah or Z0r or swfchan. 'cause the early internet to me, it was really like more explorative. 'cause like now you have, people just concentrated in those big platforms like Twitter, Instagram, Facebook, whatever. And back then at least to me you had more websites that you would just go on, you would find cool stuff. And the designs were like sometimes very minimal, aesthetically pleasing. I'd named here one of my favorite sites, Kaliber10000 which had just fantastic web design. Like, I, I also spend a lot of time on like the web design museum just like looking at old web design and just in awe. My flash archive on Twitter at least got very popular. I kind of abandoned that account, but I think it was sitting at 12,000 followers if not more? And showed that people also yearn for that early internet vibe. And to me it feels really warm. Really different from the internet nowadays. Even with the death of flash you don't really have interactive experiences like it anymore. 'cause flash was supposed to be replaced by HTML5 and JavaScript and whatever but you don't really make interactive experiences that just come packaged in a single file like flash. You need a website and everything. In flash, it just had a single file. It could be shared on multiple sites and just experienced. That kind of propelled my interest. Plus I, I dunno, I just really like the old internet design aesthetics it really warms me (and really close..?) Flash loops [00:12:01] Jeremy: The flash one specifically. Were they animations or games or was there a specific type of a flash project that spoke to you? [00:12:15] Prefetcher: Something we call loops. Basically, it's sometimes animations. 'cause, surprisingly while I like flash games they weren't my main collection. What spoke to me more were loops. Basically someone would take a song, find a gif they liked, and they would just pair it together. Something like YTMND did. At least from loops I found some of my favorite musical artists, some of my favorite songs, a lot of interesting series, be it anime or TV or whatever. And you basically saw people make stuff about their favorite series and they would just share it online. I would go over those. For example, a good website as an example is z0r.de, which is surprisingly still active and updated to this day. And you would see people making loops about members of that community or whatever they like. And you would for example see like 10 posts about the same thing. So you would know someone decided to make 10 loops and just upload them at once. And yeah, to me, loops basically were like, I mean, they weren't always the highest quality or the most unique thing, but you would see someone liked something enough that they decided to make something about it. And I always found that really cool. I would late at night just browse for loops and I'm like, oh, oh, this series, I remember it. I liked it (laughs)! But of course flash games as well. I mean, I used to play a lot when I was younger, but specifically loops, even animations and especially like when someone took like their time to animate something like really in depth. My favorite example is, the music video to a song by the band Juicy Panic called Otari. Someone liked that song enough that they made an entire flash animated music video, which was basically vectorized art of various series like Azumanga Daioh or Neon Genesis Evangelion as well, and other things. And it was so cool, at least to me, like a lot of these loops just basically have an intense, like immense feeling on me (laughs). I just really liked collecting them. [00:14:38] Jeremy: And in that last example, it sounded more like it was a complete music video, not just a brief loop? [00:14:45] Prefetcher: No, it was like a five minute long music video that someone else made. [00:14:48] Jeremy: Five. Oh my gosh. [00:14:49] Prefetcher: Yeah. You would really see people's creativity shine through on just making those weird things that not a lot of people have seen, but you look at it and it's like, wow. It's different than YouTube (Sharable single file, vectorized) [00:15:01] Jeremy: It's interesting because you can technically do and see a lot of these things on, say, YouTube today, but I think it does feel a little different for some reason. [00:15:16] Prefetcher: It really is. Of course I'm not denying on YouTube you see a lot of creative things and whatever. But first and foremost, the fact that Flash is scalable. You don't lose the quality. So be able to open, I don't know, any of the IOSYS flash music videos for like their Touhou songs and the thing would just scale and you would see like in 4K and it's like, wow. And yeah, the fact that on YouTube you have like a central place where you just like put something and it just stays there. Of course not counting reuploads, but with Flash you just had like this one animation file that you would just be able to share everywhere and I don't know, like the aspect of sharing, just like having those massive collections, you would see this flash right here on this website and on that website and also on this website. And also seeing people's personal collections of flash videos and jrandomly online and you would also see this file and this file that you haven't seen it -- it really gives it, it's like explorative to me and that's what I like. You put in the effort to like go over all those websites and you just like find new and new cool stuff. [00:16:32] Jeremy: Yeah, that's a good point too that I hadn't thought about. You can open these files and you have basically the primitives of how it was made and since, like you said, it's vector based, there's no, oh, can you please upload it in 1080 p or 4K? You can make it as big as you want. [00:16:53] Prefetcher: Yeah. Web design differences, pixel art, non-responsive [00:16:55] Jeremy: I think web design as well it was very distinct. Maybe because the tools just weren't there, so a lot of people were building things more from scratch rather than pulling a template or using a framework. A lot of people were just making the design theirs I think rather than putting words on a page and filling into some template. [00:17:21] Prefetcher: Honestly, you raise a good point here that I did not think much about. 'cause like nowadays we have all of this tooling to make web design easier and you have design languages and whatnot. And you see people make really, in my opinion, still pretty websites, very usable websites on top of that. But all of them have like the same vibes to them. All of them have like a unified design language and all of them look very similar. And you kind of lose that creativity that some people had. Of course, you still find pretty websites that were made from scratch. But you don't really get the same vibes that you did get like back then. Like my favorite, for example, trend that used to be back on like the old internet is pixel art in web design. For example, Kaliber10000, or going off the top of my head, you had the Eboy or all the sites and then Poland, for example, ... (polish website) those websites use minimal graphics, like pixel graphics and everything to build really interesting looking websites. They had their own very massive charm to them that, I don't know, I don't see a lot in more modern internet. And it's also because back then you were limited by screen size, so you didn't have to worry about someone being on a Mac with high DPI or on a 32x9 monitor like I am right now. And just having to scale it up. So you would see people go more for images, like UI elements, images instead of just like building everything from scratch and CSS and whatnot. So, yeah, internet design had to accommodate the change. So we couldn't stay how it was forever 'cause technology changed. Design language has changed, but to me it's really lost its charm. Every single website was different, specific, the web design had like this weird form, at least on websites where it was like. I like to call it futuristic minimalism. They looked very modern and also very minimal and sort of dated. And I dunno, I just really like it. I absolutely recommend checking, on the web design museum fantastic website. I love them and the pixel art in web design sub page. Like those websites to me they just look fantastic. [00:19:52] Jeremy: Yeah, and that's a good point you brought up about the screen sizes where now you have to make sure your website looks good on a phone, on a tablet, on any number of monitor sizes. Back then in the late 90s, early 2000s, I think most people were looking at these websites on their 4x3 small CRT monitors. [00:20:20] Prefetcher: My favorite this website is best viewed with an 800 by 600 monitor. It's like ... what? [00:20:28] Jeremy: Exactly. Even if you open your personal site now the design is very reminiscent of those times and it looks really cool but at the same time on a lot of monitors it's a small box in the middle of the monitor, so it's like -- [00:20:49] Prefetcher: I saw that issue, 'cause I was making it on a 1080p monitor and now I have a 32x9 monitor and it does not scale. I've been working on reworking that website, but, also on the topic of my website, I, I wanna shout out a website from the 2000s that still exists today. 'cause, my website was really inspired by a website called Assembler. And Assembler, from what I could gather, was like a net art or like internet design collective. And the website still works to this day. You still had like, all of their projects, including the website that my website was based off of. [00:21:28] Jeremy: Yeah, I mean there, there definitely was an aesthetic to that time. And it's probably, like you said, it's probably people seeing someone else's site in this case, what, what did you call it? Assem? Assembler? [00:21:42] Prefetcher: Assembler. [00:21:42] Jeremy: Yeah. You see someone else's website and then maybe you try to copy some of the design language or you look at the HTML and the CSS and I mean, really at the time, these websites weren't being made with a ton of JavaScript. There weren't the minifiers, so you really could view source and just pull whatever you wanted from there. [00:22:06] Prefetcher: We also had those design studios, design agencies, notably 2advanced which check in now, their website still works, and their website is still in the same aesthetic as it was those 20 so years ago just dictating this futuristic design style that people really like. 'cause a lot of people nowadays also really like this old futurism minimalism for example a lot of people still love the Wipeout 3 aesthetic that was designed by one of my favorite studios overall the designers republic. And yeah, it's just hard for me to explain, but it feels so soulful in a way. [00:22:53] Jeremy: I think there are some trade offs. There's what we were talking about earlier with the flexibility of screen size. But there used to be with a lot of websites that used Flash, there used to be these very elaborate intros where the site is loading and there's these really neat animations. But at the same time, it's sort of like, well, to actually get to the content, it's a bit much, but, everything is a trade off. [00:23:25] Prefetcher: People had flash at their disposal and they just wanted to make, I have the tooling, I'm going to use all of the tooling and all of it. [00:23:33] Jeremy: Yeah. Yeah. but yeah, I definitely get what you're saying where when I went to make my own website I made it very utilitarian and in some ways boring, right? I think we do kind of miss some of what we used to have. [00:23:54] Prefetcher: I mean, in my opinion, utilitarian websites are just as fine. Like in some cases you don't really need a lot of flashy things and a lot of very modern very CPU intensive or whatever animations. Sometimes it is better to go on a website and just like, see, oh, there's the play button and that's it. [00:24:17] Jeremy: Yeah. Well definitely the animations and the intro and all that stuff. I guess more in terms of the aesthetics or the designs. It's tricky because there's definitely people making very cool things now things that weren't even possible back then. But it does feel like maybe the default is I'll pick this existing style sheet or this existing framework and just go with that. [00:24:47] Prefetcher: A lot of modern websites just go for similar aesthetics, similar designs, which they aren't bad, but they are also very just bland. They, they are futuristic, they are very well designed. But when you see the same website. The same -- five websites have the same feel. And this is especially, at least in my opinion, visible with websites built on top of NextJS or other frameworks. And it just feels corporate kind of dead. Like someone just makes a website that they want to sell something to you and not for fun. [00:25:26] Jeremy: With landing pages especially it's like, wow, this looks the same as every other site, but I guess it must work. [00:25:38] Prefetcher: It works. And it really cuts down on development time. You don't need to think much about it. You just already have a lot of well-established design rules that you just follow and you get a cohesive and responsive design system. Designing the PinkSea look and feel [00:25:56] Jeremy: Let's talk about that in connection with PinkSea. What was your thinking when you designed how PinkSea would look and feel? [00:26:06] Prefetcher: Honestly, at first I have to admit I looked at other websites. I looked at Bluesky first and foremost. I looked at, front page. I looked at Smoke Signal, and I thought that I might also build something that's modern and sleek and I sketched it out in an application and I showed it to some friends. One of them suggested I go for more like a 2000 aesthetic. I'm like, yeah, okay. I like that. As the website was built, I just saw more and more of how much I feel this could sit with others. Especially with the fact that it's an oekaki page an oekaki BBS and as you scroll through oekaki has a very distinct style to it. And as you scroll and you see all of those, pixel shaded, all those dithered images, non anti-aliased pens and whatnot. It feels really really cohesive somehow with the design aesthetic. But of course, PinkSea in itself is a modern website. Like if you were to go to my PinkSea repository. It's a modern website built up on top of Vue3, which talks via like XRPC API calls in real time and it's a single page app and whatever. That's kind of the thing I merged the modern way of making sites with a very oldish design language. And I feel, in my opinion, it somehow just really works. And especially it sets PinkSea apart from the other websites. It gives it that really weird aesthetic. You would go on it and you would not be like, oh, this is a modern site that connects with a modern protocol on top of a big decentralized network. This is just someone's weird BBS stuck in the 2000s that they forgot to shut down. (laughs) [00:28:00] Jeremy: Yeah. And I think that's a good reminder too, that when people are intentional about design, the tools we have now are so much better than what we used to have. There's nothing stopping us from making websites that when people go to them they really feel like something's different. I know I did not just land on Instagram. [00:28:27] Prefetcher: Yeah. And making PinkSea taught me that it's really easy to fall into that full string of thought that every site has to look modern. Because I was like, oh yeah, this is a modern protocol, a modern everything, and it has to look the part. It has to look interesting to people and everything. And after talking with a bunch of friends and other people and just going, huh, that's maybe like the 2000s isn't as bad as I thought. And yeah, the website especially it's design people seem to just really like it. Me too. I, I just absolutely love how PinkSea turned out it is really a reminder that you don't need modernness in web design always. And people really appreciate quirky looking pages, so to say, quirky like interesting. [00:29:23] Jeremy: I interviewed the, the creator of Neocities which is like kind of a modern version of GeoCities and yeah, that's really what one of the aspects that I think makes things so interesting to people from that era is, is that it really felt like you're creating your own thing, and not just everything looks the same. The term I think he used is homesteading. You're taking care of your place and it can match your sensibilities, your style, your likes, rather than having to, like you said, try to force everything to be this, this sort of base modern, look. The old spirit of the internet is coming back [00:30:08] Prefetcher: I mean Neocities and by extension also Nekoweb are websites that I often when I don't have much to do -- I like just going through them because you see a bunch of people just make their own places. And you see that even in 2025 when we have those big social media sites. You have platforms where you can get a ton of followers. You can get a ton of attention and everything. People to some extent still want that aspect of self-expression. They want to be able to make something that's uniquely theirs and you see people just make just really amazing websites build insane things on those old Geocities-like platforms using nothing but a code editor. You see them basically just wanting thing to express, oh, that's mine and no one else has it. So to say that's why. Yeah. I feel like to some extent the old school train of thought when it comes to the internet is slowly coming back. Especially with the advent of protocols like ATProto. And you'll experience more websites that just allow people to make their own homes on the internet. Cause in my opinion, one of the biggest problems is that people do not really want to register on a lot of platforms. 'cause you already have this place where you get all of your followers, you have all of your connections, and then you want to move and then you'll lose all of your connections and everything. But with something like ATProto, you can use the social graph of, for example, Bluesky. I want to add followers on PinkSea. So for example, you have an artist that has like 30,000 followers for example, I can just click import my following from Bluesky. And just like that they would already get all of the artists that they follow on Bluesky already added as followers on PinkSea. And for example, someone else joins and they followed that big artist and they instantly followed them on PinkSea as well. I think that we are slowly coming back to the advent of people owning their place online. PinkSea and ATProto (PDS) [00:32:24] Jeremy: Yeah. So let's talk a little bit more about how PinkSea fits into ATProto. For people who aren't super familiar with ATProto, maybe you could talk about how it's split up. You've got the PDS, the relays, the AppView. What are those and how do those fit into what PinkSea is? [00:32:48] Prefetcher: My favorite analogy, ATProto is a massive network, and at least me, when I saw the initial graph I was just very confused. I absolutely did not know what I'm looking at. But let's start with the base building block, something that ATProto wouldn't exist with. And it's the PDS. Think of the PDS as like a filing cabinet. You have a bunch of folders in which you have files, so to say. So you have a filing cabinet with your ID, this is the DID part that sometimes shows up and scares people. It's what we call a decentralized identifier. Basically that identifier is not really tied to the PDS, it just exists somewhere. And the end goal is that every user controls their DID. So for example, if your PDS shuts down, you can always move to somewhere else. Still keep like, for example, that you are prefetcher.miku.place. But in that filing cabinet the PDS going back to it you have your own little zone, your own cabinets, and that has your identifier, it's uniquely yours. Every single application on the AT protocol creates data. They create data and they store the data in a structured format called a record. A record is basically just a bunch of data that explains what that thing is, be it a like, a post on Bluesky an oekaki on PinkSea and an upvote on front page, or even a pixel on place.blue. And all of those records are organized into folders in your cabinet. And that folder is named with something we call a collection id. So for example, a like is, if I remember correctly, it's app.bsky.feed.like, so you see that it belongs to Bluesky. The app.bsky part. it's a feed thing, and the same way, PinkSea, for example, the oekaki and PinkSea uses com.shinolabs.pinksea.oekaki with com.shinolabs being the the collective that I use as a, pen name, so to say. PinkSea being, well, PinkSea and oekaki just being the name. It's an oekaki. If you want to see that there are a lot of tools, for example, PDSls or atp.tools or ATProto browser, if you had to go into one of those and you would type in for example, prefetcher.miku.place, you would see all of your records, the things that, you've created on the AT protocol network. Relay [00:35:19] Prefetcher: So you have a PDS, you have your data, but for example, imagine you have a PDS that you made yourself, you hosted yourself. How will, for example, Bluesky know that you exist? 'cause it won't, it's just a server in the middle of nowhere. That's where we have a relay. A relay is an application that listens to every single server. So every time you create something or you delete something, or for example, you edit a post, you delete an oekaki. You create a new, like -- Your PDS, your filing cabinet generates a record of that. It generates an event, something we call a commit. So, anytime you do something, your PDS goes, Hey, I did that thing. And relays function as big servers that a PDS can connect to. And it's a massive shout box. The PDS goes, Hey, I made this. Then the relay aggregates all of those PDSs into one and creates a massive stream of every single event that's going on the network at once. That's also where the name firehose comes from. 'cause the, the end result, the stream is like a firehose. It just shoots a lot of data directly at anyone who can connect to it. And the thing that makes AT Protocol open and able to be built on is that anyone can just go, I want to connect to jetstream1.west.bluesky.network. They just make a connection to it and boom they just get everything that's happening. You can, for example, see that via firesky.tv. If you go to it, you would open it in your browser. Every single Bluesky post being made in real time right directly in your computer. So you have the PDSs that store data, you have the relay that aggregates every, like, builds a stream of every single event on the network. AppViews [00:37:26] Prefetcher: You just get records. You can't interact with it. You can see that someone made a new record with that name, but to a human, you won't really understand what a cid is or what property something else is. That's why you have what we call AppViews. An AppView, or in full an application view is an application that runs on the AT protocol network. It connects to the relay and it transforms the network into a state that it can be used by people. That's why it's called an application view. 'cause it's a, a specialized view into the whole network. So, for example, PinkSea connects, and then it goes, hey, I want to listen on every single thing that's happening to com.shinolabs.pinksea.oekaki, and it sees all of those, new records coming in and PinkSea understands, oh, I can turn it into this, and then I can take this thing, store it in the database, and then someone can connect with a PinkSea front end. And then it can like, transform those things, those records into something that the front end understands. And then the front end can just display, for example, the timeline, the same way Bluesky, for example -- Bluesky gets every single event, every single new file, new record coming in from the network. And it goes. Okay, so this will translate into one more like on this post. And this post is a reply to that post. So I should chain it together. Oh. And this is a new feed, so I should probably display it to the user if they ask for feeds. And it basically just gets a lot of those disjoint records and it makes sense of them all. The end user has a different API to the Bluesky AppView. And then they can get a more specialized view into Bluesky. PinkSea does not store the original images, the PDS does [00:39:26] Jeremy: And so in that example, the PDSs, they can be hosted by Bluesky the company, or they could be hosted by any person. And so PinkSea itself, when somebody posts a new oekaki, a new image, they're actually telling PinkSea to go create the image in the user's PDS, right? PinkSea is itself not the the source of truth I guess you could say. [00:40:00] Prefetcher: PinkSea in itself. I don't remember which Bluesky team member said it, but I like the analogy that AppViews are like Google. So in Google, when you search something, Google doesn't have those websites. Google just knows that this thing is on that website. In the same vein, PinkSea, when you create a new oekaki, you tell PinkSea, Hey, go to my PDS and create that record for me. And then the person owns the PDS. So for example, let's say that in a year, of course I won't do it, but hypothetically here, I just go rogue and I shut down PinkSea, I delete the database. You still own the things. So for example, if someone else would clone the PinkSea repository and go here, there's PinkSea 2. They can still use all of those images that were already on the network. So, AppViews in a way basically just work as a search engine for the network. PinkSea doesn't store anything. PinkSea just indexes that a user made a thing on that server. And here I can show you how to get to it somehow. Those images aren't stored by PinkSea, but instead, I know that the image itself is stored, for example, on pds.example.com, and of course to reduce the load, we have a proxy. PinkSea asks the proxy to go to pds.example.com and fetch the image, and then it just returns it to the user. [00:41:37] Jeremy: And so what it sounds like then is if someone were to create oekaki on their own PDS completely independently of Pink Sea the fact that they had created that image would be sent to one of the relays, and then PinkSea would receive an event that says oh, this person created a new image then at that point your index could see, oh, somebody created a new image and they didn't even have to go through the PinkSea website or call the PinkSea APIs. Is that right? Sharing PDS records with other applications [00:42:14] Prefetcher: Yep. That is exactly right. For example, someone could now go, Hey, I'm making my own PinkSea-like application. And then they would go, I want to be compatible with PinkSea. So I'm using the same record. Or what we call a lexicon, basically describe how records look like. I forgot to mention that, but every single record has an attached lexicon. And lexicons serve as a blueprint. So a lexicon specifies, oh, this has an image, this has a for example, the tags attached to it, a description of the image. Validate that the record is correct, that you don't get someone just making up random stuff. But yeah, someone could just go, Hey, I'm making another website. Let's call it GreenForest for example. And GreenForest is also an oekaki website, but it uses, for example, chickenpaint instead of tegaki but I want to be able to interoperate with PinkSea. so I'm also gonna use com.shinolabs.pinksea.oekaki the collection, the same record, the same lexicon. And for example, they have their own servers and the servers just create regular oekaki records. So for example, GreenForest gets a new user, they log in, create, draw their beautiful image, and then they click upload it. So GreenForest goes to that person's PDS and tells the PDS, Hey, I want to make a new. com.shinolabs.pinksea.oekaki record. The PDS goes okay, I've done it for you. Let me just inform the relay that I did so, relay gets the notification that someone made that new PinkSea oekaki record. And so the main PinkSea instance, pinksea.art, which is listening in on the relay, gets a notification from the relay going, Hey, there is this new oekaki record. And PinkSea goes, sure, I'll index it. And so PinkSea just gets that GreenForest image directly in itself. And in the same vein, someone at PinkSea could draw something in tegaki -- their own beautiful character. And the same thing would happen with GreenForest. GreenForest would get that PinkSea image, that PinkSea record, and index it locally. So the two platforms, despite being completely different, doing completely different things, they would still be able to share images with each other. Bluesky PDS stores other AppView's data but they could stop at anytime [00:44:38] Jeremy: And these images, since they're stored in the PDS, what that would mean is that anybody building an application on ATProto, they can basically use Bluesky's PDS or the user's PDS as their storage. They could put any number of images in there and they could get into gigabytes of images. And that's the responsibility of the PDS and not yourself to keep track of. [00:45:12] Prefetcher: Yes, that can be the case. Of course, there is a hard limit on how big a single upload can be, which is, if I remember correctly, I don't wanna lie, I think it's 50 megabytes, I don't recall there being a hard cap on how big a single repository can be. I know of some people whose repositories are in the single gigabyte digits but this kind of is a thing scares app developers. 'cause you never know when Bluesky the company -- 'cause most people registering, are registering on Bluesky. We don't really know whether Bluesky, the company will want to keep it for free. Forever allow us to do something like that. You already have projects like, for example, ATFile, which just allow you to upload any arbitrary data just to store it, on their servers and they are paying for you. So we'll never know whether Bluesky will decide, okay, our services are only for Bluesky if you want to use PinkSea you have to deal with it. Or whether they go, okay, if you want to use alternative AppViews you have to pay us in order to host them. So, that also leads me to the fact that decentralization is an important part of AT protocol as Bluesky themselves say that they are a potential adversary. You cannot trust them in the long term. Right now they are benign right now, they're very nice, but, we never know how Bluesky will end up in a year or two. So if you want to be in the full control of your data, you need to sadly host it by yourself. And it's honestly really easy in order to do so. There is a ton of really useful online content blogs and whatever. I think I've set up my PDS in 10 minutes on a break between classes and university. But to a person that's non-technical that doesn't know much I'd say around an hour to two hours The liability and potential abuse from running a PDS [00:47:14] Jeremy: Yeah, I think the scary thing for a lot of people is technical or not, is even if it's easy to set up, you gotta make sure it keeps running. You gotta have backups. And so it could be a lot. [00:47:30] Prefetcher: Yeah. This is to be expected by the fact that you're in control of your data. Keeping it secure the same way, for your personal photos or your documents, for example, your master's diploma or whatever. And it's on you to keep your Bluesky interaction secure. On one hand, it's easier to get someone to do it, and I expect in the future we'll get people that are hosting public PDSes I sometimes thought of doing that for PinkSea, just like allowing people to register by PinkSea. But, doing so as a person, you also have to be constantly on call for abuse. So if someone decides to register via PinkSea and do some illicit activities, you are solely responsible for it. PDS and AppView moderation liability [00:48:17] Jeremy: So if they were to upload content that's illegal, for example, it's hosted on your servers so then it's your problem. [00:48:27] Prefetcher: Yeah, it is my problem. [00:48:29] Jeremy: At least the way that it works now, the majority of the people, their PDS is gonna be hosted by Bluesky. So if they upload content that's breaks the law, then that's the Bluesky company's problem at least currently. [00:48:44] Prefetcher: Yeah. That is something that Bluesky has to deal with. But I do believe that in the future we are going to have, more like independent entities just building infrastructure for ATProto, not even the relay it's just like PDSs for people to be able to join the atmosphere, but not directly via Bluesky. [00:49:06] Jeremy: I'm kind of curious also with the current PDSs, if it's hosted by Bluesky, are they, are they moderating what people upload to their PDSs? [00:49:16] Prefetcher: Good question. Honestly, I don't think they're moderating everything 'cause, it's infeasible for them to, for example, other than moderate Bluesky to also moderate PinkSea and moderate front page and whatnot. So it's the obvious responsibility to moderate itself and to report abuse. I'd say that if someone started uploading illicit material, I do not think, and this is not legal advice, I do not think that they would catch on until some point let's say. [00:49:52] Jeremy: I mean, from what you were describing too, it seems like the AppViews would also, have issues with this because if, let's say someone created a PinkSea record in their PDS directly and the image they put in was not an oekaki image, it's instead something pretty illegal in the country that your AppView is hosted then, Wouldn't that go straight to the PinkSea users viewing the website? [00:50:20] Prefetcher: Yes, sadly, this is something that you have to sign up as you're making an AppView and especially one with images. Sooner or later you are going to get material that you have to moderate and it's entirely on you. That's why, you have to think of moderation while you're working on an AppView. Bluesky has an insanely complicated, at least in my opinion, moderation system, which is composable and everything, which I like. But for smaller AppViews, I think it's too much to build the same level of tooling. So you have to rely more on manual work. Thankfully so far the user base on PinkSea has been nothing but stellar. I didn't have to deal with any law breaking stuff, but I am absolutely ready for one day where I'll have to sadly make some drastic moderation issues. [00:51:18] Jeremy: Yeah. I think to me that's the most terrifying thing about making any application that's open to user content. [00:51:29] Prefetcher: I get it, sadly. I'm no stranger to having issues with people, abusing my websites. Because since 2016, my, first major project was a text board based off of, a text board in a video game called DANGER/U/. It was semi-popular, during the biggest spike in activity in like 2017 and 2016, it had in the tens of thousands of monthly visitors. And sadly, yeah, even though it was only text, I've had to deal with a lot of annoying issues. So to say the worst I think was I remember waking up and people are telling me that DANGER/U/ is down. So I log in the activity logs and someone hit me with two terabytes of traffic in a day. There was a really dedicated person that just hated my website and just either spam me with posts or just with traffic. So, yeah, sadly I have experience with that. I know what to expect that's something that you sadly have to sign up for making a website that allows user content. Pinksea is a single server [00:52:42] Jeremy: To my understanding so far, PinkSea is just a single server. Is that right? [00:52:47] Prefetcher: It is a single server. Yeah. [00:52:48] Jeremy: That's kind of interesting in that, I think a lot of people when they make a project, they worry about scaling and things like that. But, was it a case where you just had a existing VPS and you're like, well hopefully this is, this is good enough? [00:53:03] Prefetcher: I actually ordered a new one even though it's not really powerful, but my train of thought was that I didn't expect it to blow up. I didn't expect it to require more than a single VPS with 8 gigabytes of RAM and whatnot. And so far it's handling it pretty well. I do not expect ever to reach the amounts of traffic that Bluesky does, so I do not really have to worry about insane scalability and whatever. But yeah. I thought of it always as a toy project until the day I released it and realized that it's a bit more than a toy project at this point. To this day, I just kind of think that that website even if it were popular, I would never expect it to have -- And in the best, most amazing case scenario, like a hundred posts a day. I do not have to deal with the amount of traffic that Bluesky does. So one VPS it is. [00:53:59] Jeremy: Yeah, that makes a lot of sense. I mean the application is also mostly reads, right? Most people are coming to see the posts and like you said, you get a few submissions a day, but all the read stuff can probably be cached. Harbor image proxy [00:54:15] Prefetcher: Yeah. The heaviest, thing that PinkSea requires is the image proxy harbor, and that's something that right now only runs on that server. It's in Luxembourg. I think that's where my coprovider hosts it but yeah, that gets the most reads. 'cause in most cases, PinkSea, all it does, all you get is reads from a database, which is just, it's a solved problem. It's really lightweight. But with something like image proxying, you have this whole new problem. 'cause it's a lot of data, and you somehow have to send it -- it's enough for me to just host it locally on that PinkSea server and just direct people to it. But sooner or later, I can always just put it behind something like Bunny CDN or whatnot to have it be worldwide. [00:55:09] Jeremy: So Harbor is something I think you added recently. How did the images work before and what is Harbor doing in its place? [00:55:18] Prefetcher: Before I did what a lot of us currently do and I just freeload atop of Bluesky CDN 'cause Bluesky CDN is just open so far. But it's something that personally irked me. 'cause, I want PinkSea to be completely independent of Bluesky Corporation. I, I wanted to persevere even if Bluesky just decides to randomly, for example, close, the CDN to others or the relay to others or the PLC directory in the worst case scenario. So I wanted to make my own CDN more like proxy. You can't really call it a CDN because it's not worldwide. It's just a single server but let's just say image proxy. So Harbor whenever a person goes to PinkSea, they start loading in all of the images and every single image instead of going to, for example, the PDS or to cdn.bluesky.app. They go to harbor.pinksea.art, you get attached the identifier of the user and what we call a content identifier. Every single, thing uploaded to a PDS has an attached content identifier, which identifies it in a secure way so to say. So Harbor does in reality a really simple set of things. First and foremost, if the user has not seen it, like, not loaded it before first Harbor asks the local cache, do I have this file? If they do, if Harbor does, it just sends the file and it tells the browser, Hey, by the way, please don't ask me about this file for the next day. And in most cases, after one refresh, the user, all of the images load instantly because the web browser just goes, of those files were already sent. And Harbor asked me not to like, ask it more about the same file. So in the case of the image isn't in harbor's local cache, Harbor, first does a lot of those steps to resolve, the users identifier through their PDS, basically resolving that identifier, the DID to a DID document, which is a document basically explaining how that user, what is their, alias, what is their handle and where can we find them, which PDS. So we find the PDS and we then ask the PDS, Hey, send us this file for this user. The PDS sends it or doesn't, in which case we just throw an error and, Harbor just saves it locally and it sends it to the client. It basically just that. But to my knowledge, it's the first non Bluesky image proxy that's deployed for any AppView. Which also caught the attention of Brian Newbold one of the Bluesky employees and made me really happy. DID PLC Lookup [00:58:14] Jeremy: The lookup when you have the user's, DID and you wanna find out where their PDS is that's talking to something called, I think it's the PLC directory? [00:58:25] Prefetcher: Actually there are two different ways. First is PLC directory, PLC originally standed for a placeholder, and then Bluesky realized that it's not a placeholder anymore, and they stealthily changed it to public ledger of credentials. So we have PLC and we have web, the most common version is PLC. The document, the DID document is stored on Bluesky controlled servers under the moniker of PLC directory. They expose a web API that basically just allows you to say, Hey, give me the document for did:plc, whatever. And, the directory goes, have it. And this is the less decentralized version. You can host your own PLC directory and you can basically ask (their) PLC directory to just send you every single document and just you can have your local copy, which some people already do, you kind of sacrifice the fact that you are not in control of the document. It's still on a centralized server, even if you control the keys. 'cause every single DID document also has a key. And that key is used to sign changes to the document. So technically, if you define your own set of keys, you can prevent anyone else from modifying your document, even Bluesky. 'cause every single document is verifiable back and forth. You can see the previous document and its key is used to sign the next document and the chain of trust is visible and no one can just make random changes to your identity, but yeah, it's still on Bluesky to control service and it's a point of contention. Bluesky eventually wants to move it to a nonprofit standards organization, but we have yet to see anything come out of it, sadly. DID WEB lookup The next method is web. And web instead of -- 'cause in did:plc, you have did:plc, and a random string of characters. [01:00:30] Prefetcher: Web relies on domains. So for example, the domain would already like be the sole authority of where the file is. So for example, if I had did:web:example.com, I would parse the DID and I would see it's hosted at example.com. So I go to example.com, I go to /.wellknown/did.json which is the well-known location for the file. And I would have the same DID document as I would have if I used, for example, a PLC DID resolved via the PLC directory. the web method, you are in control of the document entirely. It's on your server under your domain. While it's the more decentralized version, it's just kind of hard for non-technical people to make them. 'cause it relies on a bunch of things. And also the problem is that if you lose your domain, you also lose your identity. [01:01:23] Jeremy: Yeah. So unlike the PLC where it's not really tied to a specific domain, you can change domains. With the web way, you have to always keep the same domain 'cause it's a part of the DID and yeah, like you said, you can't let your renewal lapse or your credit card not work. 'cause then you just lose everything. [01:01:49] Prefetcher: Yeah. You would still be able to change handles, but you would be tied for that domain to forever send your DID otherwise you would just lose it forever. [01:01:57] Jeremy: Yeah, I had mostly only seen the PLC and I wasn't too familiar with the web, form of identification, but yeah that makes sense. [01:02:06] Prefetcher: I think the web if I remember correctly, there is slightly over 300 accounts total on the entire network that use it. Mary who is a person on Bluesky that does a lot of like, ATProto related things, has a GitHub repository that basically gives insight into the network. And on her GitHub repository, you can find the list of every single custom PDS and also how many DID webs there are in existence. And I think it was slightly over 300. [01:02:38] Jeremy: So are you on that list? [01:02:40] Prefetcher: My PDS Yeah. If you were to scroll down. I don't use a web DID 'cause I registered my account before when I was brand new to ATProto, so I didn't know anything. But if you had to scroll down, you would see pds.ata.moe, which is my custom PDS just running. [01:02:55] Jeremy: Cool. [01:02:57] Prefetcher: Yeah. Harbor image proxy can cache any image blob [01:02:58] Jeremy: So something I noticed about harbor, you take the, I believe you take the DID and then you take the CID, the content identifier. I noticed if you take any of those pairs from the ATProto network, like I go find a image somebody posted on Bluesky, I pass that post DID and CID for the image into harbor. Harbor downloads it and caches it. So it's like, does that mean anybody could technically use you as a ATProto CDN? [01:03:38] Prefetcher: Yes, the same way anyone could use like the Bluesky CDN to for example, run PinkSea like I did. cause I do not know if there is a good way to check if a CID of an image or a blob basically. 'cause files on ATProto are called blobs. I do not think there is a nice way to check if that blob is directly tied to a specific record. But that also allows you to make cool, interesting things. Crossposting to Bluesky talks directly to the PDS [01:04:06] Prefetcher: 'cause for example, PinkSea has that, cross post to Bluesky thing. So when you create an image, You already have an option to cross post it to Bluesky, which a lot of people liked. And it was a suggestion from one of the early users of PinkSea. And the way it works is that when we create a PinkSea record, we upload that image, right? And then PinkSea goes, okay, I'm gonna use that same image, the same content identifier, and just create a Bluesky post. So Bluesky and PinkSea all share the same image. I don't upload it twice, I just upload it once. use it in PinkSea and I also use it in Bluesky. And the same way Bluesky its CDN, can just fetch the image. I can also fetch the image from mine, 'cause blobs aren't tied to specific records. They just exist outside of that realm. And you could just query anything. Not even images. You could probably query a video or even a text file. [01:05:04] Jeremy: So when you cross post to Bluesky, you're creating a record directly in the person's PDS, not going through bluesky's API. [01:05:14] Prefetcher: No, I sidestep Bluesky's API completely. And, I basically directly talk to the PDS at all times. I just tell them, Hey, please, for me, create a app.bsky.feed.post record. And you have the image, the text, which also required me to manually parse text into rich text. 'cause like, Bluesky doesn't automatically detect for example, links or tags And you basically get -- like PinkSea creates a record directly with the link to the image. And all of those tags, like the PinkSea tag and whatever, And I completely sidestep. Bluesky's API. If Bluesky, the AppView would cease to exist, PinkSea would still happily create Bluesky crossposts for you. Other applications put metadata into Bluesky posts so they can treat them differently [01:06:02] Jeremy: And since you're creating the records yourself, then you can include additional metadata or fields where you know that this was a PinkSea post, or originally came from PinkSea. [01:06:13] Prefetcher: I could do that. I don't really do that right now 'cause I don't really have much of a reason other than adding a PinkSea hashtag to every single oekaki. But I, noticed, for example, I think it was PinkSky, interesting name, PinkSky, which is like (a) Bluesky Instagram client. Any single time you make a post via PinkSky it uses the Bluesky APIs. It's Bluesky, but it attaches a hidden hashtag like PinkSky underscore some random letters. In its feed building algorithm, it basically detects posts with that hashtag, that specific hashtag, and it builds a PinkSky only timeline. 'cause it's still a Bluesky post, but it has hidden additional metadata that identifies, Hey, it came from PinkSky. [01:07:02] Jeremy: It's pretty interesting how much control you have over what to put in the PDS. So, I'm sure there's a lot of interesting use cases that people are gonna come up with. [01:07:14] Prefetcher: Yeah, of course. You still lose some of the data when you go through the Bluesky API. 'cause of course it stores the record and it's all in formats and whatnot. But you can attach a lot of metadata that can identify posts and build micro networks within Bluesky itself. I see it like that. Bluesky CDN compression [01:07:37] Jeremy: And I think, this might have been a post from you. I think I saw somebody saying that when you view an image from the CDN that the Bluesky CDN specifically, there's some kind of compression going on that that messes with certain types of art. [01:07:55] Prefetcher: It's especially noticeable artists are complaining about it all the time, left and right. Bluesky is very happy with jpeg compression, by default, their CDN, -- like to every single image it applies a really not good amount of jpeg compression which is especially not small. If you compare an image that's uploaded via PinkSea, view an image on PinkSea, and view the same image, which is, it's the same content id. It's the same blob. And you view it on Bluesky, it loses so much fidelity, it loses so much of that aliasing on the pen. You just see everything become really blurry. And on top of that, when you upload an image via Bluesky itself, if I remember correctly, I don't wanna lie here, but they also downscale the image to 1024 pixels by default. So every single image, not only big ones, and artists usually work with really big canvases, they get, downscaled and also additionally they get jpegified. So for example, PinkSea directly uploads PNG files to the PDS. And for example, Harbor gives back the original file. It does no transformations on it, but Bluesky transforms all of them into JPEG compressed images and for photos, it's fine sometimes. 'cause I've also seen people just compare directly, downloaded images of the PDS versus images viewed on Bluesky. But for art it's especially noticible. And people really (do) not like that. [01:09:31] Jeremy: Yeah, that's kind of odd. 'cause if, if I understand correctly, then if you post directly to your PDS and Bluesky pulls it in you'll avoid that, that 1024 resizing. So your images will be higher quality? [01:09:47] Prefetcher: I actually do not know. That's an interesting question. Cause I know that the maybe their CDN also does that 'cause that's what I've heard from others, that on upload the image gets processed and squashed down. So I don't know if doing it via an alternative AppView would change it or would Bluesky just directly reject this post? Because for example, PinkSea, I have built-in which I think I might change in the future -- PinkSea will reject your post if it's bigger than 800x800. 'cause then it'll notice that something is off. This could not have been made with PinkSea. [01:10:26] Jeremy: Yeah, that's a good point I suppose we know at the very least, they have some third party and internal moderation tools that they feed the images through to, so they, they can do some automatic content tagging. But yeah, I, I don't know, like you said, whether, the resizing and all that stuff is at the CDN level [01:10:50] Prefetcher: The jpegification is definitely at the CDN level. 'cause, Bluesky is actually running an open source image proxy. It's called imgproxy. Brian Newbold talked about it a bit on that harbor post. And, yeah, so a lot of the compression, the end user things are done via image proxy, but that, downscaling, I don't know, you'd have to ask someone who's a bit more intimate with Bluesky's internals. [01:11:19] Jeremy: Cool. yeah, I think we've, we've covered a lot. Is there, is there anything else, you wanted to mention or thought we should have talked about? [01:11:26] Prefetcher: Regarding PinkSea I think I've mentioned a ton both the behind the scenes things and, the user things, the design principles. What I'd want to absolutely say, and it will sound cheesy, and, is that I'm eternally grateful to anyone who's actually visited PinkSea. It's definitely grown outta all of my like dreams for the platform, to the point where I'm sitting here just talking about it. I definitely hope that the future will bring us more applications (in) ATProto. I definitely have ideas on how to expand PinkSea, a lot of ideas, a lot of things I want to do, and I'm also a very busy person, so I never get around them. But yeah, think that's it, at least regarding PinkSea. [01:12:15] Jeremy: Cool. Well, if people want to check out PinkSea or see what you're up to, where can they find you? [01:12:22] Prefetcher: So PinkSea is at pinksea.art. That's the website and Bluesky Handle is at pinksea.art and me, well, search prefetcher on Bluesky, you'll probably find me. My tag is at prefetcher.miku.place. all of my socials are probably there. I'm Prefetcher pretty much every single platform except for the platforms that already had someone called Prefetcher. GitHub, github.com/purifetchi because Prefetcher was taken. And, yeah, hit me up. I'm always eager to talk. I don't bite. [01:13:00] Jeremy: Very cool. Well, Kacper thanks. Thanks for taking the time. This was fun. [01:13:04] Prefetcher: Thank you so much, Jeremy, for having me over. It was a pleasure.

In this deeply moving episode, I speak with Laura Garcia, a psychologist and wildfire survivor, who shares her incredible story of premonitions, loss, and spiritual resilience. Laura recounts the chilling dreams and intuitive nudges she experienced before the devastating California wildfires that destroyed her family home. We explore the power of intuition, the importance of community, and the profound ways that spirituality can guide us through even the darkest of times. Join us for this heartfelt conversation as we witness Laura's incredible strength and discover how she finds hope and meaning in the ashes of loss.*********************************************** JOIN MY COMMUNITY In The Space Between membership, you'll get access to LIVE quarterly Ask Amy Anything meetings (not offered anywhere else!), discounts on courses, special giveaways, and a place to connect with Amy and other like-minded people. You'll also get exclusive access to other behind-the-scenes goodness when you join! https://the-space-between-community.circle.so/checkout/the-space-between-membership Stay Connected with Dr. Amy Robbins:InstagramYouTubeWebsiteFacebook YouTubeLife, Death & the Space Between Dr. Amy RobbinsExploring life, death, consciousness and what it all means. https://www.youtube.com/channel/UCEllYb5lKCXnpCGNtoFpS7g?sub_confirmation=1 dramyrobbins.comDr. Amy Robbins Put your preconceived notions aside as we explore life, death, consciousness and what it all means on Life, Death & the Space Between. *********************************************** Hosted on Acast. See acast.com/privacy for more information.

Paul Frazee is the CTO of Bluesky. He previously worked on the Beaker browser and the peer-to-peer social media protocol Secure Scuttlebutt. Paul discusses how Bluesky and ATProto got started, scaling up a social media site, what makes ATProto decentralized, lessons ATProto learned from previous peer-to-peer projects, and the challenges of content moderation. Episode transcript available here. My Bluesky profile. -- Related Links Bluesky ATProtocol ATProto for distributed systems engineers Bluesky and the AT Protocol: Usable Decentralized Social Media Decentralized Identifiers (DIDs) ActivityPub Webfinger Beaker web browser Secure Scuttlebutt -- Transcript You can help correct transcripts on GitHub. [00:00:00] Jeremy: Today I am talking to Paul Frazee. He's the current CTO of bluesky, and he previously worked on other decentralized applications like Beaker and Secure Scuttlebutt. [00:00:15] Paul: Thanks for having me. What's bluesky [00:00:16] Jeremy: For people who aren't familiar with bluesky, what is it? [00:00:20] Paul: So bluesky is an open social network, simplest way to put it, designed in particular for high scale. That's kind of one of the big requirements that we had when we were moving into it. and it is really geared towards making sure that the operation of the social network is open amongst multiple different organizations. [00:00:44] So we're one of the operators, but other folks can come in, spin up the software, all the open source software, and essentially have a full node with a full copy of the network active users and have their users join into our network. And they all work functionally as one shared application. [00:01:03] Jeremy: So it, it sounds like it's similar to Twitter but instead of there being one Twitter, there could be any number and there is part of the underlying protocol that allows them to all connect to one another and act as one system. [00:01:21] Paul: That's exactly right. And there's a metaphor we use a lot, which is comparing to the web and search engines, which actually kind of matches really well. Like when you use Bing or Google, you're searching the same web. So on the AT protocol on bluesky, you use bluesky, you use some alternative client or application, all the same, what we're we call it, the atmosphere, all one shared network, [00:01:41] Jeremy: And more than just the, the client. 'cause I think sometimes when people think of a client, they'll think of, I use a web browser. I could use Chrome or Firefox, but ultimately I'm connecting to the same thing. But it's not just people running alternate clients, right? [00:01:57] Paul: Their own full backend to it. That's right. Yeah. Yeah. The anchoring point on that being the fire hose of data that runs the entire thing is open as well. And so you start up your own application, you spin up a service that just pipes into that fire hose and taps into all the activity. History of AT Protocol [00:02:18] Jeremy: Talking about this underlying protocol maybe we could start where this all began so people get some context for where this all came from. [00:02:28] Paul: For sure. All right, so let's wind the clock back here in my brain. We started out 2022, right at the beginning of the year. We were formed as a, essentially a consulting company outside of Twitter with a contract with Twitter. And, uh, our goal was to build a protocol that could run, uh, Twitter, much like the way that we just described, which set us up with a couple of pretty specific requirements. [00:02:55] For one, we had to make sure that it could scale. And so that ended up being a really important first requirement. and we wanted to make sure that there was a strong kind of guarantees that the network doesn't ever get captured by any one operator. The idea was that Twitter would become the first, uh, adopter of the technology. [00:03:19] Other applications, other services would begin to take advantage of it and users would be able to smoothly migrate their accounts in between one or the other at any time. Um, and it's really, really anchored in a particular goal of just deconstructing monopolies. Getting rid of those moats that make it so that there's a kind of a lack of competition, uh, between these things. [00:03:44] And making sure that, if there was some kind of reason that you decided you're just not happy with what direction this service has been going, you move over to another one. You're still in touch with all the folks you were in touch with before. You don't lose your data. You don't lose your, your your follows. Those were the kind of initial requirements that we set out with. The team by and large came from, the decentralized web, movement, which is actually a pretty, large community that's been around since, I wanna say around 2012 is when we first kind of started to form. It got really made more specifically into a community somewhere around 2015 or 16, I wanna say. [00:04:23] When the internet archives started to host conferences for us. And so that gave us kind of a meeting point where all started to meet up there's kind of three schools of thought within that movement. There was the blockchain community, the, federation community, and the peer-to-peer community. [00:04:43] And so blockchain, you don't need to explain that one. You got Federation, which was largely ActivityPub Mastodon. And then peer-to-peer was IPFS, DAT protocol, um, secure scuttlebutt. But, those kinds of BitTorrent style of technologies really they were all kind of inspired by that. [00:05:02] So these three different kind of sub communities we're all working, independently on different ways to attack how to make these open applications. How do you get something that's a high scale web application without one corporation being the only operator? When this team came together in 2022, we largely sourced from the peer-to-peer group of the decentralized community. Scaling limitations of peer-to-peer [00:05:30] Paul: Personally, I've been working in the space and on those kinds of technologies for about 10 years at that stage. And, the other folks that were in there, you know, 5-10 each respectively. So we all had a fair amount of time working on that. And we had really kind of hit some of the limitations of doing things entirely using client devices. We were running into challenges about reliability of connections. Punching holes to the individual device is very hard. Synchronizing keys between the devices is very hard. Maintaining strong availability of the data because people's devices are going off and on, things like that. Even when you're using the kind of BitTorrent style of shared distribution, that becomes a challenge. [00:06:15] But probably the worst challenge was quite simply scale. You need to be able to create aggregations of a lot of behavior even when you're trying to model your application as largely peer wise interactions like messaging. You might need an aggregation of accounts that even exist, how do you do notifications reliably? [00:06:37] Things like that. Really challenging. And what I was starting to say to myself by the end of that kind of pure peer-to-peer stent was that it can't be rocket science to do a comment section. You know, like at some point you just ask yourself like, how, how hard are we willing to work to, to make these ideas work? [00:06:56] But, there were some pretty good pieces of tech that did come out of the peer-to-peer world. A lot of it had to do with what I might call a cryptographic structure. things like Merkel trees and advances within Merkel Trees. Ways to take data sets and reduce them down to hashes so that you can then create nice signatures and have signed data sets at rest at larger scales. [00:07:22] And so our basic thought was, well, all right, we got some pretty good tech out of this, but let's drop that requirement that it all run off of devices. And let's get some servers in there. And instead think of the entire network as a peer-to-peer mesh of servers. That's gonna solve your scale problem. [00:07:38] 'cause you can throw big databases at it. It's gonna solve your availability problems, it's gonna solve your device sync problems. But you get a lot of the same properties of being able to move data sets between services. Much like you could move them between devices in the peer-to-peer network without losing their identifiers because you're doing this in direction of, cryptographic identifiers to the current host. [00:08:02] That's what peer-to-peer is always doing. You're taking like a public key or hash and then you're asking the network, Hey, who has this? Well, if you just move that into the server, you get the same thing, that dynamic resolution of who's your active host. So you're getting that portability that we wanted real bad. [00:08:17] And then you're also getting that kind of in meshing of the different services where each of them is producing these data sets that they can sink from each other. So take peer-to-peer and apply it to the server stack. And that was our kind of initial thought of like, Hey, you know what? This might work. [00:08:31] This might solve the problems that we have. And a lot of the design fell out from that basic mentality. Crytographic identifiers and domain names [00:08:37] Jeremy: When you talk about these cryptographic identifiers, is the idea that anybody could have data about a person, like a message or a comment, and that could be hosted different places, but you would still know which person that originally came from. Is that, is that the goal there? [00:08:57] Paul: That's exactly it. Yeah. Yeah. You wanna create identification that supersedes servers, right? So when you think about like, if I'm using Twitter and I wanna know what your posts are, I go to twitter.com/jeremy, right? I'm asking Twitter and your ID is consequently always bound to Twitter. You're always kind of a second class identifier. [00:09:21] We wanted to boost up the user identifier to be kind of a thing freestanding on its own. I wanna just know what Jeremy's posts are. And then once you get into the technical system it'll be designed to figure out, okay, who knows that, who can answer that for you? And we use cryptographic identifiers internally. [00:09:41] So like all the data sets use these kind of long URLs to identify things. But in the application, the user facing part, we used domain names for people. Which I think gives the picture of how this all operates. It really moves the user accounts up into a free standing first class identifier within the system. [00:10:04] And then consequently, any application, whatever application you're using, it's really about whatever data is getting put into your account. And then that just exchanges between any application that anybody else is using. [00:10:14] Jeremy: So in this case, it sounds like the identifier is some long string that, I'm not sure if it's necessarily human readable or not. You're shaking your head no. [00:10:25] Paul: No. [00:10:26] Jeremy: But if you have that string, you know it's for a specific person. And since it's not really human readable, what you do is you put a layer on top of it which in this case is a domain that somebody can use to look up and find the identifier. [00:10:45] Paul: Yeah, yeah, yeah. So we just use DNS. Put a TXT record in there, map into that long string, or you could do a .well-known file on a web server if that's more convenient for you. And then the ID that's behind that, the non-human readable one, those are called DIDs which is actually a W3C spec. Those then map to a kind of a certificate. What you call a DID document that kind of confirms the binding by declaring what that domain name should be. So you get this bi-directional binding. And then that certificate also includes signing keys and active servers. So you pull down that certificate and that's how the discovery of the active server happens is through the DID system. What's stored on a PDS [00:11:29] Jeremy: So when you refer to an active server what is that server and what is that server storing? [00:11:35] Paul: It's kinda like a web server, but instead of hosting HTML, it's hosting a bunch of JSON records. Every user has their own document store of JSON documents. It's bucketed into collections. Whenever you're looking up somebody on the network you're gonna get access to that repository of data, jump into a collection. [00:11:58] This collection is their post collection. Get the rkey (Record Key), and then you're pulling out JSON at the end of it, which is just a structured piece of stuff saying here's the CreatedAt, here's the text, here's the type, things like that. One way you could look at the whole system is it's a giant, giant database network. Servers can change, signing keys change, but not DID [00:12:18] Jeremy: So if someone's going to look up someone's identifier, let's say they have the user's domain they have to go to some source, right? To find the user's data. You've mentioned, I think before, the idea that this is decentralized and by default I would, I would picture some kind of centralized resource where I send somebody a domain and then they give me back the identifier and the links to the servers. [00:12:46] So, so how does that work in practice where it actually can be decentralized? [00:12:51] Paul: I mentioned that your DID that non-human readable identifier, and that has that certificate attached to it that lists servers and signing keys and things like that. [00:13:00] So you're just gonna look up inside that DID document what that server is your data repository host. And then you contact that guy and say, all right, I'm told you're hosting this thing. Here's the person I'm looking for, hand over the hand over the data. It's really, you know, pretty straightforward. [00:13:18] The way that gets decentralized is by then to the fact that I could swap out that active server that's in my certificate and probably wanna rotate the signing keys 'cause I've just changed the, you know. I don't want to keep using the same signing keys as I was using previously because I just changed the authority. [00:13:36] So that's the migration change, change the hosting server, change out the signing keys. Somebody that's looking for me now, they're gonna load up my document, my DID document. They're gonna say, okay, new server, new keys. Pull down the data. Looks good, right? Matches up with the DID doc. [00:13:50] So that's how you get that level of portability. But when those changes happen, the DID doesn't change, right? The DID document changes. So there's the level of indirection there and that's pretty important because if you don't have a persistent identifier whenever you're trying to change out servers, all those backlinks are gonna break. [00:14:09] That's the kind of stuff that stops you from being able to do clean migrations on things like web-based services. the only real option is to go out and ask everybody to update their data. And when you're talking about like interactions on the social network, like people replying to each other, there's no chance, right? [00:14:25] Every time somebody moves you're gonna go back and modify all those records. You don't even control all the records from the top down 'cause they're hosted all over the web. So it's just, you can't do it. Generally we call this account portability, that you're kinda like phone number portability that you can change your host, but, so that part's portable, but the ID stays the same. [00:14:45] And keeping that ID the same is the real key to making sure that this can happen without breaking the whole system. [00:14:52] Jeremy: And so it, it sounds like there's the decentralized id, then there's the decentralized ID document that's associated with that points you to where the actual location of your, your data, your posts, your pictures and whatnot. but then you also mentioned that they could change servers. [00:15:13] So let's say somebody changes where their data is, is stored, that would change the servers, I guess, in their document. But [00:15:23] then how do all of these systems. Know okay. I need to change all these references to your old server, to these new servers, [00:15:32] Paul: Yeah. Well, the good news is that you only have to, you, you got the public data set of all the user's activity, and then you have like internal caches of where the current server is. You just gotta update those internal caches when you're trying to contact their server. Um, so it's actually a pretty minimal thing to just like update like, oh, they moved, just start talking to update my, my table, my Redis, that's holding onto that kind of temporary information, put it on ttl, that sort of thing. Most communication won't be between servers, it will be from event streams [00:16:01] Paul: And, honestly, in practice, a fair amount of the system for scalability reasons doesn't necessarily work by servers directly contacting each other. It's actually a little bit more like how, I told you before, I'm gonna use this metaphor a lot, the search engines with the web, right? What we do is we actually end up crawling the repositories that are out in the world and funneling them into event streams like a Kafka. And that allows the entire system to act like a data processing pipeline where you're just tapping into these event streams and then pushing those logs into databases that produce these large scale aggregations. [00:16:47] So a lot of the application behavior ends up working off of these event logs. If I reply to somebody, for instance, I don't necessarily, it's not, my server has to like talk to your server and say, Hey, I'm replying to you. What I do is I just publish a reply in my repository that gets shot out into the event logs, and then these aggregators pick up that the reply got created and just update their database with it. [00:17:11] So it's not that our hosting servers are constantly having to send messages with each other, you actually use these aggregators to pull together the picture of what's happening on the network. [00:17:22] Jeremy: Okay, so like you were saying, it's an event stream model where everybody publishes the events the things that they're doing, whether that's making a new post, making a reply, that's all being posted to this event stream. And then everybody who provides, I'm not sure if instances is the right term, but an implementation of the atmosphere protocol (Authenticated Transfer protocol). [00:17:53] They are listening for all those changes and they don't necessarily have to know that you moved servers because they're just listening for the events and you still have the same identifier. [00:18:10] Paul: Generally speaking. Yeah. 'cause like if you're listening to one of these event streams what you end up looking for is just the signature on it and making sure that the signature matches up. Because you're not actually having to talk to their live server. You're just listening to this relay that's doing this aggregation for you. [00:18:27] But I think actually to kind of give a little more clarity to what you're talking about, it might be a good idea to refocus how we're talking about the system here. I mentioned before that our goal was to make a high scale system, right? We need to handle a lot of data. If you're thinking about this in the way that Mastodon does it, the ActivityPub model, that's actually gonna give you the wrong intuition. Designing the protocol to match distributed systems practices (Event sourcing / Stream processing) [00:18:45] Paul: 'cause we chose a dramatically different system. What we did instead was we picked up, essentially the same practices you're gonna use for a data center, a high scale application data center, and said, all right, how do you tend to build these sorts of things? Well, what you're gonna do is you're gonna have, multiple different services running different purposes. [00:19:04] It gets pretty close to a microservices approach. You're gonna have a set of databases, and then you're going to, generally speaking for high scale, you're gonna have some kind of a kafka, some kind of a event log that you are tossing changes about the state of these databases into. And then you have a bunch of secondary systems that are tapping into the event log and processing that into, the large scale, databases like your search index, your, nice postgres of user profiles. [00:19:35] And that makes sure that you can get each of these different systems to perform really well at their particular task, and then you can detach them in their design. for instance, your primary storage can be just a key value store that scales horizontally. And then on the event log, you, you're using a Kafka that's designed to handle. [00:19:58] Particular semantics of making sure that the messages don't get dropped, that they come through at a particular throughput. And then you're using, for us, we're using like ScyllaDB for the big scale indexes that scales horizontally really well. So it's just different kind of profiles for different pieces. [00:20:13] If you read Martin Kleppman's book, data Intensive applications I think it's called or yeah. A lot of it gets captured there. He talks a lot about this kind of thing and it's sometimes called a kappa architecture is one way this is described, event sourcing is a similar term for it as well. [00:20:30] Stream processing. That's pretty standard practices for how you would build a traditional high scale service. so if you take, take this, this kind of microservice architecture and essentially say, okay, now imagine that each of the services that are a part of your data center could be hosted by anybody, not just within our data center, but outside of our data center as well and should be able to all work together. [00:20:57] Basically how the AT Proto is designed. We were talking about the data repository hosts. Those are just the primary data stores that they hold onto the user keys and they hold onto those JSON records. And then we have another service category we call Relay that just crawls those data repositories and sucks that in that fire hose of data we were talking about that event log. App views pull data from relay and produces indexes and threads [00:21:21] Paul: And then we have what we call app views that sit there and tail the index and tail the log, excuse me, and produce indexes off of it, they're listening to those events and then like, making threads like okay, that guy posted, that guy replied, that guy replied. [00:21:37] That's a thread. They assemble it into that form. So when you're running an application, you're talking to the AppView to read the network, and you're talking to the hosts to write to the network, and each of these different pieces sync up together in this open mesh. So we really took a traditional sort of data center model and just turned it inside out where each piece is a part of the protocol and communicate it with each other and therefore anybody can join into that mesh. [00:22:07] Jeremy: And to just make sure I am tracking the data repository is the data about the user. So it has your decentralized identifier, it has your replies, your posts, And then you have a relay, which is, its responsibility, is to somehow find all of those data repositories and collect them as they happen so that it can publish them to some kind of event stream. [00:22:41] And then you have the AppView which it's receiving messages from the relay as they happen, and then it can have its own store and index that for search. It can collect them in a way so that it can present them onto a UI. That's sort of thing that's the user facing part I suppose. [00:23:00] Paul: Yeah, that's exactly it. And again, it's, it's actually quite similar to how the web works. If you combine together the relay and the app view, you got all these different, you know, the web works where you got all these different websites, they're hosting their stuff, and then the search engine is going around, aggregating all that data and turning it into a search experience. [00:23:19] Totally the same model. It's just being applied to, more varieties of data, like structured data, like posts and, and replies, follows, likes, all that kinda stuff. And then instead of producing a search application at the end. I mean, it does that too, but it also produces a, uh, you know, timelines and threads and, um, people's profiles and stuff like that. [00:23:41] So it's actually a pretty bog standard way of doing, that's one of the models that we've seen work for large scale decentralized systems. And so we're just transposing it onto something that kind of is more focused towards social applications [00:23:58] Jeremy: So I think I'm tracking that the data repository itself, since it has your decentralized identifier and because the data is cryptographically signed, you know, it's from a specific user. I think the part that I am still not quite sure about is the relays. I, I understand if you run all the data repositories, you know where they are, so you know how to collect the data from them. [00:24:22] But if someone's running another system outside of your organization, how do they find, your data repositories? Or do they have to connect to your relay? What's the intention for that? Data hosts request relays to pull their data [00:24:35] Paul: That logic runs, again, really similar to how search engines find out about websites. So there is actually a way for, one of these, data hosts to contact Relay and say, Hey, I exist. You know, go ahead and get my stuff. And then it'll be up to the relay to decide like if they want it or not. [00:24:52] Right now, generally we're just like, yeah, you know, we, we want it. But as you can imagine, as the thing matures and gets to higher scale, there might be some trust kind of things to worry about, you know? So that's kind of the naive operation that currently exists. But over time as the network gets bigger and bigger, it'll probably involve some more traditional kind of spiraling behaviors because as more relays come into the system, each of these hosts, they're not gonna know who to talk to. Relays can bootstrap who they know about by talking to other relays [00:25:22] Paul: You're trying to start a new relay. What they're gonna do is they're going to discover all of the different users that exist in the system by looking at what data they have to start with. Probably involve a little bit of a manual feeding in at first, whenever I'm starting up a relay, like, okay, there's bluesky's relay. [00:25:39] Lemme just pull what they know. And then I go from there. And then anytime you discover a new user you don't have, you're like, oh, I wanna look them up. Pull them into the relay too. Right. So there's a, pretty straightforward, discovery process that you'll just have to bake into a relay to, to make sure you're calling as much the network as possible. ActivityPub federation vs AT Proto [00:25:57] Jeremy: And so I don't think we've defined the term federation, but maybe you could explain what that is and if that is what this is. [00:26:07] Paul: We are so unsure. [00:26:10] Jeremy: Okay. [00:26:11] Paul: Yeah. This has jammed is up pretty bad. Um, because I think everybody can, everybody pretty strongly agrees that ActivityPub is federation, right? and ActivityPub kind of models itself pretty similarly to email in a way, like the metaphors they use is that there's inboxes and outboxes and, and every ActivityPub server they're standing up the full vertical stack. [00:26:37] They set up, the primary hosting, the views of the data that's happening there. the interface for the application, all of it, pretty traditional, like close service, but then they're kind of using the perimeter. they're making that permeable by sending, exchanging, essentially mailing records to each other, right? [00:26:54] That's their kind of logic of how that works. And that's pretty much in line with, I think, what most people think of with Federation. Whereas what we're doing isn't like that we've cut, instead of having a bunch of vertical stacks communicating horizontally with each other, we kind of sliced in the other direction. [00:27:09] We sliced horizontally into, this microservices mesh and have all the different, like a total mix and match of different microservices between different operators. Is that federation? I don't know. Right. we tried to invent a term, didn't really work, you know, At the moment, we just kind of don't worry about it that much, see what happens, see what the world sort of has to say to us about it. [00:27:36] and beyond that, I don't know. [00:27:42] Jeremy: I think people probably are thinking of something like, say, a Mastodon instance when you're, when you're talking about everything being included, The webpage where you view the posts, the Postgres database that's keeping the messages. [00:28:00] And that same instance it's responsible for basically everything. [00:28:06] Paul: mm-Hmm [00:28:06] Jeremy: And I believe what you're saying is that the difference with, the authenticated transfer protocol, is that the [00:28:15] Paul: AT Protocol, Yep. [00:28:17] Jeremy: And the difference there is that you've, at the protocol level, you've split it up into the data itself, which can be validated completely separately from other parts of the system. [00:28:31] You could have the JSON files on your hard drive and somebody else can have that same JSON file and they would know that who the user is and that these are real things that user posted. That's like a separate part. And then the relay component that looks for all these different repositories that has people's data, that can also be its own independent thing where its job is just to output events. [00:29:04] And that can exist just by itself. It doesn't need the application part, the, the user facing part, it can just be this event stream on itself. and that's the part where it sounds like you can make decisions on who to, um, collect data from. I guess you have to agree that somebody can connect to you and get the users from your data repositories. [00:29:32] And likewise, other people that run relays, they also have to agree to let you pull the users from theirs. [00:29:38] Paul: Yeah, that's right. Yeah. [00:29:41] Jeremy: And so I think the Mastodon example makes sense. And, but I wonder if the underlying ActivityPub protocol forces you to use it in that way, in like a whole full application that talks to another full application. [00:29:55] Or is it more like that's just how people tend to use it and it's not necessarily a characteristic of the protocol. [00:30:02] Paul: Yeah, that's a good question actually. so, you know, generally what I would say is pretty core to the protocol is the expectations about how the services interact with each other. So the mailbox metaphor that's used in ActivityPub, that design, if I reply to you, I'll update my, local database with what I did, and then I'll send a message over to your server saying, Hey, by the way, add this reply. [00:30:34] I did this. And that's how they find out about things. That's how they find out about activity outside of their network. that's the part that as long as you're doing ActivityPub, I suspect you're gonna see reliably happening. That's that, I can say for sure that's a pretty tight requirement. [00:30:50] That's ActivityPub. If you wanted to split it up the way we're talking about, you could, I don't know, I don't know if you necessarily would want to. Because I don't know. That's actually, I think I'd have to dig into their stack a little bit more to see how meaningful that would be. I do know that there's some talk of introducing a similar kind of an aggregation method into the ActivityPub world which I believe they're also calling a relay and to make things even more complicated. [00:31:23] And NOSTR has a concept of a relay. So these are three different protocols that are using this term. I think you could do essentially what a search engine does on any of these things. You could go crawling around for the data, pull them into a fire hose, and then, tap into that aggregation to produce, bigger views of the network. [00:31:41] So that principle can certainly apply anywhere. AT Protocol, I think it's a little bit, we, we focused in so hard from that on that from the get go, we focus really hard on making sure that this, the data is, signed at rest. That's why it's called the authenticated transfer protocol. And that's a nice advantage to have when you're running a relay like this because it means that you don't have to trust the relay. [00:32:08] Like generally speaking, when I look at results from Google, you know, I'm trusting pretty well that they're accurately reflecting what's on the website, which is fine. You know, there's, that's not actually a huge risk or anything. But whenever you're trying to build entire applications and you're using somebody else's relay, you could really run into things where they say like, oh, you know what Paul tweeted the other day, you know, I hate dogs. [00:32:28] They're like, no, I didn't. That's a lie, right? You just sneak in Little lies like that over a while, it becomes a problem. So having the signatures on the data is pretty important. You know, if you're gonna be trying to get people to cooperate, uh, you gotta manage the trust model. I know that ActivityPub does have mechanisms for signed records. Issuers with ActivityPub identifiers [00:32:44] Paul: I don't know how deep they go if they could fully replace that, that utility. and then Mastodon ActivityPub, they also use a different identifier system that they're actually taking a look at DIDs um, right now, I don't know what's gonna happen there. We're, we're totally on board to, you know, give any kind of insight that we got working on 'em. [00:33:06] But at, at the moment, they use I think it's WebFinger based identifiers they look like emails. So you got host names in there and those identifiers are being used in the data records. So you don't get that continuous identifier. They actually do have to do that hey, I moved update your records sort of thing. [00:33:28] And that causes it to, I mean, it works like decently well, but not as well as it could. They got us to the point where it moves your profile over and you update all the folks that were following you so they can update their follow records, but your posts, they're not coming right, because that's too far into that mesh of interlinking records. [00:33:48] There's just no chance. So that's kind of the upper limit on that, it's a different set of choices and trade-offs. You're always kind of asking like, how important is the migration? Does that work out? Anyway, now I'm just kind of digging into differences between the two here. Issues with an identifier that changes and updating old records [00:34:07] Jeremy: So you were saying that with ActivityPub, all of the instances need to be notified that you've changed your identifier but then all of the messages that they had already received. They don't point to the new identifier somehow. [00:34:24] Paul: Yeah. You run into basically just the practicalities of actual engineering with that is what happens, right? Because if you imagine you got a multimillion user social network. They got all their posts. Maybe the user has like, let's say a thousand posts and 10,000 likes. And that, activity can range back three years. [00:34:48] Let's say they changed their identifier, and now you need to change the identifier of all those records. If you're in a traditional system that's already a tall order, you're going back and rewriting a ton of indexes, Anytime somebody replied to you, they have these links to your posts, they're now, you've gotta update the identifiers on all of those things. [00:35:11] You could end up with a pretty significant explosion of rewrites that would have to occur. Now that's, that's tough. If you're in a centralized model. If you're in a decentralized one, it's pretty much impossible because you're now, when you notify all the other servers like, Hey, this, this changed. How successful are all of them at actually updating that, that those, those pointers, it's a good chance that there's things are gonna fall out of correctness. that's just a reality of it. And if, so, if you've got a, if you've got a mutable identifier, you're in trouble for migrations. So the DID is meant to keep it permanent and that ends up being the anchoring point. If you lose control of your DID well, that's it. Managing signing keys by server, paper key reset [00:35:52] Paul: Your, your account's done. We took some pretty traditional approaches to that, uh, where the signing keys get managed by your hosting server instead of like trying to, this may seem like really obvious, but if you're from the decentralization community, we spend a lot of time with blockchains, like, Hey, how do we have the users hold onto their keys? [00:36:15] You know, and the tooling on that is getting better for what it's worth. We're starting to see a lot better key pair management in like Apple's ecosystem and Google's ecosystem, but it's still in the range of like, nah, people lose their keys, you know? So having the servers manage those is important. [00:36:33] Then we have ways of exporting paper keys so that you could kind of adversarially migrate if you wanted to. That was in the early spec we wanted to make sure that this portability idea works, that you can always migrate your accounts so you can export a paper key that can override. [00:36:48] And that was how we figured that out. Like, okay, yeah, we don't have to have everything getting signed by keys that are on the user's devices. We just need these master backup keys that can say, you know what? I'm done with that host. No matter what they say, I'm overriding what they, what they think. and that's how we squared that one. [00:37:06] Jeremy: So it seems like one of the big differences with account migration is that with ActivityPub, when you move to another instance, you have to actually change your identifier. [00:37:20] And with the AT protocol you're actually not allowed to ever change that identifier. And maybe what you're changing is just you have say, some kind of a lookup, like you were saying, you could use a domain name to look that up, get a reference to your decentralized identifier, but your decentralized identifier it can never change. [00:37:47] Paul: It, it, it can't change. Yeah. And it shouldn't need to, you know what I mean? It's really a total disaster kind of situation if that happens. So, you know that it's designed to make sure that doesn't happen in the applications. We use these domain name handles to, to identify folks. And you can change those anytime you want because that's really just a user facing thing. [00:38:09] You know, then in practice what you see pretty often is that you may, if you change hosts, if you're using, we, we give some domains to folks, you know, 'cause like not everybody has their own domain. A lot of people do actually, to our surprise, people actually kind of enjoy doing that. But, a lot of folks are just using like paul.bsky.social as their handle. [00:38:29] And so if you migrated off of that, you probably lose that. Like your, so your handle's gonna change, but you're not losing the followers and stuff. 'cause the internal system isn't using paul.bsky.social, it's using that DID and that DID stays the same. Benefits of domain names, trust signal [00:38:42] Jeremy: Yeah. I thought that was interesting about using the domain names, because when you like you have a lot of users, everybody's got their own sub-domain. You could have however many millions of users. Does that become, does that become an issue at some point? [00:39:00] Paul: Well, it's a funny thing. I mean like the number of users, like that's not really a problem 'cause you run into the same kind of namespace crowding problem that any service is gonna have, right? Like if you just take the subdomain part of it, like the name Paul, like yeah, only, you only get to have one paul.bsky.social. [00:39:15] so that part of like, in terms of the number of users, that part's fine I guess. Uh, as fine as ever. where gets more interesting, of course is like, really kind of around the usability questions. For one, it's, it's not exactly the prettiest to always have that B sky.social in there. If we, if we thought we, if we had some kind of solution to that, we would use it. [00:39:35] But like the reality is that, you know, now we're, we've committed to the domain name approach and some folks, you know, they kind of like, ah, that's a little bit ugly. And we're like, yeah that's life. I guess the plus side though is that you can actually use like TLD the domain. It's like on pfrazee.com. [00:39:53] that starts to get more fun. it can actually act as a pretty good trust signal in certain scenarios. for instance, well-known domain names like nytimes.com, strong authentication right there, we don't even need a blue check for it. Uh, similarly the .gov, domain name space is tightly regulated. [00:40:14] So you actually get a really strong signal out of that. Senator Wyden is one of our users and so he's, I think it's wyden.senate.gov and same thing, strong, you know, strong identity signal right there. So that's actually a really nice upside. So that's like positives, negatives. [00:40:32] That trust signal only works so far. If somebody were to make pfrazee.net, then that can be a bit confusing. People may not be paying attention to .com vs .net, so it's not, I don't wanna give the impression that, ah, we've solved blue checks. It's a complicated and multifaceted situation, but, it's got some juice. [00:40:54] It's also kinda nice too, 'cause a lot of folks that are doing social, they're, they've got other stuff that they're trying to promote, you know? I'm pretty sure that, uh, nytimes would love it if you went to their website. And so tying it to their online presence so directly like that is a really nice kind of feature of it. [00:41:15] And tells a I think a good story about what we're trying to do with an open internet where, yeah, everybody has their space on the internet where they can do whatever they want on that. And that's, and then thethese social profiles, it's that presence showing up in a shared space. It's all kind of part of the same thing. [00:41:34] And that that feels like a nice kind of thing to be chasing, you know? And it also kind of speaks well to the naming worked out for us. We chose AT Protocol as a name. You know, we back acronymed our way into that one. 'cause it was a @ simple sort of thing. But like, it actually ended up really reflecting the biggest part of it, which is that it's about putting people's identities at the front, you know, and make kind of promoting everybody from a second class identity that's underneath Twitter or Facebook or something like that. [00:42:03] Up into. Nope, you're freestanding. You exist as a person independently. Which is what a lot of it's about. [00:42:12] Jeremy: Yeah, I think just in general, not necessarily just for bluesky, if people had more of an interest in getting their own domain, that would be pretty cool if people could tie more of that to something you basically own, right? [00:42:29] I mean, I guess you're leasing it from ICANN or whatever, but, [00:42:33] yeah, rather than everybody having an @Gmail, Outlook or whatever they could actually have something unique that they control more or less. [00:42:43] Paul: Yeah. And we, we actually have a little experimental service for registering domain names that we haven't integrated into the app yet because we just kind of wanted to test it out and, and kind of see what that appetite is for folks to register domain names way higher than you'd think we did that early on. [00:43:01] You know, it's funny when you're coming from decentralization is like an activist space, right? Like it's a group of people trying to change how this tech works. And sometimes you're trying to parse between what might come off as a fascination of technologists compared to what people actually care about. [00:43:20] And it varies, you know, the domain name thing to a surprising degree, folks really got into that. We saw people picking that up almost straight away. More so than certainly we ever predicted. And I think that's just 'cause I guess it speaks to something that people really get about the internet at this point. [00:43:39] Which is great. We did a couple of other things that are similar and we saw varied levels of adoption on them. We had similar kinds of user facing, opening up of the system with algorithms and with moderation. And those have both been pretty interesting in and of themselves. Custom feed algorithms [00:43:58] Paul: So with algorithms, what we did was we set that up so that anybody can create a new feed algorithm. And this was kind of one of the big things that you run into whenever you use the app. If you wanted to create a new kind of for you feed you can set up a service somewhere that's gonna tap into that fire hose, right? [00:44:18] And then all it needs to do is serve a JSON endpoint. That's just a list of URLs, but like, here's what should be in that feed. And then the bluesky app will pick that up and, and send that, hydrate in the content of the posts and show that to folks. I wanna say this is a bit of a misleading number and I'll explain why but I think there's about 35,000 of these feeds that have been created. [00:44:42] Now, the reason it's little misleading is that, I mean, not significantly, but it's not everybody went, sat down in their IDE and wrote these things. Essentially one of our users created, actually multiple of our users made little platforms for building these feeds, which is awesome. That's the kinda thing you wanna see because we haven't gotten around to it. [00:44:57] Our app still doesn't give you a way to make these things. But they did. And so lots of, you know, there it is. Cool. Like, one, one person made a kind of a combinatorial logic thing that's like visual almost like scratch, it's like, so if it has this hashtag and includes these users, but not those users, and you're kind of arranging these blocks and that constructs the feed and then probably publish it on your profile and then folks can use it, you know? [00:45:18] And um, so that has been I would say fairly successful. Except, we had one group of hackers do put in a real effort to make a replacement for you feed, like magic algorithmic feed kind of thing. And then they kind of kept up going for a while and then ended up giving up on it. Most of what we see are actually kind of weird niche use cases for feeds. [00:45:44] You get straightforward ones, like content oriented ones like a cat feed, politics feed, things like that. It's great, some of those are using ML detection, so like the cat feed is ML detection, so sometimes you get like a beaver in there, but most of the time it's a cat. And then we got some ones that are kind of a funny, like change in the dynamic of freshness. [00:46:05] So, uh, or or selection criteria, things that you wouldn't normally see. Um, but because they can do whatever they want, you know, they try it out. So like the quiet posters ended up being a pretty successful one. And that one just shows people you're following that don't post that often when they do just those folks. [00:46:21] It ended up being, I use that one all the time because yeah, like they get lost in the noise. So it's like a way to keep up with them. Custom moderation and labeling [00:46:29] Paul: The moderation one, that one's a a real interesting situation. What we did there essentially we wanted to make sure that the moderation system was capable of operating across different apps so that they can share their work, so to speak. [00:46:43] And so we created what we call labeling. And labeling is a metadata layer that exists over the network. Doesn't actually live in the normal data repositories. It uses a completely different synchronization because a lot of these labels are getting produced. It's just one of those things where the engineering characteristics of the labels is just too different from the rest of the system. [00:47:02] So we created a separate synchronization for this, and it's really kind of straightforward. It's, here's a URL and here's a string saying something like NSFW or Gore, or you know, whatever. then those get merged onto the records brought down by the client and then the client, you know, based on the user's preferences. [00:47:21] We'll put like warning screens up, hide it, stuff like that. So yeah, these label streams can then, you know, anybody that's running a moderation service can, you know, are publishing these things and so anybody can subscribe to 'em. And you get that kind of collaborative thing we're always trying to do with this. [00:47:34] And we had some users set up moderation services and so then as an end user you find it, it looks like a profile in the app and you subscribe to it and you configure it and off you go. That one has had probably the least amount of adoption throughout all of 'em. It's you know, moderation. [00:47:53] It's a sticky topic as you can imagine, challenging for folks. These moderation services, they do receive reports, you know, like whenever I'm reporting a post, I choose from all my moderation services who I wanna report this to. what has ended up happening more than being used to actually filter out like subjective stuff is more kind of like either algorithmic systems or what you might call informational. [00:48:21] So the algorithmic ones are like, one of the more popular ones is a thing that's looking for, posts from other social networks. Like this screenshot of a Reddit post or a Twitter post or a Facebook post. Because, which you're kinda like, why, you know, but the thing is some folks just get really tired of seeing screenshots from the other networks. [00:48:40] 'cause often it's like, look what this person said. Can you believe it? You know, it's like, ah. Okay, I've had enough. So one of our users aendra made a moderate service that just runs an ML that detects it, labels it, and then folks that are tired of it, they subscribe to it and they're just hide it, you know? [00:48:57] And so it's like a smart filter kind of thing that they're doing. you know, hypothetically you could do that for things like spiders, you know, like you've got arachniphobia, things like that. that's like a pretty straightforward, kind of automated way of doing it. Which takes a lot of the spice, you know, outta out of running moderation. [00:49:15] So that users have been like, yeah, yeah, okay, we can do that. [00:49:20] Those are user facing ways that we tried to surface the. Decentralized principle, right? And make take advantage of how this whole architecture can have this kind of a pluggability into it. Users can self host now [00:49:33] Paul: But then really at the end of the day, kind of the important core part of it is those pieces we were talking about before, the hosting, the relay and the, the applications themselves, having those be swappable in completely. so we tend to think of those as kind of ranges of infrastructure into application and then into particular client side stuff. [00:49:56] So a lot of folks right now, for instance, they're making their own clients to the application and those clients are able to do customizations, add features, things like that, as you might expect, [00:50:05] but most of them are not running their own backend. They're just using our backend. But at any point, it's right there for you. You know, you can go ahead and, and clone that software and start running the backend. If you wanted to run your own relay, you could go ahead and go all the way to that point. [00:50:19] You know, if you wanna do your own hosting, you can go ahead and do that. Um, it's all there. It's really just kind of a how much effort your project really wants to take. That's the kind of systemically important part. That's the part that makes sure that the overall mission of de monopolizing, social media online, that's where that really gets enforced. [00:50:40] Jeremy: And so someone has their own data repository with their own users and their own relay. they can request that your relay collect the information from their own data repositories. And that's, that's how these connections get made. [00:50:58] Paul: Yeah. And, and we have a fair number of those already. Fair number of, we call those the self hosters right? And we got I wanna say 75 self hoster going right now, which is, you know, love to see that be more, but it's, really the folks that if you're running a service, you probably would end up doing that. [00:51:20] But the folks that are just doing it for themselves, it's kind of the, the nerdiest of the nerds over there doing that. 'cause it doesn't end up showing itself in the, in the application at all. Right? It's totally abstracted away. So it, that, that one's really about like, uh, measure your paranoia kind of thing. [00:51:36] Or if you're just proud of the self-hosting or, or curious, you know, that that's kind of where that sits at the moment. AT Protocol beyond bluesky [00:51:42] Jeremy: We haven't really touched on the fact that there's this underlying protocol and everything we've been discussing has been centered around the bluesky social network where you run your own, instance of the relay and the data repositories with the purpose of talking to bluesky, but the protocol itself is also intended to be used for other uses, right? [00:52:06] Paul: Yeah. It's generic. The data types are set up in a way that anybody can build new data types in the system. there's a couple that have already begun, uh, front page, which is kind of a hacker news clone. There's Smoke Signals, which is a events app. There's Blue Cast, which is like a Twitter spaces, clubhouse kind of thing. [00:52:29] Those are the folks that are kind of willing to trudge into the bleeding edge and deal with some of the rough edges there for pretty I think, obvious reasons. A lot of our work gets focused in on making sure that the bluesky app and that use case is working correctly. [00:52:43] But we are starting to round the corner on getting to a full kind of how to make alternative applications state. If you go to the atproto.com, there's a kind of a introductory tutorial where that actually shows that whole stack and how it's done. So it's getting pretty close. There's a couple of still things that we wanna finish up. [00:53:04] jeremy so in a way you can almost think of it as having an eventually consistent data store on the network, You can make a traditional web application with a relational database, and the source of truth can actually be wherever that data repository is stored on the network. [00:53:24] paul Yeah, that's exactly, it is an eventually consistent system. That's exactly right. The source of truth is there, is their data repo. And that relational database that you might be using, I think the best way to think about it is like secondary indexes or computed indexes, right? They, reflect the source of truth. [00:53:43] Paul: This is getting kind of grandiose. I don't tend to poses in these terms, but it is almost like we're trying to have an OS layer at a protocol level. It's like having your own [00:53:54] Network wide database or network-wide file system, you know, these are the kind of facilities you expect out of a platform like an os And so the hope would be that this ends up getting that usage outside of just the initial social, uh, app, like what we're doing here. [00:54:12] If it doesn't end up working out that way, if this ends up, you know, good for the Twitter style use case, the other one's not so much, and that's fine too. You know, that's, that's our initial goal, but we, we wanted to make sure to build it in a way that like, yeah, there's evolve ability to, it keeps, it, keeps it, make sure that you're getting kinda the most utility you can out of it. Peer-to-peer and the difficulty of federated queries [00:54:30] Jeremy: Yeah, I can see some of the parallels to some of the decentralized stuff that I, I suppose people are still working on, but more on the peer-to-peer side, where the idea was that I can have a network host this data. but, and in this case it's a network of maybe larger providers where they could host a bunch of people's data versus just straight peer to peer where everybody has to have a piece of it. [00:54:57] And it seems like your angle there was really the scalability part. [00:55:02] Paul: It was the scalability part. And there's great work happening in peer-to-peer. There's a lot of advances on it that are still happening. I think really the limiter that you run into is running queries against aggregations of data. Because you can get the network, you know, BitTorrent sort of proved that you can do distributed open horizontal scaling of hosting. [00:55:29] You know, that basic idea of, hey, everybody's got a piece and you sync it from all these different places. We know you can do things like that. What nobody's been able to really get into a good place is running, queries across large data sets. In the model like that, there's been some research in what is, what's called federated queries, which is where you're sending a query to multiple different nodes and asking them to fulfill as much of it as they can and then collating the results back. But it didn't work that well. That's still kind of an open question and until that is in a place where it can like reliably work and at very large scales, you're just gonna need a big database somewhere that does give the properties that you need. You need these big indexes. And once we were pretty sure of that requirement, then from there you start asking, all right, what else about the system [00:56:29] Could we make easier if we just apply some more traditional techniques and merge that in with the peer-to-peer ideas? And so key hosting, that's an obvious one. You know, availability, let's just have a server. It's no big deal. But you're trying to, you're trying to make as much of them dumb as possible. [00:56:47] So that they have that easy replaceability. Moderation challenges [00:56:51] Jeremy: Earlier you were talking a a little bit about the moderation tools that people could build themselves. There was some process where people could label posts and then build their own software to determine what a feed should show per a person. [00:57:07] Paul: Mm-Hmm [00:57:07] Jeremy: But, but I think before that layer for the platform itself, there's a base level of moderation that has to happen. [00:57:19] Paul: yeah. [00:57:20] Jeremy: And I wonder if you could speak to, as the app has grown, how that's handled. [00:57:26] Paul: Yeah. the, you gotta take some requirements in moderation pretty seriously to start. And with decentralization. It sometimes that gets a little bit dropped. You need to have systems that can deal with questions about CSAM. So you got those big questions you gotta answer and then you got stuff that's more in the line of like, alright, what makes a good platform? [00:57:54] What kind of guarantees are we trying to give there? So just not legal concerns, but you know, good product experience concerns. That's something we're in the realm of like spam and and abusive behavior and things like that. And then you get into even more fine grain of like what is a person's subjective preference and how can they kind of make their thing better? [00:58:15] And so you get a kind of a telescoping level of concerns from the really big, the legal sort of concerns. And then the really small subjective preference kind of concerns. And that actually that telescoping maps really closely to the design of the system as well. Where the further you get up in the kind of the, in that legal concern territory, you're now in core infrastructure. [00:58:39] And then you go from infrastructure, which is the relay down into the application, which is kind of a platform and then down into the client. And that's where we're having those labelers apply. And each of them, as you kind of move closer to infrastructure, the importance of the decision gets bigger too. [00:58:56] So you're trying to do just legal concerns with the relay right? Stuff that you objectively can, everybody's in agreement like Yeah, yeah, yeah. You know, no bigs don't include that. The reason is that at the relay level, you're anybody that's using your relay, they depend on the decisions you're making, that sort of selection you're doing, any filtering you're doing, they don't get a choice after that. [00:59:19] So you wanna try to keep that focus really on legal concerns and doing that well. so that applications that are downstream of it can, can make their choices. The applications themselves, you know, somebody can run a parallel I guess you could call it like a parallel platform, so we got bluesky doing the microblogging use case, other people can make an application doing the microblogging use case. So there's, there's choice that users can easily switch, easily enough switch between, it's still a big choice. [00:59:50] So we're operating that in many ways. Like any other app nowadays might do it. You've got policies, you know, for what's acceptable on the network. you're still trying to keep that to be as, you know, objective as possible, make it fair, things like that. You want folks to trust your T&S team. Uh, but from the kind of systemic decentralization question, you get to be a little bit more opinionated. [01:00:13] Down all the way into the client with that labeling system where you can, you know, this is individuals turning on and off preferences. You can be as opinionated as you want on that letter. And that's how we have basically approached this. And in a lot of ways, it really just comes down to, in the day to day, you're the moderation, the volume of moderation tasks is huge. [01:00:40] You don't actually have high stakes moderation decisions most of the time. Most of 'em are you know pretty straightforward. Shouldn't have done that. That's gotta go. You get a couple every once in a while that are a little spicier or a policy that's a little spicier. And it probably feels pretty common to end users, but that just speaks to how much moderation challenges how the volume of reports and problems that come through. [01:01:12] And we don't wanna make it so that the system is seized up, trying to decentralize itself. You know, it needs to be able to operate day to day. What you wanna make is, you know, back pressure, you know, uh, checks on that power so that if an application or a platform does really start to go down the wrong direction on moderation, then people can have this credible exit. [01:01:36] This way of saying, you know what, that's a problem. We're moving from here. And somebody else can come in with different policies that better fit people's people's expectations about what should be done at, at these levels. So yeah, it's not about taking away authority, it's about checking authority, you know, kind of a checks and balances mentality. [01:01:56] Jeremy: And high level, 'cause you saying how there's such a high volume of, of things that you know what it is, you'd know you wanna remove it, but there's just so much of it. So is there, do you have automated tools to label these things? Do you have a team of moderators? Do they have to understand all the different languages that are coming through your network? [01:02:20] Yes, yes, yes and yes. Yeah. You use every tool at your disposal to, to stay on top of it. cause you're trying to move as fast as you can, folks. The problems showing up, you know, the slower you are to respond to it, the, the more irritating it is to folks. Likewise, if you make a, a missed call, if somebody misunderstands what's happening, which believe me, is sometimes just figuring out what the heck is going on is hard. [01:02:52] Paul: People's beefs definitely surface up to the moderation misunderstanding or wrong application. Moderators make mistakes so you're trying to maintain a pretty quick turnaround on this stuff. That's tough. And you, especially when to move fast on some really upsetting content that can make its way through, again, illegal stuff, for instance, but more videos, stuff like that, you know, it's a real problem. [01:03:20] So yeah, you're gotta be using some automated systems as well. Clamping down on bot rings and spam. You know, you can imagine that's gotten a lot harder thanks to LLMs just doing text analysis by dumb statistics of what they're talking about that doesn't even work anymore. [01:03:41] 'cause the, the LLMs are capable of producing consistently varied responses while still achieving the same goal of plugging a online betting site of some kind, you know? So we do use kind of dumb heuristic systems for when it works, but boy, that won't work for much longer. [01:04:03] And we've already got cases where it's, oh boy, so the moderation's in a dynamic place to say the least right now with, with LLMs coming in, it was tough before and

On Bubble Trouble, we are never short of subject matter: from the metaverse, NFTs and Chinese real estate, to Silicon Valley Bank and er… that small issue of a former global powerhouse Credit Suisse. Remember them? Well our guest, Duncan Mavin, knows their story better than anyone, and he's documented them in the wonderfully titled Meltdown: Scandal, Sleaze and the Collapse of Credit Suisse. For more on Bubble Trouble, including transcripts of the show, visit us online at http://bubbletroublepodcast.comYou can learn more about Richard at https://www.linkedin.com/in/richard-kramer-16306b2/More on Will Page at: https://pivotaleconomics.com(Times below correspond to the episode without considering any inserted advertisements.)Credit Suisse: A Rolling Crisis in Banking ScandalsIn this episode of Bubble Trouble, hosts Will Page and Richard Kramer discuss the collapse of Credit Suisse with journalist and author Duncan Maven. They delve into Maven's book 'Meltdown: Scandal, Sleaze, and the Collapse of Credit Suisse,' exploring the myriad of crises that plagued the bank. They touch on scandals ranging from rogue traders and sanctions busting to laundering Nazi gold and funding corrupt projects in Mozambique. The conversation also highlights the rapid acquisition of Credit Suisse by UBS over a tense and decisive weekend. Duncan Maven provides insights into the bank's culture, the broader implications for the banking sector, and why people should care about the ethics in banking. The episode concludes with the discussion of warning signs (or smoke signals) that indicate deeper issues within financial institutions.00:00 Introduction01:00 Part One01:09 Guest Introduction: Duncan Maven02:31 The Rise and Fall of Credit Suisse03:32 The Impact of White Collar Crime05:08 Cultural Issues at Credit Suisse09:56 Historical Context of Swiss Banking15:21 The Mozambique Scandal19:49 The Role of Social Media in Credit Suisse's Collapse23:00 The Bulgarian Mafia and Credit Suisse Scandal23:47 Part Two23:54 The Collapse of Credit Suisse24:32 UBS Absorbs Credit Suisse26:41 The Aftermath and Lingering Scandals28:57 The Swiss Financial Crisis32:58 The Future of Swiss Banking40:05 Reception of the Book42:08 Smoke Signals and Final Thoughts46:37 Credits Hosted on Acast. See acast.com/privacy for more information.

Get free access to The Fire Time Magazine every month by going to https://www.itsfiretime.com/subscribe —— Order the latest issue of the printed Fire Time Journal: https://itsfiretime.com/journal. Support The Fire Time Podcast financially: https://www.patreon.com/itsfiretime. Become an Advertising Partner: https://www.itsfiretime.com/advertising

In this episode, Mark Ridley and Andrew Maclaren explore the evolution and challenges of virtual teams. Inspired by Amazon CEO Andy Jassy's recent call for employees to return to the office, our hosts discuss what defines a virtual team, the importance of trust and shared context, and how physical environments impact team dynamics. Historical examples, from Byzantine smoke signals to Apollo missions, illustrate that remote teamwork has been around longer than we may think. They also discuss what defines a virtual team, the importance of trust and shared context, and how physical environments impact team dynamics. Topics include:Andy Jassy's memo to Amazon employeesThe definition and variations of virtual teamsHistorical examples of remote coordinationChallenges in building trust and common ground remotelyThe impact of shared environments on teamworkCommunication challenges and the importance of consistencyComing Up in Part 2: Andrew and Mark will explore more on communication strategies, protocols, and actionable recommendations for enhancing virtual team collaboration.Chapters00:00 Virtual Teams Part 100:43 Intro02:37 Andy Jassy's message to Amazon Staff04:30 Executive Comms and the Return to Office message07:47 Amazon Web Services & Stanford article on hybrid working10:40 Defining a virtual team21:43 The virtual team on Apollo 726:49 Trust in teams34:22 Common Ground in teams39:25 Rhythms of the environment42:37 Next EpisodeThanks for listening!Music by Tom Farrington

Cultural Advisor Bobby Mercier joined the Smoke Signals podcast to reflect on the creation of the Grand Ronde Tribe's achaf-hammi Plankhouse fifteen years later. Mercier goes down memory lane with photos from the Smoke Signals archive documenting the process of milling and building the plankhouse back in 2008. The achaf-hammi Plankhouse's 15th birthday celebration will be held in at the plankhouse on Saturday, Oct. 19 with doors opening at 4 p.m.

What if the answers to the climate crisis are here? In this special Indigenous Peoples' Day episode, host Frank Oscar Weaver speaks with Indigenous leaders from across the world who are on the front lines of the fight to protect their lands and our planet. Impirita, an Indigenous leader from Peru, shares the harsh reality her community faces as industrial mining contaminates rivers that have provided life and sustenance for generations. “All these rivers are contaminated, not just by sewage, but also by mining activities,” – Impirita Frank reflects on the wisdom of Indigenous teachings, like those of Dr. Don Dexter from the Klamath Tribes, who explains how removing Indigenous people from their lands disrupts a natural cycle that keeps ecosystems in balance. Beth Tupara-Katene from Aotearoa (New Zealand) reminds us of the deep responsibility of reciprocity between people and nature, and the urgent need to protect sacred lands. From the ancient mounds of the Tocobaga tribe in Florida, believed to protect the region from hurricanes, to the laws that silence the words "climate change," this episode explores the modern challenges Indigenous communities face. These storms and disasters are not merely natural—they are #UnnaturalDisasters, fueled by climate pollution.  

We always try to flag the smoke signals of mischievous market behaviour that gets society and stock portfolios into trouble. Are we about to get fooled again by the hype and hysteria surrounding the poster child Open AI? Or maybe, just maybe, it's worth joining us for 30 minutes to find what really sits behind a 150bn valuation and ask whether beauty is in the eye of the beholder?For more on Bubble Trouble, including transcripts of the show, visit us online at http://bubbletroublepodcast.comYou can learn more about Richard at https://www.linkedin.com/in/richard-kramer-16306b2/More on Will Page at: https://pivotaleconomics.com(Times below correspond to the episode without considering any inserted advertisements.)In the latest episode of Bubble Trouble, co-hosts Richard Kramer and Will Page dive into the hype surrounding OpenAI, now valued at $150 billion. They examine the risks of market hype and hysteria behind this soaring valuation, discussing the broader implications for society and the tech industry. The episode explores the nuances of company valuations, comparing public versus private market insights and the lack of transparency in the private sector. With references to past tech bubbles, the hosts analyze the potential conflicts of interest among investors and question the sustainability of current trajectories in tech valuations. As they await the next bubble to burst, Kramer and Page emphasize the importance of scrutinizing underlying business fundamentals in an era of outsized market valuations.00:00 Introduction00:49 Part One01:04 The AI Hype and OpenAI's Valuation03:25 Understanding Company Valuations06:32 Public vs Private Market Valuations10:56 The Transparency Challenge in Tech15:26 Reflecting on Past Episodes and Lessons21:12 Part Two21:49 The Role of Central Banks in Market Bubbles25:32 Exploring OpenAI's Valuation and Market Dynamics36:09 Smoke Signals and Future Predictions43:46 Credits Hosted on Acast. See acast.com/privacy for more information.

Father Hudgins' homily: We Saw Your Smoke Signal

Twenty-five years after playing Little Victor in the 1998 coming-of-age drama “Smoke Signals,” Cody Lightning is all grown up and back with his directorial debut. It's a mockumentary, titled “Hey, Viktor!,” which follows a fictionalized version of himself trying to make a sequel to the cult classic film he acted in as a child. Cody joins Tom from Edmonton to talk about his gritty new Indigenous comedy, how his idea for the film began as a running joke with his friends, and how he looks back on his time as a child actor.

Smoke Signals has reached cult status in NDN Country, and now there is a sequel (sorta). Comic genius Cody Lightning, known as Young Victor, writes, directs and stars in this epic comedy about getting the cast of Smoke Signals together again to reclaim his status in the acting world. Our hosts discuss if NDN Country is ready for this mockumentary/gross-out comedy.

Damien and Ali get In The Conversation about Labor Day, liquors to avoid, and grilling in the winter time. Twitter.com/dlemoncomedy // Twitter.com/mrmuhammad Keep up with the conversation on Instagram www.instagram.com/intheconversation

So let's look forward and prepare you for the next big sexy blockbuster tech IPO, you've read all about it - that's right. Reddit is going to ring the bell.For more on Bubble Trouble, including transcripts of the show, visit us online at http://bubbletroublepodcast.comYou can learn more about Richard at https://www.linkedin.com/in/richard-kramer-16306b2/More on Will Page at: https://pivotaleconomics.com(Times below correspond to the episode without considering any inserted advertisements.)Reddit's IPO Adventure: A Deep Dive into Valuations, Trends, and Future ProspectsIn this episode of Bubble Trouble, hosts Richard Kramer and Will Page dissect Reddit's impending IPO, examining its valuation, user base, and revenue streams. The podcast begins with a discussion on the evolution of Reddit and its business model, focusing on the challenges it faces as a business primarily driven by advertising revenue in a competitive digital advertising landscape. Kramer and Page delve into the nuances of Reddit's user engagement and its niche position in the internet culture, juxtaposing it against giants like Meta and Google. They critically analyze the hype surrounding tech IPOs, emphasizing Reddit's $800 million revenue and its struggle to become profitable amidst a sprawling digital advertising world. The episode also covers the broader implications of down rounds and the valuation bubbles that tech companies often face. Through expert insights and a candid conversation, the episode offers a comprehensive view on Reddit's IPO, the tech industry's valuation practices, and what the future holds for user-generated content platforms.00:00 Welcome to Bubble Trouble: DeepFakes and Bubbles01:02 Part One01:06 The Fascinating Shift from Hong Kong to Singapore02:52 Reddit's Upcoming IPO: A Deep Dive03:25 Exploring Reddit's Niche and Financials06:04 The Cultural Impact and Controversies of Reddit08:58 Reddit IPO Strategies and User Dynamics10:43 Inside Reddit: Culture, Compliance, and Future Prospects16:00 Part Two16:00 South by Southwest Festival Insights20:04 Back to Reddit: IPO Details and Expectations21:22 Technical Difficulties and Starting Off21:24 Exploring Down Rounds: A Deep Dive23:48 The Reality of Valuations and Market Corrections24:42 Tech Companies' Valuations Post-Pandemic25:41 Reddit's Revenue Diversification and Data Deals27:15 The Creator Economy: Expectations vs. Reality29:48 Reddit's IPO: A Case Study in Market Dynamics34:49 Smoke Signals for Future IPOs38:21 Reflecting on Reddit and the IPO Landscape40:20 Credits Hosted on Acast. See acast.com/privacy for more information.

The miracle in the woods!

When the sun's out, there's nothing quite like a BBQ to tickle those taste buds. If you're a fan of a cook-out but you're bored of the same old flavors, then give Smoke Signals' new BBQ Legends a look! Learn more at https://smokesignalsweekly.beehiiv.com/p/bbq-styles-around-the-world Smoke Signals Weekly City: Winnipeg Address: Winnipeg, Manitoba Website: https://smokesignalsweekly.beehiiv.com Email: boknowscigars2@gmail.com

Interested in learning more about the Prohibition era? Check out Smoke Signals' new six-part newsletter series, “George Remus: From Pharmacist to King of the Bootleggers.” Go to https://smokesignalsweekly.beehiiv.com/p/george-remus-bootlegging-story to find out more. Smoke Signals Weekly City: Winnipeg Address: Winnipeg, Manitoba Website: https://smokesignalsweekly.beehiiv.com Email: boknowscigars2@gmail.com

Give it to the USofAMovie guys for once again accidentally stumbling into cultural relevance as we revisit 'Napoleon Dynamite' on it's 20th anniversary, discover new voices in the world of American movies with another indie movie, 'Smoke Signals' and then we all get swept up in the current of 'The River Wild' where Meryl Streep always comes first Learn more about your ad choices. Visit megaphone.fm/adchoices

Dr. John Delony joins me as we talk through the concept of anxiety as a smoke signal, indicating that something is amiss in our lives. He encourages individuals to face their discomfort and choose the hard path of growth and change (sound familiar?). He also highlights the significance of belief in something bigger than ourselves and the need to drive our own lives instead of trying to control others. Lastly, we discuss the importance of self-awareness and taking responsibility for our own actions in relationships. Learn more about Dr John here https://www.ramseysolutions.com/john-delony Takeaways Dr. John Deloney's journey into therapy and coaching was inspired by his father's work as a homicide detective and hostage negotiator. Anxiety is a smoke signal that something is amiss in our lives, and it is important to face our discomfort and choose the hard path of growth and change. Belief in something bigger than ourselves is crucial for managing anxiety and finding peace and clarity. It is important to drive our own lives and take responsibility for our own actions, rather than trying to control others. Self-awareness and recognizing our own part in relationships is essential for personal growth and healthy connections. On the Xtended Version ... In the XTD content, we continue the conversation with Dr John by looking further into how vulnerability and open communication are key to building strong and intimate relationships. Plus, it is important to embrace the mundane aspects of life and find joy in the everyday moments. Enjoy the show! Sponsors ... OneSKin: Get 15% off OneSkin with our code SMR at https://oneskin.co  #oneskinpod Honeylove: Get 20% OFF @honeylove by going to https://honeylove.com/SMR! #honeylovepod The post Anxiety As A Smoke Signal | Dr John Delony #680 first appeared on Sexy Marriage Radio.

What are the main causes of wildfires in wine country? Which two weather-based factors are the strongest predictors of the severity of wildfires each season? What impact do wildfires have on the taste of your wine, and why is it difficult to predict whether smoke-exposed grapes will, in fact, produce tainted wine? Should we, as consumers, be concerned about buying wines from regions which have experienced wildfires? Why does smoke taint intensify as a wine ages? How can wineries mitigate the risk of producing smoke-tainted wine? In this episode of the Unreserved Wine Talk podcast, I'm chatting with researcher Dr. Wes Zandberg. You can find the wines we discussed at https://www.nataliemaclean.com/winepicks   Highlights What sparked Wes' interest in winemaking and wine chemistry? Why are BC wineries at a disadvantage coming out of 2022 and 2023? What are the main causes of wildfires in British Columbia? How much damage was caused by the wildfires in late 2023 and why were they worse than in the past? Why did the wildfires start so early in 2024? Which two weather-based factors are the strongest predictors of the risk of wildfires each season? How does fire play an important role in the forest ecosystem? How do wildfires affect wine itself chemically? What is the economic impact of wildfires on the wine industry? Why is it challenging to predict smoke taint through analytical tools alone? How does yeast activity contribute to smoke taint in wine post-fermentation? Why does smoke taint show up differently in different wines despite the same level of exposure of the grapes? How can wineries mitigate the risk of producing smoke-tainted wine? Is there a health risk associated with wine made from smoke-exposed grapes? Why does smoke taint intensify with wine aging? Why does the perception of smoke taint become stronger with every sip? What are some similarities and differences between wildfire smoke exposure and the smoky aromas achieved with oak barrels? Are some grape varieties more susceptible to smoke taint than others? What are some of the main challenges in researching the effects of smoke exposure on wine? Were there differences between the wildfires in BC, California, and Australia wine country? Where is the current research focus for prevention and mitigation of smoke taint? How would routine testing of grapes in vineyards help researchers establish benchmarks for risk assessment? How could understanding more about the terroir of the air positively impact the wine industry?   Key Takeaways In 2021, Wes notes that the BC's Okanagan Valley experienced severe wildfires due to arson. The vast majority, though, of wildfires are started by lightning and human causes, both errors and malevolence. Wes observes that the quicker snow melts and evaporates, leaving drier conditions, the greater the risk of wildfires. This is exacerbated if seasonal rains are below average, especially in June and July. There isn't a chemical test to determine whether smoke-exposed grapes will actually produce smoke-tainted wines. Smoke taint also doesn't express itself in unfermented grapes, making it even harder to predict its impact on the wine.   About Wes Zandberg Before beginning his independent research career at The University of British Columbia (2015), Wes earned a PhD in chemistry at Simon Fraser University with Prof. B. Mario Pinto. Wes loved the rainy Fraser Valley so much that he remained at SFU, completing his post-doctoral research with Prof. David Vocadlo. This training instilled in Wes a fascination for glycoscience as well as a realization that the study of the structures/functions of carbohydrates (i.e. glycoscience) was—and still is—impeded by a dearth of suitable analytical tools and methods. Now, students in Wes' lab at devise glyco-analytical methods that actually work for real samples rather than off-the-shelf model systems.         To learn more, visit https://www.nataliemaclean.com/podcast.

Send us a Text Message.The conversation features an interview with Jonathan and Kiara Washington, owners of House of Smoke Barbecue LV. They discuss the importance of supporting small businesses, the history of House of Smoke Barbecue, and the family's involvement in the business. The conversation also includes a 'this or that' segment and a Las Vegas trivia question.TakeawaysSupporting small businesses is crucial for the local communityFamily involvement and teamwork are essential for the success of a family-owned businessConstructive criticism is valuable for business improvementSocial media presence is important for promoting and engaging with customersLas Vegas trivia and local knowledge can enhance the listener's understanding of the city's culture and historyOrder online here:HouseOfSmokeBBQLV (@hosbbqlv) • Instagram photos and videosChapters00:00Introduction and Community Support02:18The Importance of Supporting Small Businesses04:21Family Involvement in a Family-Owned Business27:49Las Vegas Trivia and Local KnowledgeSubscribe to Visit Vegas Places with Coyal Never miss an episode again!Plus get behind the scenes coverage with business owners and chefs.Have you thought about hosting your own podcast show? If so, I have provided links below to get you started in the right direction. Start with some gear that you already have, and a quiet space. Now you are officially ready.Riverside FM - provides quality recording and virtual capabilities for long distance guest.Access RiversideFM hereBuzzsprout - is hands down the easiest and best way to launch, promote, and track your podcast. Your show can be online and listed in all the major podcast directories (like Apple Podcasts, Spotify, Google Podcasts, and more) within minutes of finishing your recording.Access Buzzsprout HereShow music composed by: Dae One Visit Vegas Places with Coyal. Real Vegas, Real Topics, Real Business with Real Owners. Covering topics on economics, entrepreneurship, health, well-being and FOOD! Thank You for tuning in and make sure to VISIT VEGAS PLACES!Follow our social media platforms:https://www.instagram.com/visitvegasplaces/https://www.youtube.com/c/CoyalHarrisonIIISupport the Show.

The boys have a lot to vent about communication in this episode, with the suggestion that maybe we shoul go back to sending smoke signals and messengers. --- Send in a voice message: https://podcasters.spotify.com/pod/show/innit-podcast2/message

In the cozy corners of our homes, where wagging tails and loyal companionship abound, secondhand smoke lingers as an unseen threat to our faithful canine friends. As some puff away on cigarettes and exhale plumes of toxic fumes, the innocent noses of our older dogs are unknowingly subjected to a barrage of harmful chemicals. The alarming reality is that while we may be aware of the dangers posed by secondhand smoke to human health, the risks it poses for our aging furry companions often go unnoticed.Imagine this: your beloved senior dog snuggled at your feet as you relax with a cigarette in hand. While you may find solace in their company, each breath they take in this shared space is tainted with harmful carcinogens and toxins present in secondhand smoke. This seemingly innocuous act could have far-reaching consequences on their health and well-being.Support the Show.You can find Woody's Place Senior German Shepherd Sanctuary online at:www.wpsgss.orghttps://www.facebook.com/woodysplacesgsshttps://www.instagram.com/wpsgss/https://www.youtube.com/channel/UC7Tb1hKnOWEamQstkqAxEygWe would LOVE it if you could leave a thumbs-up or comment! Please and Thank you! You can support our podcast by going to http://www.patreon.com/LifeWithOldDogsEvery little bit helps, and your support is what keeps the #Lifewitholddogs podcast going.

In this insightful episode of "Taco Bout Fertility Tuesday," Dr. Mark Amols unpacks the complex significance of FSH (Follicle Stimulating Hormone) levels within the realm of fertility treatments. Using vivid analogies such as smoke signals and buildings, Dr. Amols elucidates why the numbers on a lab report are just the beginning of understanding one's fertility health. Delve deep into the dynamics between FSH and estrogen, and learn why lowering FSH with estrogen might not actually improve your chances of conceiving.Dr. Amols challenges common misconceptions and provides a nuanced explanation of how FSH levels interact with ovarian reserve, response to medication, and ultimately, egg quality. This episode not only clarifies the biological feedback loops essential for accurate diagnosis but also emphasizes the difference between association and causation in fertility metrics.Listeners will come away with a clearer understanding of how hormonal levels reflect underlying reproductive conditions, rather than dictating them. Whether you're navigating your own fertility journey or supporting someone else's, Dr. Amols offers essential knowledge to help demystify the process, ensuring that patients and their supporters are well-informed and empowered.Tune in to "Smoke Signals: Decoding What FSH Levels Truly Signify in Fertility" for an in-depth discussion that transcends the numbers, offering hope and clarity to those facing fertility challenges. Don't miss this opportunity to change the way you think about fertility and hormonal health.Thanks for tuning in to another episode of 'Taco Bout Fertility Tuesday' with Dr. Mark Amols. If you found this episode insightful, please share it with friends and family who might benefit from our discussion. Remember, your feedback is invaluable to us – leave us a review on Apple Podcasts, Spotify, or your preferred listening platform. Stay connected with us for updates and fertility tips – follow us on Facebook. For more resources and information, visit our website at www.NewDirectionFertility.com. Have a question or a topic you'd like us to cover? We'd love to hear from you! Reach out to us at TBFT@NewDirectionFertility.com. Join us next Tuesday for more discussions on fertility, where we blend medical expertise with a touch of humor to make complex topics accessible and engaging. Until then, keep the conversation going and remember: understanding your fertility is a journey we're on together.

Cody Lightning played the role of young Viktor in the 1998 cult classic Smoke Signals. On Face to Face, he shares his journey to write, direct and star in Hey Viktor, a mockumentary about Cody's attempt to make the sequel, Smoke Signals 2: Still Smoking.

Founder and Executive Director of Diplo Foundation, Dr. Jovan Kurbalija, takes us on a journey from the past to the present and across civilizations to explore the interplay of technology and diplomacy. Diplomacy and technology are at the heart of Diplo's mission. Dr. Kurbalija emphasizes the importance of writing as a diplomatic tool and begins by telling us the story in the Sumerian poem “Enmerkar and the Lord of Aratta”, recounting how Enmerkar invents writing on clay tablets to relieve the messenger of having to remember the increasing number of messages with which he is charged. Jovan talks about the similarity of the Ancient Egyptian Amarna letters to today's diplomatic notes, the advanced messaging system of the Persians at the time of Cyrus the Great, how the Romans and Byzantines concealed information, the advances in technology during the Renaissance period and he highlights the themes of continuity and change all the way to present day. He also speaks about the impact of social media, AI, and our need to remain open to embracing technology in a smart way. Resources Diplo website: https://www.diplomacy.edu/ Kurbalija J. (2023) History of Diplomacy and Technology: From Smoke Signals to Artificial Intelligence   available at: https://www.diplomacy.edu/resource/history-of-diplomacy-and-technology-from-smoke-signals-to-artificial-intelligence/ Where to listen to this episode  Apple podcasts:  https://podcasts.apple.com/us/podcast/the-next-page/id1469021154 Spotify: https://open.spotify.com/show/10fp8ROoVdve0el88KyFLy YouTube: https://www.youtube.com/ Content    Guest: Jovan Kurbalija, Executive Director, Diplo Host and Producer: Amy Smith Editing and social media designs: Mengna Chen   Recorded & produced at the United Nations Library & Archives Geneva 

Hey Victor, hey Victor, hey...,hey Victor, Victor HEY! Hey Victor. Hey Victor! Thanks for tuning in. For more, follow us on Instagram & YouTube @justplayitpodcast & X (fka Twitter) @justplayitpod

If you were in middle school or high school in the last couple of decades, there's a good chance you were assigned Sherman's classic young adult novel The Absolutely True Diary of a Part-Time Indian, an epistolary novel with cartoon illustrations about a native teenage boy growing up on the Spokane Indian Reservation who decides to attend a nearly all-white high school. The book is semi-autobiographical. Sherman grew up on that reservation in the 1970s and 80s and is a member of the Spokane Tribe. He is also arguably — or perhaps inarguably — the most significant native American writer of the last 30 years. Not only did The Absolutely True Diary of a Part-Time Indian win the 2007 National Book Award for Young People's Literature, among other prizes, but his 2009 book War Dances won the 2010 Pen/Faulkner award for fiction, and his 1993 story collection The Lone Ranger and Tonto Fistfight in Heaven was adapted into the popular and highly acclaimed film Smoke Signals. Best of all (for me, anyway), Sherman is teaching a class for the brand-new Unspeakeasy School Of Thought. It's in a brand new genre: Writing Your Cancelation Story. In this conversation, Sherman talks about his career, his 2018 “cancelation event” (or at least its aftermath) and offers his thoughts on the state of writing and publishing, not least of all the recent incident wherein editors at the journal Guernica retracted an essay when the Twitter mob and its own staffers deemed it harmful, even “genocidal.” GUEST BIO Sherman Alexie is a poet, short story writer, novelist, essayist, memoirist, and filmmaker. He's published two dozen books, including The Absolutely True Diary of a Part-Time Indian, which won the National Book Award for Young People's Literature and was listed by the American Library Association as the Most Banned and Challenged Book from 2010 to 2019. He's won the PEN-Faulkner and PEN-Malamud awards, and he wrote and co-produced the award-winning film Smoke Signals, which was based on his short story collection The Lone Ranger and Tonto Fistfight in Heaven. Visit Sherman's Substack. Check out his upcoming course here. HOUSEKEEPING

Directed and starring Cody Lightning, HEY VIKTOR! is a mockumentary about one man's last grasp at greatness. As the child star of SMOKE SIGNALS, Lightning has never been able to translate his early success into adulthood acting glory. Now in his 30s, Lightning decides that the only course of action is to reconnect with his friends and recreate his childhood success with the creation of SMOKE SIGNALS 2. In this 1on1, we speak to Lightning about the line between myth and man, getting the band back together and leaving a legacy.

So let's look forward and prepare you for the next big sexy blockbuster tech IPO, you've read all about it - that's right. Reddit is going to ring the bell.For more on Bubble Trouble, including transcripts of the show, visit us online at http://bubbletroublepodcast.comYou can learn more about Richard at https://www.linkedin.com/in/richard-kramer-16306b2/More on Will Page at: https://pivotaleconomics.com(Times below correspond to the episode without considering any inserted advertisements.)Reddit's IPO Adventure: A Deep Dive into Valuations, Trends, and Future ProspectsIn this episode of Bubble Trouble, hosts Richard Kramer and Will Page dissect Reddit's impending IPO, examining its valuation, user base, and revenue streams. The podcast begins with a discussion on the evolution of Reddit and its business model, focusing on the challenges it faces as a business primarily driven by advertising revenue in a competitive digital advertising landscape. Kramer and Page delve into the nuances of Reddit's user engagement and its niche position in the internet culture, juxtaposing it against giants like Meta and Google. They critically analyze the hype surrounding tech IPOs, emphasizing Reddit's $800 million revenue and its struggle to become profitable amidst a sprawling digital advertising world. The episode also covers the broader implications of down rounds and the valuation bubbles that tech companies often face. Through expert insights and a candid conversation, the episode offers a comprehensive view on Reddit's IPO, the tech industry's valuation practices, and what the future holds for user-generated content platforms.00:00 Welcome to Bubble Trouble: DeepFakes and Bubbles01:02 Part One01:06 The Fascinating Shift from Hong Kong to Singapore02:52 Reddit's Upcoming IPO: A Deep Dive03:25 Exploring Reddit's Niche and Financials06:04 The Cultural Impact and Controversies of Reddit08:58 Reddit IPO Strategies and User Dynamics10:43 Inside Reddit: Culture, Compliance, and Future Prospects16:00 Part Two16:00 South by Southwest Festival Insights20:04 Back to Reddit: IPO Details and Expectations21:22 Technical Difficulties and Starting Off21:24 Exploring Down Rounds: A Deep Dive23:48 The Reality of Valuations and Market Corrections24:42 Tech Companies' Valuations Post-Pandemic25:41 Reddit's Revenue Diversification and Data Deals27:15 The Creator Economy: Expectations vs. Reality29:48 Reddit's IPO: A Case Study in Market Dynamics34:49 Smoke Signals for Future IPOs38:21 Reflecting on Reddit and the IPO Landscape40:20 Credits Hosted on Acast. See acast.com/privacy for more information.

25 years after playing “little Victor” in the cult classic 1998 film Smoke Signals, Cody Lightning is all grown up and back with his mockumentary, “Hey Viktor!” which follows a fictionalized version of himself trying to make Smoke Signals 2. Cody joins Tom from Edmonton, Alberta where the movie was shot to talk about making gritty Indigenous comedy, how his idea for the film began as a joke, and how he looks back on growing up as a child actor.

Grand Ronde Tribal Council Secretary Micheal Cherry recently attended the Tribal Elected Official Training at the ilani Casino Resort in Washington. Cherry sat down with the Smoke Signals podcast to share her take-aways from the three-day training.

Today's guest a man of many projects in the music scene George Rich of Lumina, I dream in cellophane, Smoke Signals and one of my personal favorites Void Runner. I always love hanging out talking with George its never a dull moment when the two of us get together and this time was no different. Check out all of his endeavors.    Links down below for all the goods. If you want behind the scenes and episodes 2 days early sign up for our Patreon it helps support the show in many ways.   As always thank you for listening.   Patreon https://www.patreon.com/crashcast   YouTube https://www.youtube.com/c/crashcast     Instagram https://www.instagram.com/crashcastpod/   Facebook https://www.facebook.com/crashcastpod   Twitter https://twitter.com/crashcastpod1

Adam Beach has been in more than 60 films and TV shows, from Canada's “North of 60” to the cult classic movie “Smoke Signals,” to Clint Eastwood's “Flags Of Our Fathers.” Adam tells Tom about how he began acting in Manitoba, how he looks back on his leading role as Victor in “Smoke Signals,” and why he's drawn to his complicated character in the new film “Exile.”

The interview in this episode was originally published in March of 2022.Before she was the starring alongside Jodie Foster in TRUE DETECTIVE, Kali Reis was a champion boxer. As she shares in this interview, she has always been "boxing for a cause" -- in particular, that of Murdered and Missing Indigenous Women. In her feature debut, 'Catch the Fair One' (directed by Josef Kubota Wladyka), she plays a  woman whose world is shaken when her sister goes missing.  Reis, who is of Wampanoag and Cape Verdean heritage, brings us a character with much different problems, but whose physicality, sense of humor, and deeply felt emotions, have been making Kali feel seen: Rue Bennett from HBO's Euphoria.Then, back in 2024, Jordan has one quick thing to say about the brand new crop of Oscar nominees.***With Jordan Crucchiola and Kali Reis

With 340-odd days ahead, what are the smoke signals - good and bad - that you need to be aware of? Today we look forward, and make sense of the madness ahead of us in 2024.For more on Bubble Trouble, including transcripts of the show, visit us online at http://bubbletroublepodcast.comYou can learn more about Richard at https://www.linkedin.com/in/richard-kramer-16306b2/More on Will Page at: https://pivotaleconomics.com(Times below correspond to the episode without considering any inserted advertisements.)Bubble Trouble: A Look at 2024's Economic Pitfalls and OpportunitiesIn this episode of Bubble Trouble, hosts Will Page and Richard Kramer discuss their outlook for 2024, examining potential economic headwinds and tailwinds. They predict turbulence ahead, citing macroeconomic swings, cutbacks in sectors like luxury goods, upcoming global elections, and changes in the tech landscape. They consider the potential impact of AI, particularly in the public sector, with potential benefits in education, health, and law. The hosts also discuss the uptake of Duolingo, reflecting on the broader success of apps that can maintain usage frequency.00:00 Introduction01:01 Part One01:26 The Impact of Economic Headwinds03:01 The Role of AI and Technology in the Economy04:23 The Impact of Job Cuts and Unemployment05:01 The Influence of Tech Companies on the Economy08:43 The Impact of Macro Swings and Uncertainties14:12 The Influence of Political Cycles on Economic Cycles20:25 Part Two 20:25 The Potential of AI in Transforming Public Services31:31 The Role of Drama in Influencing Public Opinion Hosted on Acast. See acast.com/privacy for more information.

We havne't had a Man's POV episode in a long time and this one was a wild ride! Your two favorite Black girls were joined by dating coach Derrick Bradley to discuss communication in relationships. One topic of discussion: everyone should be self-interested, but are we narcissists? And before you get up in arms about the use of the word, tap into this episode with us and our guest Derrick.

Brian and Shelly discuss indigenous movies including The Nightengale, Once Were Warriors and Smoke Signals

Dan and Jon have made it to The Aloha State to gab about the 1961film that introduced the world to Elvis singing I Can't Help Falling in Love. Dan and Jon talk about their own experiences in Hawaii, representation of indigenous Pacific Islanders, and conflicting feelings about the King of Rock and Roll.Hey, Viktor! trailerNext episode: Wayne's World (1992) • IllinoisSee what native tribes reside or resided in what is now known as IdahoContact us, follow us on social media, or buy some merch at linktr.ee/RuinedChildhoods Hosted on Acast. See acast.com/privacy for more information.

Dan and Jon have made it to The Aloha State to gab about the 1961film that introduced the world to Elvis singing I Can't Help Falling in Love. Dan and Jon talk about their own experiences in Hawaii, representation of indigenous Pacific Islanders, and conflicting feelings about the King of Rock and Roll.Next episode: Smoke Signals (1998) • IdahoSee what native tribes reside or resided in what is now known as HawaiiContact us, follow us on social media, or buy some merch at linktr.ee/RuinedChildhoods Hosted on Acast. See acast.com/privacy for more information.

Book Vs. Movie: Smoke SignalsThe Sherman Alexie Short Story Vs. the 1998 Movie In this episode, the Margos delve into the acclaimed indie film Smoke Signals, released in 1998. This film was based on a series of short stories by Sherman Alexie in 1993, titled The Lone Ranger and Tonto Fistfight in Heaven. The story follows two young men, Victor Joseph and Tom Builds-the-Fire, who grew up on a Spokane Indian Reservation. It explores the interconnectedness of their families, the perception of Native Americans in mainstream media, and the truth behind Tom's father's death. Smoke Signals was well-received by critics and audiences alike and was showcased at various film festivals such as the Sundance Film Festival, the Gotham Awards, and the Independent Spirit Awards. In 2018, it was even added to the National Film Registry. Chris Eyre directed the movie, which was based on Alexie's screenplay. We'll also be discussing our personal preferences between the two. Come and join this discussion. Calm History:If you want to learn about curious moments from history while lowering your stress, try the new podcast Calm History. Each episode is narrated in a calm voice to help you to relax or fall asleep. You'll enjoy learning about famous explorers, leaders, athletes, inventions, civilizations, and ancient wonders. There is even a 6-part series about The Titanic. Search your podcast player for Calm History, or use the link to calmhistory.com in the episode notes.In this ep, the Margos discuss:The controversies of writer Sherman AlexieThe history of how America treats Indigenous people. (Big hint--not great!)The differences between Alexie's short stories and the filmThe cast of the 1998 film: Adam Beach (Victor Joseph,) Evan Adams (Thomas Builds-the-Fire,) Irene Bedard (Suzy Song,) Gary Farmer (Arnold Joseph,) John Trudell (Randy Peone,) Michael Greyeyes (Junior Polatkin,) Michelle St. John (Velma,) Elaine Miles (Lucy,) Cynthia Geary (Cathy the gymnast,) Perrey Reaves (Holly,) Molly Cheek (Penny Cicero,) Robert Maino (Burt Cicero,) and Tom Skerrit as the police chief.Clips used:“How to be a real Indian”Smoke Signals (1998 trailer)“Don't go, Dad!”“He's waiting for you”“I broke some hearts”“The Oral Tradition”Music: Wah Jhi le Yihm by Ulali Book Vs. Movie is part of the Frolic Podcast Network. Find more podcasts you will love Frolic.Media/podcasts. Join our Patreon page “Book Vs. Movie podcast”You can find us on Facebook at Book Vs. Movie Podcast GroupFollow us on Twitter @bookversusmovieInstagram: Book Versus Movie https://www.instagram.com/bookversusmovie/Email us at bookversusmoviepodcast@gmail.com Margo D. Twitter @BrooklynMargo Margo D's Blog www.brooklynfitchick.com Margo D's Instagram “Brooklyn Fit Chick”Margo D's TikTok https://www.tiktok.com/@margodonohuebrooklynfitchick@gmail.comYou can buy your copy of Filmed in Brooklyn here! Margo P. Twitter @ShesNachoMamaMargo P's Instagram https://www.instagram.com/shesnachomama/Margo P's Blog https://coloniabook.weebly.com/ Our logo was designed by Madeleine Gainey/Studio 39 Marketing Follow on Instagram @Studio39Marketing & @musicalmadeleine This show is part of the Spreaker Prime Network, if you are interested in advertising on this podcast, contact us at https://www.spreaker.com/show/5406542/advertisement

Actor Cody Lightning explore his legacy in his 2023 film Hey Viktor, a mockumentary about where he's been since his role in the 1998 coming-of-age film Smoke Signals. Editor Sarah Taylor discusses her approach to the film as well as some of her other work.Find out more about Sarah at https://suiteoneproductions.com/Become a supporter of this podcast: https://www.spreaker.com/show/the-projection-booth-podcast_2/support.This show is part of the Spreaker Prime Network, if you are interested in advertising on this podcast, contact us at https://www.spreaker.com/show/5513239/advertisement

Link to our listener survey: https://tally.so/r/wgaKOd   On today's episode of the Wright Report, we explore various topics affecting America and the wider world. Our first story looks at the unexpected cloud of smoke lingering over the East Coast, all the way from Canada. We'll delve into its cause and how long it's likely to persist. We then turn our attention to an important staple - wheat - and discuss its global implications that are closer to home than you might think. Next, we examine a significant shift in the global economic landscape, with data from the Commerce Department revealing a divergence between America and China's economies. We also explore a developing scandal out of Colombia involving a nanny, wiretap, and a hefty campaign contribution. Finally, we address a disgruntled listener's concerns over our Ukraine coverage and give an update on our listener survey.

Richard from Intercourse, PA has become a public nuisance with his Ford wagon that belches white smoke every time he accelerates from a stop. Can Click and Clack divine his car's trouble from analyzing the Ford's emissions? Check it out along with Gary, the yodeling cowboy, a new puzzler and more callers on this episode of the Best of Car Talk.