Podcasts about geocities

Miks julgus kahelda oma mõtetes ja soov kuulata, mida kasutajad tegelikult arvad, viib parema digiteenuseni? Mida tähendab igapäevane innovatsioon digiteenuse arenduses?Seekordses saates on külas Kristjan Pillak, Postimees Grupi digiteenuste juht, kelle 20+ aasta teekond ulatub esimestest Geocities lehtedest täna suure meediamaja platvormideni.Räägime sellest, kuidas sünnib päriselt toimiv digiteenus ja millist rolli mängivad hästi sihitud fookus, andmeanalüütika, kasutajaintervjuud ja kiire prototüüpimine.Uurime ka, mis on hoidnud Kristjanit nii pikalt digiteenuste arenduse juures ning milliseid põnevaid projekte see teekond on toonud.Saates saad teada:- Mis on kolm kriitilist sammu iga digiteenuse loomisel?- Miks on oluline kahelda iseeneda mõtetes ja küsida, mida kasutajad tegelikult mõtlevad ja teevad? - Miks prototüüp on parim viis oma mõttelõnga testimiseks?- Miks mõni idee vajabki 10 aastat, et õigeks ajaks valmis küpseda?- Ja millist rolli mängivad koosloome töötoad ja disainmõtlemine igapäevases innovatsioonis.Fun fakt, Kristjani tiimi käe all elab endiselt edasi ka legendaarne Neti.ee ja sellel on rohkem kasutajaid, kui arvaksid! Saa teada, miks seda endiselt elus hoitakse.Lähemalt disainisprintidest: https://www.futurist.ee/disainisprintLähemalt postimehe teenustest päisemenüüs: https://www.postimees.ee

ย้อนกลับไปในยุค 1990 มีสถานที่หนึ่งบนอินเทอร์เน็ตที่ครั้งหนึ่งเคยเป็นบ้านให้กับผู้คนนับล้าน เป็นมหานครดิจิทัลที่เต็มไปด้วยชีวิตชีวา มีถนนหนทางเป็นลิงก์ มีอาคารบ้านเรือนเป็นเว็บเพจส่วนตัว และมีย่านต่างๆ ที่แบ่งตามความสนใจของผู้คน สถานที่นั้นมีชื่อว่า GeoCities ช่วงปลายทศวรรษ 1990 เป็นยุคทองของ GeoCities ซึ่งเปรียบเสมือนศูนย์กลางของวัฒนธรรมอินเทอร์เน็ตยุคแรก ในเวลานั้น การสร้างเว็บไซต์เป็นเรื่องที่ซับซ้อนและต้องใช้ความรู้ทางเทคนิคสูง แต่ GeoCities เปลี่ยนแปลงทุกอย่าง พวกเขาเสนอพื้นที่ฟรีและเครื่องมือง่ายๆ ที่ทำให้คนทั่วไปสามารถสร้างเว็บเพจของตัวเองได้โดยไม่ต้องมีความรู้เรื่องการเขียนโค้ด HTML ที่ซับซ้อน เลือกฟังกันได้เลยนะครับ อย่าลืมกด Follow ติดตาม PodCast ช่อง Geek Forever's Podcast ของผมกันด้วยนะครับ #GeoCities #ประวัติศาสตร์อินเทอร์เน็ต #เว็บไซต์ยุค90 #อินเทอร์เน็ตยุคแรก #Yahoo #เมืองร้างดิจิทัล #WebDesign #ย้อนอดีต #เว็บไซต์เก่าแก่ #เก็บถาวรเว็บไซต์ #สร้างเว็บฟรี #ดิจิทัลโนสตัลเจีย #ประวัติInternet #WebHistory #DavidBohnett #InternetArchive #เว็บไซต์สูญหาย #มรดกดิจิทัล #ความทรงจำออนไลน์ #ArchiveTeam #geekstory #geekforeverpodcast

El misterioso caso de un delito que nunca fue cometido y un pueblo en alerta ECDQEMSD podcast episodio 6035 Secuestro Involuntario Conducen: El Pirata y El Sr. Lagartija https://canaltrans.com Noticias del Mundo: Marchas en el mundo por el Día del Trabajo - Reapareció Kamala Harris - La violencia en Haití - El león de Culiacán - No tenemos tobilleras - Fortuna negada - Cuestión de métodos - Pronóstico del Tiempo Historias Desintegradas: Una tarde de calor - Jugando en el patio - Viendo una película - Rumores al anochecer - Composta y lombrices - El México prehistórico - Taxis del DF - Chica fresa - Olor sintético - Geocities, Encarta, Altavista y muchos más - El liso santafesino - Clásico entre sabaleros y tatengues - Hay historias de éxito - El buen Atún - No al acoso escolar - Día mundial del asma y más... En Caso De Que El Mundo Se Desintegre - Podcast no tiene publicidad, sponsors ni organizaciones que aporten para mantenerlo al aire. Solo el sistema cooperativo de los que aportan a través de las suscripciones hacen posible que todo esto siga siendo una realidad. Gracias Dragones Dorados!! NO AI: ECDQEMSD Podcast no utiliza ninguna inteligencia artificial de manera directa para su realización. Diseño, guionado, música, edición y voces son de  nuestra completa intervención humana.

BARRY RITHOLTZ's new book "How Not to Invest" has received a warm reception. We talk about investing mistakes, the Trump Tariffs, and curating a good media diet. https://youtu.be/pS4f45v2iRk https://www.amazon.com/dp/1804091197/ "How Not To Invest" Transcript Frazer Rice (00:03)Welcome aboard, Barry. Barry (00:04)Well, thanks so much for having me, Frasier. Frazer Rice (00:06)Well, we are recording in the midst of chaos and disorder. We're basically in day three, trading day three of the tariffs and trying to understand all of that. But back at the matter of hand, your new book, I read it really good. I thought it did a really good job of sort of colloquially putting some process and structure around not making bad investing decisions. Tell me a little bit about the impetus for the book. Barry (00:35)Sure, so the last book, Bailout Nation, was 15 years ago when I've had a lot of friends and family say, when's the next book coming? And, you know, I had a little, like, hey, that was kind of a slog, stuff blowing up and forcing me to rewrite entire sections of the book every time some new company went belly up. And I came home from Christmas break from vacation. You have that dead zone a few days before you're back in the office January 2nd. And I just started thumbing through some old quarterly calls for clients and research notes and market commentaries. You know, I had moved the blog from GeoCities in the nineties to Typepad in the two thousands to WordPress in the 2010s. And so I was looking at some of these old things and like, God, I never revisited this. This is such a great piece of research. I love this academic take on where alpha or even beta comes from. And I'm just kind of mulling it over. I start writing down chapter ideas on three by five cards like these. And I end up using this giant bulletin board on my wall. It just basically I start putting stuff up and I start rearranging them. And pretty soon it becomes obvious. Hey, these ideas, a lot of them are don'ts. Don't do this. Don't do that. Avoid this. Try not to make this bad mistake. And ultimately, I kind of came to the conclusion that, know, we've part of the reason I held off writing a book is there have been tens of thousands of investing books telling people what to do. And we're all pretty mediocre investors still. Maybe it might be useful if we learned what not to do and thus "how not to invest" was born. Frazer Rice (02:35)We found kind of an interesting crucible to test all of this with sort of Trump's tariff initiatives and a bunch of chaos on that front. As you think about what we're living in right now with uncertainty, whether manufactured or not, what are some of the top things that you think about that you tell people, your clients and otherwise? to keep in mind as we sort of weather this storm and try to learn a little bit about what the future is going to look like. Barry (03:06)Right. I had no idea what what the sequel would be named. Maybe it could be how not to run an economy or what we'll play with that. But so so what's happening these days are kind of fascinating because the first third of the book I spent a lot of time talking about how little we really know about about what's happening right now. And we learn even less about the future. And so our Frazer Rice (03:12)Ha Barry (03:34)A hot take on these things is maybe we shouldn't build portfolios based on having to predict where the economy is going to be, what the hot sector is going to be, where the hot geography is going to be, what the best companies are. Maybe we need to be a little more robust and capable of withstanding this. And the tariffs are a perfect example of how little we know. Look, the obvious examples of "How Not to Invest" Nobody had heading into 2020 in their year had forecast global pandemic that shuts the world's economy. And by the way, stocks go straight up. They just after a 34 percent crash,

Brandon Liu is an open source developer and creator of the Protomaps basemap project. We talk about how static maps help developers build sites that last, the PMTiles file format, the role of OpenStreetMap, and his experience funding and running an open source project full time. Protomaps Protomaps PMTiles (File format used by Protomaps) Self-hosted slippy maps, for novices (like me) Why Deploy Protomaps on a CDN User examples Flickr Pinball Map Toilet Map Related projects OpenStreetMap (Dataset protomaps is based on) Mapzen (Former company that released details on what to display based on zoom levels) Mapbox GL JS (Mapbox developed source available map rendering library) MapLibre GL JS (Open source fork of Mapbox GL JS) Other links HTTP range requests (MDN) Hilbert curve Transcript You can help correct transcripts on GitHub. Intro [00:00:00] Jeremy: I'm talking to Brandon Liu. He's the creator of Protomaps, which is a way to easily create and host your own maps. Let's get into it. [00:00:09] Brandon: Hey, so thanks for having me on the podcast. So I'm Brandon. I work on an open source project called Protomaps. What it really is, is if you're a front end developer and you ever wanted to put maps on a website or on a mobile app, then Protomaps is sort of an open source solution for doing that that I hope is something that's way easier to use than, um, a lot of other open source projects. Why not just use Google Maps? [00:00:36] Jeremy: A lot of people are gonna be familiar with Google Maps. Why should they worry about whether something's open source? Why shouldn't they just go and use the Google maps API? [00:00:47] Brandon: So Google Maps is like an awesome thing it's an awesome product. Probably one of the best tech products ever right? And just to have a map that tells you what restaurants are open and something that I use like all the time especially like when you're traveling it has all that data. And the most amazing part is that it's free for consumers but it's not necessarily free for developers. Like if you wanted to embed that map onto your website or app, that usually has an API cost which still has a free tier and is affordable. But one motivation, one basic reason to use open source is if you have some project that doesn't really fit into that pricing model. You know like where you have to pay the cost of Google Maps, you have a side project, a nonprofit, that's one reason. But there's lots of other reasons related to flexibility or customization where you might want to use open source instead. Protomaps examples [00:01:49] Jeremy: Can you give some examples where people have used Protomaps and where that made sense for them? [00:01:56] Brandon: I follow a lot of the use cases and I also don't know about a lot of them because I don't have an API where I can track a hundred percent of the users. Some of them use the hosted version, but I would say most of them probably use it on their own infrastructure. One of the cool projects I've been seeing is called Toilet Map. And what toilet map is if you're in the UK and you want find a public restroom then it maps out, sort of crowdsourced all of the public restrooms. And that's important for like a lot of people if they have health issues, they need to find that information. And just a lot of different projects in the same vein. There's another one called Pinball Map which is sort of a hobby project to find all the pinball machines in the world. And they wanted to have a customized map that fit in with their theme of pinball. So these sorts of really cool indie projects are the ones I'm most excited about. Basemaps vs Overlays [00:02:57] Jeremy: And if we talk about, like the pinball map as an example, there's this concept of a basemap and then there's the things that you lay on top of it. What is a basemap and then is the pinball locations is that part of it or is that something separate? [00:03:12] Brandon: It's usually something separate. The example I usually use is if you go to a real estate site, like Zillow, you'll open up the map of Seattle and it has a bunch of pins showing all the houses, and then it has some information beneath it. That information beneath it is like labels telling, this neighborhood is Capitol Hill, or there is a park here. But all that information is common to a lot of use cases and it's not specific to real estate. So I think usually that's the distinction people use in the industry between like a base map versus your overlay. The overlay is like the data for your product or your company while the base map is something you could get from Google or from Protomaps or from Apple or from Mapbox that kind of thing. PMTiles for hosting the basemap and overlays [00:03:58] Jeremy: And so Protomaps in particular is responsible for the base map, and that information includes things like the streets and the locations of landmarks and things like that. Where is all that information coming from? [00:04:12] Brandon: So the base map information comes from a project called OpenStreetMap. And I would also, point out that for Protomaps as sort of an ecosystem. You can also put your overlay data into a format called PMTiles, which is sort of the core of what Protomaps is. So it can really do both. It can transform your data into the PMTiles format which you can host and you can also host the base map. So you kind of have both of those sides of the product in one solution. [00:04:43] Jeremy: And so when you say you have both are you saying that the PMTiles file can have, the base map in one file and then you would have the data you're laying on top in another file? Or what are you describing there? [00:04:57] Brandon: That's usually how I recommend to do it. Oftentimes there'll be sort of like, a really big basemap 'cause it has all of that data about like where the rivers are. Or while, if you want to put your map of toilets or park benches or pickleball courts on top, that's another file. But those are all just like assets you can move around like JSON or CSV files. Statically Hosted [00:05:19] Jeremy: And I think one of the things you mentioned was that your goal was to make Protomaps or the, the use of these PMTiles files easy to use. What does that look like for, for a developer? I wanna host a map. What do I actually need to, to put on my servers? [00:05:38] Brandon: So my usual pitch is that basically if you know how to use S3 or cloud storage, that you know how to deploy a map. And that, I think is the main sort of differentiation from most open source projects. Like a lot of them, they call themselves like, like some sort of self-hosted solution. But I've actually avoided using the term self-hosted because I think in most cases that implies a lot of complexity. Like you have to log into a Linux server or you have to use Kubernetes or some sort of Docker thing. What I really want to emphasize is the idea that, for Protomaps, it's self-hosted in the same way like CSS is self-hosted. So you don't really need a service from Amazon to host the JSON files or CSV files. It's really just a static file. [00:06:32] Jeremy: When you say static file that means you could use any static web host to host your HTML file, your JavaScript that actually renders the map. And then you have your PMTiles files, and you're not running a process or anything, you're just putting your files on a static file host. [00:06:50] Brandon: Right. So I think if you're a developer, you can also argue like a static file server is a server. It's you know, it's the cloud, it's just someone else's computer. It's really just nginx under the hood. But I think static storage is sort of special. If you look at things like static site generators, like Jekyll or Hugo, they're really popular because they're a commodity or like the storage is a commodity. And you can take your blog, make it a Jekyll blog, hosted on S3. One day, Amazon's like, we're charging three times as much so you can move it to a different cloud provider. And that's all vendor neutral. So I think that's really the special thing about static storage as a primitive on the web. Why running servers is a problem for resilience [00:07:36] Jeremy: Was there a prior experience you had? Like you've worked with maps for a very long time. Were there particular difficulties you had where you said I just gotta have something that can be statically hosted? [00:07:50] Brandon: That's sort of exactly why I got into this. I've been working sort of in and around the map space for over a decade, and Protomaps is really like me trying to solve the same problem I've had over and over again in the past, just like once and forever right? Because like once this problem is solved, like I don't need to deal with it again in the future. So I've worked at a couple of different companies before, mostly as a contractor, for like a humanitarian nonprofit for a design company doing things like, web applications to visualize climate change. Or for even like museums, like digital signage for museums. And oftentimes they had some sort of data visualization component, but always sort of the challenge of how to like, store and also distribute like that data was something that there wasn't really great open source solutions. So just for map data, that's really what motivated that design for Protomaps. [00:08:55] Jeremy: And in those, those projects in the past, were those things where you had to run your own server, run your own database, things like that? [00:09:04] Brandon: Yeah. And oftentimes we did, we would spin up an EC2 instance, for maybe one client and then we would have to host this server serving map data forever. Maybe the client goes away, or I guess it's good for business if you can sign some sort of like long-term support for that client saying, Hey, you know, like we're done with a project, but you can pay us to maintain the EC2 server for the next 10 years. And that's attractive. but it's also sort of a pain, because usually what happens is if people are given the choice, like a developer between like either I can manage the server on EC2 or on Rackspace or Hetzner or whatever, or I can go pay a SaaS to do it. In most cases, businesses will choose to pay the SaaS. So that's really like what creates a sort of lock-in is this preference for like, so I have this choice between like running the server or paying the SaaS. Like businesses will almost always go and pay the SaaS. [00:10:05] Jeremy: Yeah. And in this case, you either find some kind of free hosting or low-cost hosting just to host your files and you upload the files and then you're good from there. You don't need to maintain anything. [00:10:18] Brandon: Exactly, and that's really the ideal use case. so I have some users these, climate science consulting agencies, and then they might have like a one-off project where they have to generate the data once, but instead of having to maintain this server for the lifetime of that project, they just have a file on S3 and like, who cares? If that costs a couple dollars a month to run, that's fine, but it's not like S3 is gonna be deprecated, like it's gonna be on an insecure version of Ubuntu or something. So that's really the ideal, set of constraints for using Protomaps. [00:10:58] Jeremy: Yeah. Something this also makes me think about is, is like the resilience of sites like remaining online, because I, interviewed, Kyle Drake, he runs Neocities, which is like a modern version of GeoCities. And if I remember correctly, he was mentioning how a lot of old websites from that time, if they were running a server backend, like they were running PHP or something like that, if you were to try to go to those sites, now they're like pretty much all dead because there needed to be someone dedicated to running a Linux server, making sure things were patched and so on and so forth. But for static sites, like the ones that used to be hosted on GeoCities, you can go to the internet archive or other websites and they were just files, right? You can bring 'em right back up, and if anybody just puts 'em on a web server, then you're good. They're still alive. Case study of news room preferring static hosting [00:11:53] Brandon: Yeah, exactly. One place that's kind of surprising but makes sense where this comes up, is for newspapers actually. Some of the users using Protomaps are the Washington Post. And the reason they use it, is not necessarily because they don't want to pay for a SaaS like Google, but because if they make an interactive story, they have to guarantee that it still works in a couple of years. And that's like a policy decision from like the editorial board, which is like, so you can't write an article if people can't view it in five years. But if your like interactive data story is reliant on a third party, API and that third party API becomes deprecated, or it changes the pricing or it, you know, it gets acquired, then your journalism story is not gonna work anymore. So I have seen really good uptake among local news rooms and even big ones to use things like Protomaps just because it makes sense for the requirements. Working on Protomaps as an open source project for five years [00:12:49] Jeremy: How long have you been working on Protomaps and the parts that it's made up of such as PMTiles? [00:12:58] Brandon: I've been working on it for about five years, maybe a little more than that. It's sort of my pandemic era project. But the PMTiles part, which is really the heart of it only came in about halfway. Why not make a SaaS? [00:13:13] Brandon: So honestly, like when I first started it, I thought it was gonna be another SaaS and then I looked at it and looked at what the environment was around it. And I'm like, uh, so I don't really think I wanna do that. [00:13:24] Jeremy: When, when you say you looked at the environment around it what do you mean? Why did you decide not to make it a SaaS? [00:13:31] Brandon: Because there already is a lot of SaaS out there. And I think the opportunity of making something that is unique in terms of those use cases, like I mentioned like newsrooms, was clear. Like it was clear that there was some other solution, that could be built that would fit these needs better while if it was a SaaS, there are plenty of those out there. And I don't necessarily think that they're well differentiated. A lot of them all use OpenStreetMap data. And it seems like they mainly compete on price. It's like who can build the best three column pricing model. And then once you do that, you need to build like billing and metrics and authentication and like those problems don't really interest me. So I think, although I acknowledge sort of the indie hacker ethos now is to build a SaaS product with a monthly subscription, that's something I very much chose not to do, even though it is for sure like the best way to build a business. [00:14:29] Jeremy: Yeah, I mean, I think a lot of people can appreciate that perspective because it's, it's almost like we have SaaS overload, right? Where you have so many little bills for your project where you're like, another $5 a month, another $10 a month, or if you're a business, right? Those, you add a bunch of zeros and at some point it's just how many of these are we gonna stack on here? [00:14:53] Brandon: Yeah. And honestly. So I really think like as programmers, we're not really like great at choosing how to spend money like a $10 SaaS. That's like nothing. You know? So I can go to Starbucks and I can buy a pumpkin spice latte, and that's like $10 basically now, right? And it's like I'm able to make that consumer choice in like an instant just to spend money on that. But then if you're like, oh, like spend $10 on a SaaS that somebody put a lot of work into, then you're like, oh, that's too expensive. I could just do it myself. So I'm someone that also subscribes to a lot of SaaS products. and I think for a lot of things it's a great fit. Many open source SaaS projects are not easy to self host [00:15:37] Brandon: But there's always this tension between an open source project that you might be able to run yourself and a SaaS. And I think a lot of projects are at different parts of the spectrum. But for Protomaps, it's very much like I'm trying to move maps to being it is something that is so easy to run yourself that anyone can do it. [00:16:00] Jeremy: Yeah, and I think you can really see it with, there's a few SaaS projects that are successful and they're open source, but then you go to look at the self-hosting instructions and it's either really difficult to find and you find it, and then the instructions maybe don't work, or it's really complicated. So I think doing the opposite with Protomaps. As a user, I'm sure we're all appreciative, but I wonder in terms of trying to make money, if that's difficult. [00:16:30] Brandon: No, for sure. It is not like a good way to make money because I think like the ideal situation for an open source project that is open that wants to make money is the product itself is fundamentally complicated to where people are scared to run it themselves. Like a good example I can think of is like Supabase. Supabase is sort of like a platform as a service based on Postgres. And if you wanted to run it yourself, well you need to run Postgres and you need to handle backups and authentication and logging, and that stuff all needs to work and be production ready. So I think a lot of people, like they don't trust themselves to run database backups correctly. 'cause if you get it wrong once, then you're kind of screwed. So I think that fundamental aspect of the product, like a database is something that is very, very ripe for being a SaaS while still being open source because it's fundamentally hard to run. Another one I can think of is like tailscale, which is, like a VPN that works end to end. That's something where, you know, it has this networking complexity where a lot of developers don't wanna deal with that. So they'd happily pay, for tailscale as a service. There is a lot of products or open source projects that eventually end up just changing to becoming like a hosted service. Businesses going from open source to closed or restricted licenses [00:17:58] Brandon: But then in that situation why would they keep it open source, right? Like, if it's easy to run yourself well, doesn't that sort of cannibalize their business model? And I think that's really the tension overall in these open source companies. So you saw it happen to things like Elasticsearch to things like Terraform where they eventually change the license to one that makes it difficult for other companies to compete with them. [00:18:23] Jeremy: Yeah, I mean there's been a number of cases like that. I mean, specifically within the mapping community, one I can think of was Mapbox's. They have Mapbox gl. Which was a JavaScript client to visualize maps and they moved from, I forget which license they picked, but they moved to a much more restrictive license. I wonder what your thoughts are on something that releases as open source, but then becomes something maybe a little more muddy. [00:18:55] Brandon: Yeah, I think it totally makes sense because if you look at their business and their funding, it seems like for Mapbox, I haven't used it in a while, but my understanding is like a lot of their business now is car companies and doing in dash navigation. And that is probably way better of a business than trying to serve like people making maps of toilets. And I think sort of the beauty of it is that, so Mapbox, the story is they had a JavaScript renderer called Mapbox GL JS. And they changed that to a source available license a couple years ago. And there's a fork of it that I'm sort of involved in called MapLibre GL. But I think the cool part is Mapbox paid employees for years, probably millions of dollars in total to work on this thing and just gave it away for free. Right? So everyone can benefit from that work they did. It's not like that code went away, like once they changed the license. Well, the old version has been forked. It's going its own way now. It's quite different than the new version of Mapbox, but I think it's extremely generous that they're able to pay people for years, you know, like a competitive salary and just give that away. [00:20:10] Jeremy: Yeah, so we should maybe look at it as, it was a gift while it was open source, and they've given it to the community and they're on continuing on their own path, but at least the community running Map Libre, they can run with it, right? It's not like it just disappeared. [00:20:29] Brandon: Yeah, exactly. And that is something that I use for Protomaps quite extensively. Like it's the primary way of showing maps on the web and I've been trying to like work on some enhancements to it to have like better internationalization for if you are in like South Asia like not show languages correctly. So I think it is being taken in a new direction. And I think like sort of the combination of Protomaps and MapLibre, it addresses a lot of use cases, like I mentioned earlier with like these like hobby projects, indie projects that are almost certainly not interesting to someone like Mapbox or Google as a business. But I'm happy to support as a small business myself. Financially supporting open source work (GitHub sponsors, closed source, contracts) [00:21:12] Jeremy: In my previous interview with Tom, one of the main things he mentioned was that creating a mapping business is incredibly difficult, and he said he probably wouldn't do it again. So in your case, you're building Protomaps, which you've admitted is easy to self-host. So there's not a whole lot of incentive for people to pay you. How is that working out for you? How are you supporting yourself? [00:21:40] Brandon: There's a couple of strategies that I've tried and oftentimes failed at. Just to go down the list, so I do have GitHub sponsors so I do have a hosted version of Protomaps you can use if you don't want to bother copying a big file around. But the way I do the billing for that is through GitHub sponsors. If you wanted to use this thing I provide, then just be a sponsor. And that definitely pays for itself, like the cost of running it. And that's great. GitHub sponsors is so easy to set up. It just removes you having to deal with Stripe or something. 'cause a lot of people, their credit card information is already in GitHub. GitHub sponsors I think is awesome if you want to like cover costs for a project. But I think very few people are able to make that work. A thing that's like a salary job level. It's sort of like Twitch streaming, you know, there's a handful of people that are full-time streamers and then you look down the list on Twitch and it's like a lot of people that have like 10 viewers. But some of the other things I've tried, I actually started out, publishing the base map as a closed source thing, where I would sell sort of like a data package instead of being a SaaS, I'd be like, here's a one-time download, of the premium data and you can buy it. And quite a few people bought it I just priced it at like $500 for this thing. And I thought that was an interesting experiment. The main reason it's interesting is because the people that it attracts to you in terms of like, they're curious about your products, are all people willing to pay money. While if you start out everything being open source, then the people that are gonna be try to do it are only the people that want to get something for free. So what I discovered is actually like once you transition that thing from closed source to open source, a lot of the people that used to pay you money will still keep paying you money because like, it wasn't necessarily that that closed source thing was why they wanted to pay. They just valued that thought you've put into it your expertise, for example. So I think that is one thing, that I tried at the beginning was just start out, closed source proprietary, then make it open source. That's interesting to people. Like if you release something as open source, if you go the other way, like people are really mad if you start out with something open source and then later on you're like, oh, it's some other license. Then people are like that's so rotten. But I think doing it the other way, I think is quite valuable in terms of being able to find an audience. [00:24:29] Jeremy: And when you said it was closed source and paid to open source, do you still sell those map exports? [00:24:39] Brandon: I don't right now. It's something that I might do in the future, you know, like have small customizations of the data that are available, uh, for a fee. still like the core OpenStreetMap based map that's like a hundred gigs you can just download. And that'll always just be like a free download just because that's already out there. All the source code to build it is open source. So even if I said, oh, you have to pay for it, then someone else can just do it right? So there's no real reason like to make that like some sort of like paywall thing. But I think like overall if the project is gonna survive in the long term it's important that I'd ideally like to be able to like grow like a team like have a small group of people that can dedicate the time to growing the project in the long term. But I'm still like trying to figure that out right now. [00:25:34] Jeremy: And when you mentioned that when you went from closed to open and people were still paying you, you don't sell a product anymore. What were they paying for? [00:25:45] Brandon: So I have some contracts with companies basically, like if they need a feature or they need a customization in this way then I am very open to those. And I sort of set it up to make it clear from the beginning that this is not just a free thing on GitHub, this is something that you could pay for if you need help with it, if you need support, if you wanted it. I'm also a little cagey about the word support because I think like it sounds a little bit too wishy-washy. Pretty much like if you need access to the developers of an open source project, I think that's something that businesses are willing to pay for. And I think like making that clear to potential users is a challenge. But I think that is one way that you might be able to make like a living out of open source. [00:26:35] Jeremy: And I think you said you'd been working on it for about five years. Has that mostly been full time? [00:26:42] Brandon: It's been on and off. it's sort of my pandemic era project. But I've spent a lot of time, most of my time working on the open source project at this point. So I have done some things that were more just like I'm doing a customization or like a private deployment for some client. But that's been a minority of the time. Yeah. [00:27:03] Jeremy: It's still impressive to have an open source project that is easy to self-host and yet is still able to support you working on it full time. I think a lot of people might make the assumption that there's nothing to sell if something is, is easy to use. But this sort of sounds like a counterpoint to that. [00:27:25] Brandon: I think I'd like it to be. So when you come back to the point of like, it being easy to self-host. Well, so again, like I think about it as like a primitive of the web. Like for example, if you wanted to start a business today as like hosted CSS files, you know, like where you upload your CSS and then you get developers to pay you a monthly subscription for how many times they fetched a CSS file. Well, I think most developers would be like, that's stupid because it's just an open specification, you just upload a static file. And really my goal is to make Protomaps the same way where it's obvious that there's not really some sort of lock-in or some sort of secret sauce in the server that does this thing. How PMTiles works and building a primitive of the web [00:28:16] Brandon: If you look at video for example, like a lot of the tech for how Protomaps and PMTiles works is based on parts of the HTTP spec that were made for video. And 20 years ago, if you wanted to host a video on the web, you had to have like a real player license or flash. So you had to go license some server software from real media or from macromedia so you could stream video to a browser plugin. But now in HTML you can just embed a video file. And no one's like, oh well I need to go pay for my video serving license. I mean, there is such a thing, like YouTube doesn't really use that for DRM reasons, but people just have the assumption that video is like a primitive on the web. So if we're able to make maps sort of that same way like a primitive on the web then there isn't really some obvious business or licensing model behind how that works. Just because it's a thing and it helps a lot of people do their jobs and people are happy using it. So why bother? [00:29:26] Jeremy: You mentioned that it a tech that was used for streaming video. What tech specifically is it? [00:29:34] Brandon: So it is byte range serving. So when you open a video file on the web, So let's say it's like a 100 megabyte video. You don't have to download the entire video before it starts playing. It streams parts out of the file based on like what frames... I mean, it's based on the frames in the video. So it can start streaming immediately because it's organized in a way to where the first few frames are at the beginning. And what PMTiles really is, is it's just like a video but in space instead of time. So it's organized in a way where these zoomed out views are at the beginning and the most zoomed in views are at the end. So when you're like panning or zooming in the map all you're really doing is fetching byte ranges out of that file the same way as a video. But it's organized in, this tiled way on a space filling curve. IIt's a little bit complicated how it works internally and I think it's kind of cool but that's sort of an like an implementation detail. [00:30:35] Jeremy: And to the person deploying it, it just looks like a single file. [00:30:40] Brandon: Exactly in the same way like an mp3 audio file is or like a JSON file is. [00:30:47] Jeremy: So with a video, I can sort of see how as someone seeks through the video, they start at the beginning and then they go to the middle if they wanna see the middle. For a map, as somebody scrolls around the map, are you seeking all over the file or is the way it's structured have a little less chaos? [00:31:09] Brandon: It's structured. And that's kind of the main technical challenge behind building PMTiles is you have to be sort of clever so you're not spraying the reads everywhere. So it uses something called a hilbert curve, which is a mathematical concept of a space filling curve. Where it's one continuous curve that essentially lets you break 2D space into 1D space. So if you've seen some maps of IP space, it uses this crazy looking curve that hits all the points in one continuous line. And that's the same concept behind PMTiles is if you're looking at one part of the world, you're sort of guaranteed that all of those parts you're looking at are quite close to each other and the data you have to transfer is quite minimal, compared to if you just had it at random. [00:32:02] Jeremy: How big do the files get? If I have a PMTiles of the entire world, what kind of size am I looking at? [00:32:10] Brandon: Right now, the default one I distribute is 128 gigabytes, so it's quite sizable, although you can slice parts out of it remotely. So if you just wanted. if you just wanted California or just wanted LA or just wanted only a couple of zoom levels, like from zero to 10 instead of zero to 15, there is a command line tool that's also called PMTiles that lets you do that. Issues with CDNs and range queries [00:32:35] Jeremy: And when you're working with files of this size, I mean, let's say I am working with a CDN in front of my application. I'm not typically accustomed to hosting something that's that large and something that's where you're seeking all over the file. is that, ever an issue or is that something that's just taken care of by the browser and, and taken care of by, by the hosts? [00:32:58] Brandon: That is an issue actually, so a lot of CDNs don't deal with it correctly. And my recommendation is there is a kind of proxy server or like a serverless proxy thing that I wrote. That runs on like cloudflare workers or on Docker that lets you proxy those range requests into a normal URL and then that is like a hundred percent CDN compatible. So I would say like a lot of the big commercial installations of this thing, they use that because it makes more practical sense. It's also faster. But the idea is that this solution sort of scales up and scales down. If you wanted to host just your city in like a 10 megabyte file, well you can just put that into GitHub pages and you don't have to worry about it. If you want to have a global map for your website that serves a ton of traffic then you probably want a little bit more sophisticated of a solution. It still does not require you to run a Linux server, but it might require (you) to use like Lambda or Lambda in conjunction with like a CDN. [00:34:09] Jeremy: Yeah. And that sort of ties into what you were saying at the beginning where if you can host on something like CloudFlare Workers or Lambda, there's less time you have to spend keeping these things running. [00:34:26] Brandon: Yeah, exactly. and I think also the Lambda or CloudFlare workers solution is not perfect. It's not as perfect as S3 or as just static files, but in my experience, it still is better at building something that lasts on the time span of years than being like I have a server that is on this Ubuntu version and in four years there's all these like security patches that are not being applied. So it's still sort of serverless, although not totally vendor neutral like S3. Customizing the map [00:35:03] Jeremy: We've mostly been talking about how you host the map itself, but for someone who's not familiar with these kind of tools, how would they be customizing the map? [00:35:15] Brandon: For customizing the map there is front end style customization and there's also data customization. So for the front end if you wanted to change the water from the shade of blue to another shade of blue there is a TypeScript API where you can customize it almost like a text editor color scheme. So if you're able to name a bunch of colors, well you can customize the map in that way you can change the fonts. And that's all done using MapLibre GL using a TypeScript API on top of that for customizing the data. So all the pipeline to generate this data from OpenStreetMap is open source. There is a Java program using a library called PlanetTiler which is awesome, which is this super fast multi-core way of building map tiles. And right now there isn't really great hooks to customize what data goes into that. But that's something that I do wanna work on. And finally, because the data comes from OpenStreetMap if you notice data that's missing or you wanted to correct data in OSM then you can go into osm.org. You can get involved in contributing the data to OSM and the Protomaps build is daily. So if you make a change, then within 24 hours you should see the new base map. Have that change. And of course for OSM your improvements would go into every OSM based project that is ingesting that data. So it's not a protomap specific thing. It's like this big shared data source, almost like Wikipedia. OpenStreetMap is a dataset and not a map [00:37:01] Jeremy: I think you were involved with OpenStreetMap to some extent. Can you speak a little bit to that for people who aren't familiar, what OpenStreetMap is? [00:37:11] Brandon: Right. So I've been using OSM as sort of like a tools developer for over a decade now. And one of the number one questions I get from developers about what is Protomaps is why wouldn't I just use OpenStreetMap? What's the distinction between Protomaps and OpenStreetMap? And it's sort of like this funny thing because even though OSM has map in the name it's not really a map in that you can't... In that it's mostly a data set and not a map. It does have a map that you can see that you can pan around to when you go to the website but the way that thing they show you on the website is built is not really that easily reproducible. It involves a lot of c++ software you have to run. But OpenStreetMap itself, the heart of it is almost like a big XML file that has all the data in the map and global. And it has tagged features for example. So you can go in and edit that. It has a web front end to change the data. It does not directly translate into making a map actually. Protomaps decides what shows at each zoom level [00:38:24] Brandon: So a lot of the pipeline, that Java program I mentioned for building this basemap for protomaps is doing things like you have to choose what data you show when you zoom out. You can't show all the data. For example when you're zoomed out and you're looking at all of a state like Colorado you don't see all the Chipotle when you're zoomed all the way out. That'd be weird, right? So you have to make some sort of decision in logic that says this data only shows up at this zoom level. And that's really what is the challenge in optimizing the size of that for the Protomaps map project. [00:39:03] Jeremy: Oh, so those decisions of what to show at different Zoom levels those are decisions made by you when you're creating the PMTiles file with Protomaps. [00:39:14] Brandon: Exactly. It's part of the base maps build pipeline. and those are honestly very subjective decisions. Who really decides when you're zoomed out should this hospital show up or should this museum show up nowadays in Google, I think it shows you ads. Like if someone pays for their car repair shop to show up when you're zoomed out like that that gets surfaced. But because there is no advertising auction in Protomaps that doesn't happen obviously. So we have to sort of make some reasonable choice. A lot of that right now in Protomaps actually comes from another open source project called Mapzen. So Mapzen was a company that went outta business a couple years ago. They did a lot of this work in designing which data shows up at which Zoom level and open sourced it. And then when they shut down, they transferred that code into the Linux Foundation. So it's this totally open source project, that like, again, sort of like Mapbox gl has this awesome legacy in that this company funded it for years for smart people to work on it and now it's just like a free thing you can use. So the logic in Protomaps is really based on mapzen. [00:40:33] Jeremy: And so the visualization of all this... I think I understand what you mean when people say oh, why not use OpenStreetMaps because it's not really clear it's hard to tell is this the tool that's visualizing the data? Is it the data itself? So in the case of using Protomaps, it sounds like Protomaps itself has all of the data from OpenStreetMap and then it has made all the decisions for you in terms of what to show at different Zoom levels and what things to have on the map at all. And then finally, you have to have a separate, UI layer and in this case, it sounds like the one that you recommend is the Map Libre library. [00:41:18] Brandon: Yeah, that's exactly right. For Protomaps, it has a portion or a subset of OSM data. It doesn't have all of it just because there's too much, like there's data in there. people have mapped out different bushes and I don't include that in Protomaps if you wanted to go in and edit like the Java code to add that you can. But really what Protomaps is positioned at is sort of a solution for developers that want to use OSM data to make a map on their app or their website. because OpenStreetMap itself is mostly a data set, it does not really go all the way to having an end-to-end solution. Financials and the idea of a project being complete [00:41:59] Jeremy: So I think it's great that somebody who wants to make a map, they have these tools available, whether it's from what was originally built by Mapbox, what's built by Open StreetMap now, the work you're doing with Protomaps. But I wonder one of the things that I talked about with Tom was he was saying he was trying to build this mapping business and based on the financials of what was coming in he was stressed, right? He was struggling a bit. And I wonder for you, you've been working on this open source project for five years. Do you have similar stressors or do you feel like I could keep going how things are now and I feel comfortable? [00:42:46] Brandon: So I wouldn't say I'm a hundred percent in one bucket or the other. I'm still seeing it play out. One thing, that I really respect in a lot of open source projects, which I'm not saying I'm gonna do for Protomaps is the idea that a project is like finished. I think that is amazing. If a software project can just be done it's sort of like a painting or a novel once you write, finish the last page, have it seen by the editor. I send it off to the press is you're done with a book. And I think one of the pains of software is so few of us can actually do that. And I don't know obviously people will say oh the map is never finished. That's more true of OSM, but I think like for Protomaps. One thing I'm thinking about is how to limit the scope to something that's quite narrow to where we could be feature complete on the core things in the near term timeframe. That means that it does not address a lot of things that people want. Like search, like if you go to Google Maps and you search for a restaurant, you will get some hits. that's like a geocoding issue. And I've already decided that's totally outta scope for Protomaps. So, in terms of trying to think about the future of this, I'm mostly looking for ways to cut scope if possible. There are some things like better tooling around being able to work with PMTiles that are on the roadmap. but for me, I am still enjoying working on the project. It's definitely growing. So I can see on NPM downloads I can see the growth curve of people using it and that's really cool. So I like hearing about when people are using it for cool projects. So it seems to still be going okay for now. [00:44:44] Jeremy: Yeah, that's an interesting perspective about how you were talking about projects being done. Because I think when people look at GitHub projects and they go like, oh, the last commit was X months ago. They go oh well this is dead right? But maybe that's the wrong framing. Maybe you can get a project to a point where it's like, oh, it's because it doesn't need to be updated. [00:45:07] Brandon: Exactly, yeah. Like I used to do a lot of c++ programming and the best part is when you see some LAPACK matrix math library from like 1995 that still works perfectly in c++ and you're like, this is awesome. This is the one I have to use. But if you're like trying to use some like React component library and it hasn't been updated in like a year, you're like, oh, that's a problem. So again, I think there's some middle ground between those that I'm trying to find. I do like for Protomaps, it's quite dependency light in terms of the number of hard dependencies I have in software. but I do still feel like there is a lot of work to be done in terms of project scope that needs to have stuff added. You mostly only hear about problems instead of people's wins [00:45:54] Jeremy: Having run it for this long. Do you have any thoughts on running an open source project in general? On dealing with issues or managing what to work on things like that? [00:46:07] Brandon: Yeah. So I have a lot. I think one thing people point out a lot is that especially because I don't have a direct relationship with a lot of the people using it a lot of times I don't even know that they're using it. Someone sent me a message saying hey, have you seen flickr.com, like the photo site? And I'm like, no. And I went to flickr.com/map and it has Protomaps for it. And I'm like, I had no idea. But that's cool, if they're able to use Protomaps for this giant photo sharing site that's awesome. But that also means I don't really hear about when people use it successfully because you just don't know, I guess they, NPM installed it and it works perfectly and you never hear about it. You only hear about people's negative experiences. You only hear about people that come and open GitHub issues saying this is totally broken, and why doesn't this thing exist? And I'm like, well, it's because there's an infinite amount of things that I want to do, but I have a finite amount of time and I just haven't gone into that yet. And that's honestly a lot of the things and people are like when is this thing gonna be done? So that's, that's honestly part of why I don't have a public roadmap because I want to avoid that sort of bickering about it. I would say that's one of my biggest frustrations with running an open source project is how it's self-selected to only hear the negative experiences with it. Be careful what PRs you accept [00:47:32] Brandon: 'cause you don't hear about those times where it works. I'd say another thing is it's changed my perspective on contributing to open source because I think when I was younger or before I had become a maintainer I would open a pull request on a project unprompted that has a hundred lines and I'd be like, Hey, just merge this thing. But I didn't realize when I was younger well if I just merge it and I disappear, then the maintainer is stuck with what I did forever. You know if I add some feature then that person that maintains the project has to do that indefinitely. And I think that's very asymmetrical and it's changed my perspective a lot on accepting open source contributions. I wanna have it be open to anyone to contribute. But there is some amount of back and forth where it's almost like the default answer for should I accept a PR is no by default because you're the one maintaining it. And do you understand the shape of that solution completely to where you're going to support it for years because the person that's contributing it is not bound to those same obligations that you are. And I think that's also one of the things where I have a lot of trepidation around open source is I used to think of it as a lot more bazaar-like in terms of anyone can just throw their thing in. But then that creates a lot of problems for the people who are expected out of social obligation to continue this thing indefinitely. [00:49:23] Jeremy: Yeah, I can totally see why that causes burnout with a lot of open source maintainers, because you probably to some extent maybe even feel some guilt right? You're like, well, somebody took the time to make this. But then like you said you have to spend a lot of time trying to figure out is this something I wanna maintain long term? And one wrong move and it's like, well, it's in here now. [00:49:53] Brandon: Exactly. To me, I think that is a very common failure mode for open source projects is they're too liberal in the things they accept. And that's a lot of why I was talking about how that choice of what features show up on the map was inherited from the MapZen projects. If I didn't have that then somebody could come in and say hey, you know, I want to show power lines on the map. And they open a PR for power lines and now everybody who's using Protomaps when they're like zoomed out they see power lines are like I didn't want that. So I think that's part of why a lot of open source projects eventually evolve into a plugin system is because there is this demand as the project grows for more and more features. But there is a limit in the maintainers. It's like the demand for features is exponential while the maintainer amount of time and effort is linear. Plugin systems might reduce need for PRs [00:50:56] Brandon: So maybe the solution to smash that exponential down to quadratic maybe is to add a plugin system. But I think that is one of the biggest tensions that only became obvious to me after working on this for a couple of years. [00:51:14] Jeremy: Is that something you're considering doing now? [00:51:18] Brandon: Is the plugin system? Yeah. I think for the data customization, I eventually wanted to have some sort of programmatic API to where you could declare a config file that says I want ski routes. It totally makes sense. The power lines example is maybe a little bit obscure but for example like a skiing app and you want to be able to show ski slopes when you're zoomed out well you're not gonna be able to get that from Mapbox or from Google because they have a one size fits all map that's not specialized to skiing or to golfing or to outdoors. But if you like, in theory, you could do this with Protomaps if you changed the Java code to show data at different zoom levels. And that is to me what makes the most sense for a plugin system and also makes the most product sense because it enables a lot of things you cannot do with the one size fits all map. [00:52:20] Jeremy: It might also increase the complexity of the implementation though, right? [00:52:25] Brandon: Yeah, exactly. So that's like. That's really where a lot of the terrifying thoughts come in, which is like once you create this like config file surface area, well what does that look like? Is that JSON? Is that TOML, is that some weird like everything eventually evolves into some scripting language right? Where you have logic inside of your templates and I honestly do not really know what that looks like right now. That feels like something in the medium term roadmap. [00:52:58] Jeremy: Yeah and then in terms of bug reports or issues, now it's not just your code it's this exponential combination of whatever people put into these config files. [00:53:09] Brandon: Exactly. Yeah. so again, like I really respect the projects that have done this well or that have done plugins well. I'm trying to think of some, I think obsidian has plugins, for example. And that seems to be one of the few solutions to try and satisfy the infinite desire for features with the limited amount of maintainer time. Time split between code vs triage vs talking to users [00:53:36] Jeremy: How would you say your time is split between working on the code versus issue and PR triage? [00:53:43] Brandon: Oh, it varies really. I think working on the code is like a minority of it. I think something that I actually enjoy is talking to people, talking to users, getting feedback on it. I go to quite a few conferences to talk to developers or people that are interested and figure out how to refine the message, how to make it clearer to people, like what this is for. And I would say maybe a plurality of my time is spent dealing with non-technical things that are neither code or GitHub issues. One thing I've been trying to do recently is talk to people that are not really in the mapping space. For example, people that work for newspapers like a lot of them are front end developers and if you ask them to run a Linux server they're like I have no idea. But that really is like one of the best target audiences for Protomaps. So I'd say a lot of the reality of running an open source project is a lot like a business is it has all the same challenges as a business in terms of you have to figure out what is the thing you're offering. You have to deal with people using it. You have to deal with feedback, you have to deal with managing emails and stuff. I don't think the payoff is anywhere near running a business or a startup that's backed by VC money is but it's definitely not the case that if you just want to code, you should start an open source project because I think a lot of the work for an opensource project has nothing to do with just writing the code. It is in my opinion as someone having done a VC backed business before, it is a lot more similar to running, a tech company than just putting some code on GitHub. Running a startup vs open source project [00:55:43] Jeremy: Well, since you've done both at a high level what did you like about running the company versus maintaining the open source project? [00:55:52] Brandon: So I have done some venture capital accelerator programs before and I think there is an element of hype and energy that you get from that that is self perpetuating. Your co-founder is gungho on like, yeah, we're gonna do this thing. And your investors are like, you guys are geniuses. You guys are gonna make a killing doing this thing. And the way it's framed is sort of obvious to everyone that it's like there's a much more traditional set of motivations behind that, that people understand while it's definitely not the case for running an open source project. Sometimes you just wake up and you're like what the hell is this thing for, it is this thing you spend a lot of time on. You don't even know who's using it. The people that use it and make a bunch of money off of it they know nothing about it. And you know, it's just like cool. And then you only hear from people that are complaining about it. And I think like that's honestly discouraging compared to the more clear energy and clearer motivation and vision behind how most people think about a company. But what I like about the open source project is just the lack of those constraints you know? Where you have a mandate that you need to have this many customers that are paying by this amount of time. There's that sort of pressure on delivering a business result instead of just making something that you're proud of that's simple to use and has like an elegant design. I think that's really a difference in motivation as well. Having control [00:57:50] Jeremy: Do you feel like you have more control? Like you mentioned how you've decided I'm not gonna make a public roadmap. I'm the sole developer. I get to decide what goes in. What doesn't. Do you feel like you have more control in your current position than you did running the startup? [00:58:10] Brandon: Definitely for sure. Like that agency is what I value the most. It is possible to go too far. Like, so I'm very wary of the BDFL title, which I think is how a lot of open source projects succeed. But I think there is some element of for a project to succeed there has to be somebody that makes those decisions. Sometimes those decisions will be wrong and then hopefully they can be rectified. But I think going back to what I was talking about with scope, I think the overall vision and the scope of the project is something that I am very opinionated about in that it should do these things. It shouldn't do these things. It should be easy to use for this audience. Is it gonna be appealing to this other audience? I don't know. And I think that is really one of the most important parts of that leadership role, is having the power to decide we're doing this, we're not doing this. I would hope other developers would be able to get on board if they're able to make good use of the project, if they use it for their company, if they use it for their business, if they just think the project is cool. So there are other contributors at this point and I want to get more involved. But I think being able to make those decisions to what I believe is going to be the best project is something that is very special about open source, that isn't necessarily true about running like a SaaS business. [00:59:50] Jeremy: I think that's a good spot to end it on, so if people want to learn more about Protomaps or they wanna see what you're up to, where should they head? [01:00:00] Brandon: So you can go to Protomaps.com, GitHub, or you can find me or Protomaps on bluesky or Mastodon. [01:00:09] Jeremy: All right, Brandon, thank you so much for chatting today. [01:00:12] Brandon: Great. Thank you very much.

We review Day 12 of Carabello's 12 Days of Christmas: Jubilation Blend and talk about streaming music, having different music taste than your friends, EDM, Geocities, and new cars adventures.

This week, Doug buys a soda from the '90s, Jason fills a bathtub with milk, Matt eats a hamburger, and Mike buys a used car from a man named Ling.Support the showStarting your own podcast? Use this link to receive a $20 Amazon gift card when you sign up for a paid account with Buzzsprout!https://www.buzzsprout.com/?referrer_id=1671664LinktreeBuy us a beer!Join us in Discord!DLUTI.comUnplanned PodnancyUndefined Graphics (Photography & Graphic Design)Ghoulish MortalsInquiries: dlutipod@gmail.comDon't Look Under The Internet PO BOX 6437 Aurora IL 60598

Remember your first email marketing campaign? Or maybe you're old enough to remember when "digital marketing" meant updating your GeoCities website? Well, just like those marketers who dismissed email as a fad in the '90s, there are those today who are missing the signs of AI's transformative power in marketing. Every day, I talk to marketers who are either paralyzed by AI's complexity or, worse, dismissing it as just another overhyped trend. They're making the same mistake marketers made with social media in 2008, mobile in 2010, and video marketing in 2015. The cost of waiting to adapt isn't just falling behind – it's becoming irrelevant. The challenge isn't just learning AI – it's understanding how we got here and where we're headed. Without this context, marketers risk making costly mistakes, investing in the wrong tools, or missing critical opportunities that could define their careers. That's why I'm thrilled to welcome Katie King to the show today. Katie is the author of "AI Strategy for Sales and Marketing" and has been at the forefront of digital transformation for over two decades. She's worked with global brands including Virgin, Samsung, and PwC, helping them navigate the evolution from basic automation to today's AI-powered marketing landscape. As a visiting lecturer at several universities and CEO of AI in Business, Katie brings both historical perspective and practical insights to help us understand where marketing technology has been – and more importantly, where it's going. The AI Hat Podcast host Mike Allton asked Katie King about: ✨ History Repeats Itself: AI adoption follows familiar patterns seen in previous marketing technology revolutions. ✨ Evolution Not Revolution: Understanding AI's gradual integration helps marketers adapt more effectively. ✨ Future-Proof Foundation: Historical context provides the framework for making better AI implementation decisions. Learn more about Katie King Connect with Katie King on LinkedIn Resources & Brands mentioned in this episode AI Strategy for Sales and Marketing: Connecting Marketing, Sales and Customer Experience AI in Business The Future of Lean: AI's Impact on Business Staffing Models with Chris Daigle Mastering AI: The Future of Data-Driven Personalization in Marketing with Zontee Hou World Economic Forum's Future of Jobs Report AI and Copyright: What Marketers Need to Know with Mitch Jackson Play Before Pay: Why Having Fun with AI Leads to Marketing Success with Amy Walters Start with Why: How Great Leaders Inspire Everyone to Take Action by Simon Sinek AI Work Buddy as an AI Assistant AI Marketing Primer: A Comprehensive Guide for Marketers AI Training for Businesses Explore past episodes of The AI Hat Podcast SHOW TRANSCRIPT & NOTES: https://theaihat.com/your-marketing-career-needs-this-ai-history-lesson/ Start your AI journey with the AI Marketing Primer. Brought to you by The AI Hat - Get Your AI On. Interesting in sponsoring an episode? Learn more here. AI Training for Business Leaders & Teams: https://theaihat.com/ai-training-for-business/ Powered by Magai - why choose one AI tool when you can have them all? And Descript, the magic wand for podcasters. Produced and Hosted by Mike Allton, AI Consultant & Trainer at The AI Hat, where he's tirelessly helping businesses and marketers get ahead of the AI Revolution and apply advanced technologies to their roles. He's spent over a decade in digital marketing, bringing an unparalleled level of experience and excitement to the fore, whether he's delivering a presentation or leading a workshop. If you're interested in helping business owners with AI in an upcoming episode, reach out to Mike. Powered by the Marketing Podcast Network. Learn more about your ad choices. Visit megaphone.fm/adchoices

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.

Lorelain ja lumen väliseen rakkauteen tulee ryppyjä, kun ensilumi sotkee kaiken majatalolla ja hänen autonsakin jää kinoksen alle. Richard ja Emily hoitavat pihallensa hortoillutta koiraa, ja Christopherin isä kuolee. Lorelai päätyy valehtelemaan Lukelle, koska hän ei halua paljastaa viettäneensä humalaisen illan Chrisin kanssa tätä lohduttaen. Anski ja Sanna eivät malta olla puhumatta Monty Pythonista, vaikka siihen liittyvät viittaukset onkin käsitelty jo moneen kertaan. Lisäksi kaksikko muistelee musiikkivideoiden kulta-aikaa, melodisia soittoääniä ja Geocities-sivustoja.Osioiden aikaleimat:Kirkin kirjakauppa ja teatteri: 00:08:45Luken kuppila: 00:56:01IG: Gilmorettajatwww.gilmorettajat.fiEmail:gilmorettajat@gmail.comPatreon:www.patreon.com/gilmorettajatCover art: Kristófer Knutsen (IG: @kristoferknutsen_photography)Kirkin musiikki: https://www.purple-planet.com

En 1999 me encontraba cursando mis primeros pasos en la facultad y comencé a llevar una especie de diario en él que escribía sobre las diversas cosas que me ocurrían, aunque las disfrazaba como otras historias. Dichos textos fueron el puntapié inicial para dar lugar años más tarde al blog, aunque nunca fueron publicados allí y sufrieron el juicio del fuego. Pero sin ellos nada de esto existiría, así que dada la primera publicación en las viejas Geocities de Yahoo en el año 2004 es un buen momento para recordar el primer ladrillo en el muro. ¡Continúa mientras se escribe!

Hear from tech pioneer and philanthropist David Bohnett discuss the transformative impact of technology on organizations and society. David, co-founder of the groundbreaking early web platform Geocities, shares his journey from a Business and Computer Science major at USC to selling Geocities to Yahoo for a staggering $3.5 billion in 1999. Plus we tackle the role of social media in voter education and registration and where AI fits in to the current technology landscape and the broader impact it can have on ATOs.

In this episode we search out evil in the highest office of the land of freedom from FDR to his polar opposite, Ronald Reagan.Cameo guest stars include, Gerald Burton Winrod, The Antichrist and the Atomic Bomb, Concerned Christian, Kim Miller, big pharma, Harry S. Truman, George Bush, George E Lowe, Stalking the Antichrists, Gabriel J Cola, Unmasking the Beast, The Second Reign of JFK, Armageddon, Revelation, Qanon, Dealey Plaza, Dallas, Texas, Donald Trump, JD Vance, Hunter S Thompson, Richard Nixon, Oval Office, Billy Graham, Hollywood, Knute Rockne All American, The Gipper, Notre Dame, The Four Horsemen, California, Maryland, 666, Pick 3 Lottery, New Jersey, GeoCities, Xerox, Administration's Fiscal Year 1983 Economic Program, The 97th Congress, Budget of the United States Government, Bill Clinton, 1600 Pennsylvania Ave, Malibu, Porsche #666 #SketchComedy #Sketch #Comedy #Sketch Comedy #Atheist #Science #History #Atheism #Antitheist #ConspiracyTheory #Conspiracy #Conspiracies #Sceptical #Scepticism #Mythology #Religion #Devil #Satan #Skeptic #Debunk #SatanIsMySuperhero #Podcast #funny #sketch #skit #comedy #comedyshow #comedyskits #HeavyMetal #weird 

I stumbled across a few towing news websites I hadn't seen before. Without surprise, the majority of stories were negative but we found one good story about a tower in Georgia. We discuss some of the tops stories we found on these Geocities era websites. Miller Industries Traxero Harbinger Marketing HAAS Alert Safety Cloud ERSCA

Icicle?! This week, Emily and V hold a sort of jazz funeral for a fandom event that shaped both of them as human people, and that cannot and should not ever happen again. The Three-Year Summer was a pivotal stretch of time for fandom culture as a whole because a) every fucking person alive was in this fandom, b) the whole point was that there was no canon and the world was wide open for the taking, and c) the Internet was young enough that you could claim ANYTHING on that shit. And we all did! And we all believed each other about it! It was amazing! It was fresh and new! And it has been tainted forever! We completely understand if you do not want to listen to an episode about Harry Potter. We get it. We'll see you next week.

Jem and Justin chat about configurator orders, HSK holders, and motivation. They cover software changes, AI advancements, and Profit First financial updates. The pair touches on creativity, skating, and the concept of play.Watch on YoutubeDISCUSSED:✍️ Send Comments on this Episode 4 config orders in a week ❗️HSK 63F Holders in-processHow many times per week do you have 'stuff this' thoughts?Motivation, direction.Power DumpSkating and creativityAndy AndersonPlaySoftware cornerDumped Adobe and ChatGPTCrawling back to LightroomCapture OneSimTheory AIFluxiOS 18 transcription promiseSo ready for AI SiriConfig DIY a year later - GeoCities here we come!PFAdded Timing and Capital / Repairs Investment accountsSofa accounting6 months in report from LBXero vs 'real' numbers---Profit First PlaylistClassic Episodes Playlist---SUPPORT THE SHOWBecome a Patreon - Get the Secret ShowReview on Apple Podcast Share with a FriendDiscuss on Show SubredditShow InfoShow WebsiteContact Jem & JustinInstagram | Tiktok | Facebook | YoutubePlease note: Show notes contains affiliate links.HOSTSJem FreemanCastlemaine, Victoria, AustraliaLike Butter | Instagram | More LinksJustin BrouillettePortland, Oregon, USAPDX CNC | Instagram | More Links

"The White House, repeatedly pressured our teams for months to censor certain COVID-19 content, including humor and satire." Warning: This show is extremely political. It has to be. There simply is no way to discuss the topic without being political. Just the same, the core of the topic is regarding the usability of digital, online publishing and messaging platforms -- a topic near and dear to the heart of those of us who have lived through the ages of the BBS, Usenet, Geocities, and the like.More from The Lunduke Journal: https://lunduke.com/ This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit lunduke.substack.com/subscribe

The internet is a vast archive of unsolved mysteries. By this week's campfire, Edwin investigates the Cicada 3301 puzzle, and Michelle tells us about the time traveler known as "John Titor".Do you have an idea for an episode theme? email us: hello@campfirestory.comGet ad-free episodes and support the show at CampfireStory.com Hosted by Michelle Newman and Edwin Covarrubias. Episode edited & sound designed by Sarah Vorhees Wendel of VW Sound

The Ballad of John D. Cort continues with an episode of Baywatch called "Old Friends." Mitch, Craig, and Garner take a few days off to hang glide in the Santa Monica mountains. Well, Garner is more interested in reading and dozing. But when Mitch crashes into a tree, gets bit by a snake, and subsequently falls into a quarry, it's up to Craig and Garner to get him out of the wilderness. Meanwhile, Cort is reminded of a friend who died a year earlier. But when he visits the widow, he gets the sense things may not be as it seems. Will it turn out he was a patsy all along? Erik and Justin realize Baywatch's time has passed. They also call for the return of Geocities and webrings. Colonial Marine Trevor Wierzbowski becomes an unlikely mascot. Mitch's fall down the cliff becomes the lynch pin of the entire outing. The love fest for John Allen Nelson continues. Captain Thorpe makes a very special appearance. David Hasselhoff's ego gets examined. Manwë joins the pantheon. A brief guest turn by Hope Marie Carlton leads well into the weeds. Garner's glamping is praised. Mitch ends up being the worst character and a snake turns out to be the hero.

How did we go from people being scared the Y2K Bug was going to close banks to me buying a gadget I didn't need from TikTok? #TikTokMadeMeBuyIt I decided to go back in time. And I'm taking you with me. Do you remember what your first digital platform was? Mine was GeoCities - iykyk. Helpful Links: Read on the blog: https://blog.vannesiadarby.com/from-dial-up-to-dms-humble-digital-beginnings  Join the Speak Life Newsletter: vannesiadarby.com/subscribe

Talking Points: Mice in Missles, Soak A Bond, Jomblow I Choose You, Gaslighting Grandpa, MC Has A Mortgage, Don't Scream At The Cryptid, Quarterly Stephening, Sending Medical Diagrams, Can I Replace You, I Am The Giraffe, Summon A Bed, Conker's Coming  If you'd like to watch the show live, join us on the first Tuesday of every month over at Twitch.tv/ProtonJon at 9pm EST.

We did it Reddit! We watched 36 episodes of anime and 36 episodes of Americanimation and even podcasted about it. We're joined by the only person we know who's watched all of Robotech, Sanga, for some brand new viewpoints! And together we explore the complicated and messy finale of both shows, and the Venn diagram of messiness between them. This is one of the longer ones we've had in a while, and it's not just because we spend the ending looking at some old horrible Geocities fansite (which I will not be linking because of the doxxing!!!).In other news I'm finally going to put the song list at the bottom here! Please send us your rankings for the ultimate RANKING OF MINMEI we would really appreciate it! (There's one songs we haven't seen yet from the movie but hey get a head start!!)Join us next time for DO YOU REMEMBER LOVE and Codename: Robotech! Please only watch the former if you're following along lmao. Standing Ovation: https://i.imgur.com/8J2jN1N.pngSDF 2: https://i.imgur.com/8J2jN1N.pngOh hey the Kickstarter is open give Grant money: https://www.kickstarter.com/projects/foxbot/the-disappearances-of-lydia-fountayne?Ranking of Minmei Song List: https://docs.google.com/document/d/1ucm813JmA4JkLcLnztY7hjWuUXbd0Unelj27XxMh4vA/edit?usp=sharingPlease send your list to our email: doyourememberrobotech@gmail.com Hosted on Acast. See acast.com/privacy for more information.

Christina Warren joins Jason Howell to talk about how nostalgia for the early Internet and failed technology companies has permeated her life in tech. From developer advocacy at Microsoft and Github to working in the tech journalism trenches at Mashable, Christina has stayed passionate about the possibilities of tech and its limitations.Please support our work on Patreon: http://www.patreon.com/JasonHowellChristina's experience of accidentally not hitting the "go live" button at the start of the interview, and the importance of redundancy in recordingHer early memories and passion for technology, sparked by video games, gadgets, and the internet in the 90sBuilding her first website on GeoCities as a 12-year-old unpaid "community leader"Her collectibles obsession, including shoes and merchandise from failed/infamous tech companies like Theranos, FTX, Pets.com etc.Reminiscing about the spectacular dot-com boom and bust, and companies like Webvan, Pets.com that didn't surviveDiscussing the decline of TiVo and how the DVR experience has arguably gotten worse over timeHer current role as a developer advocate at GitHub, and how to follow her work Hosted on Acast. See acast.com/privacy for more information.

Os novos iPads não são para a Bia, e o Marcus quer saber: como manter a produtividade quando o foco está em baixa?

Iceberg right ahead! This week, V and Emily plumb the depths of the entire world's massive Titanic fandom and its accompanying "Leomania." James Cameron's Titanic was impossible to ignore in 1998 -- from the cinema to some weird video store in Utah, from middle school dances to the Oval Office, from the pages of Vanity Fair to the wilderness of GeoCities, Jack Dawson and Rose DeWitt-Bukater were inescapable. So grab your Jewel of the Sea knockoff necklace, polish off your Céline Dion CD, and rewind VHS1 of your two-tape box set. Are you ready to go back to Titanic?

A creepy question for Caitlyn Clark, launching an album on Geocities, the 'You're Not Real' woman is back and she's in a bikini, 911 goes down, the shock talk tactic, a coast guard rescue, your first time driving, the hot dog eating president challenge and so much more!

In this episode we reminisce about how things used to be done and how much web development has changed in the last 25 years. From under construction gifs to the rise and fall of jQuery we cover it all. GeocitiesTable based layoutsFloat based layoutsClearfix.clearfix::after { content: ""; clear: both; display: table; } Equal Height columns Matchmedia.jsConditional commentsstar selector hack ('star plus html) css hack.Microsoft Kicks Off Campaign to Kill Internet Explorer 6Microsoft anti-trust lawsuitImage Ready - slicing designWYSISWYG (drag and drop) html editorsMacromedia DreamweaverMicrosoft Front PageAdobe Go LiveAdaptive Design (not responsive design)Fluid Layout (CSS tricks article)Rounded corners with sliding doorsImage SpritesCufon FontsNavigation tabsCSS Zen GardenBlink, Marquee (blink no longer works despite what Sean said in the show. However, the marquee tag does work)Sean's Boilerplate (Season 7 Episode 5)Animated gifsUnder construction animated gif1TB archive of Geocities (article) Web ringsJavascript jQuery Mootools Show Links More Website 101 Podcast Email the Podcast! Twitter Sean on LinkedIn Mike on LinkedIn Amanda on LinkedIn

Hosts Victoria Guido and Will Larry are joined by Trent Walton, CEO of Luro. Trent shares his journey into the design world, from his early fascination with typography and logos to co-founding Paravel. This agency later evolved into creating Luro, a no-code solution for building design systems and tracking their adoption across products. Trent emphasizes the importance of understanding the materials one works with in design and development and stresses the need for a holistic approach to product building. This approach blurs the lines between disciplines, encouraging a generalist mindset over specialization. Luro, as a product, stemmed from the realization that existing design systems often fell short in adoption and application, leading to a search for a more integrated and comprehensive solution. Trent outlines the functionality and vision behind Luro, explaining how it serves not just designers and developers but entire organizations by fostering better collaboration, documentation, and understanding of design decisions. Luro aims to streamline the creation and maintenance of design systems, making them more accessible and manageable, even for teams facing resource constraints. By incorporating performance, accessibility metrics, and the ability to track component adoption and integration, Luro provides a platform for continuous improvement and alignment with organizational goals. Luro (https://luroapp.com/) Follow Luro on LinkedIn (https://www.linkedin.com/company/luroapp/), YouTube (https://www.youtube.com/channel/UCsS9BEmX1NPBXkbaLGcMZlw), Discord (https://discord.com/invite/aNEdjnR6A5), or Instagram (https://www.instagram.com/luroapp/). Follow Trent Walton on LinkedIn (https://www.linkedin.com/in/trent-walton/). Visit his website at trentwalton.com (https://trentwalton.com/). Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Transcript:  VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. WILL: And I'm your other host, Will Larry. And with me today is Trent Walton, CEO of Luro. Luro is a no-code solution to build your design system and track adoption across your entire product. Trent, thank you for joining me. TRENT: Oh, thanks for having me. It's great to be here. WILL: Yeah, I can't wait to dive into Luro and get to know more about the product. But before we go into that, tell us a little bit about yourself. I know you're based out of Texas. TRENT: Yeah, I grew up, lived here my whole life. I'm in Austin with the other co-founders, Dave and Reagan. Been a designer probably all my life, always been interested in, like, typography and fonts. When I was little, I used to buy badges for cars from swap meets and take them home, not because I needed, like, I had a car I was building and had any interest in, like, sandblasting or building an engine. I just liked the typography, and the design of the icons, and the logos, and all that kind of thing. And so, now it's evolved into me just being, like, a type aficionado and a graphic design aficionado, and then that evolved into, especially when I discovered the web in the early 2000s, building and designing websites with Dave and Reagan, who I mentioned. And so, we had an agency called Paravel early on and had a lot of time putting into practice kind of that design and development and building for the web. VICTORIA: So, your first interest in design came from, is it a car engine? Is that what I heard? TRENT: Well, yeah, my father is a mechanical engineer, and so is my brother. And they work on cars, have classic, like, old Mustangs and Cobras and things that they build in their spare time. And I have no interest in that kind of work [laughs] but grew up in that environment. And, you know, pre-internet growing up in the '80s, one of the things that really got me was the aesthetic and the design around those kinds of muscle cars, so, like, old Shelby or Cobra or Mustang Ford ads, just, I really got into that. So, I'd buy, like, car manuals for a few bucks, or if there's a Mustang Cobra and there's a cool, like, chrome snake logo with a condensed uppercase typeface or some sort of lettering that says, you know, "Shelby Cobra." And that's when I realized [laughs] where my interests lie. You know, engines are cool. They sound cool. Fast cars are cool. But I was just totally, you know, enamored with the typography and the design aspect that surrounded those things, and then it just kind of evolved from there. Anything else I could get my hooks into, I picked up on. VICTORIA: I love that because when I talk to people about design, for folks who don't have a background in it, they kind of think, oh, design, that's logos. You know, I'm redesigning my house right now. My husband is like, "Oh, it's picking the tiles and the colors. We can do that." And I'm like, "No, like, design, there's a lot more to it. Design is everywhere." Like, you can find design inspiration from car manuals [laughs], it's so funny that you bought those, or from random logo design and actually, like, really good design. If it's something that's designed well, you probably don't even notice it. You just flow and use the space or use the app as you're intended to. TRENT: Yeah. And I also think that getting inspiration or starting ideas out from anywhere but the medium you're working in might be a nice little trick to bring some, like, naïve, fresh perspective to things. So, I try to go back to that stuff as much as possible. I have heaps of manuals I've bought off of eBay in recent years, yeah, things you wouldn't think you'd find on, like, you know, whatever, a graphic designer's bookcase, just anything to sort of break the monotony or break my own little lenses of what a website should look like, or what a logo or a brand should look like, how to step outside of that a little bit. But it's funny because it really does go back to that initial sense of wonder I experienced at those really just, you know, we're talking, like, in a gross, swampy field in Texas with, like, funnel cakes being served at every corner, like, not the most slick, rad graphic designy vibe, but that's where it all started for me. So, I go back there as often as I can [laughs]. VICTORIA: So, how do you talk to founders or people who are thinking about building products? How do you talk to them about design and give them a where to get started approach? TRENT: I don't know that I ever specifically talk about design or even maybe, like, engineering or about performance. I talk about all those things, accessibility, et cetera. I try to blur those lines as much as possible. It's maybe an idyllic thing that I've had for years. But going back to the agency days, I'll call them the agency days, but up until, like, you know, 2015, '16, Dave, Reagan, and I ran an agency called Paravel. And by nature, the three of us are some sort of a hybrid between a designer, maybe, like, a front-end developer. You know, Dave's more of an engineer now. But we've all been very careful to make sure that we're generalists, which I don't know that that, like, career-wise that, might pay off long term, but I cannot work on the web any other way or talk about the web any other way. I've always felt like, I mean, there was the old, which we don't have to get into, gosh, but the debate on should designers code? But I think the essence of that is really, like, should we be familiar with the materials we're working on? So, anytime I start to talk about designing for the web or designing a product, you want to make sure everyone has a clear understanding of the environment that they're working with. So, is it, you know, a website? And is performance important? And is our site that we're redesigning is it performant now? Is it fast or slow? Or am I a designer who only cares, and this is a thing that I have to fight inside of myself all the time? So, I'm not trash-talking anybody, but, like, do I want to load a bunch of fonts and cool images, and is that my KPI is how interesting and engaging the visuals are? Which is a great one to have, but it also, you know, while you're talking about design, you have to consider all of these other things that can define quality for an experience. Maybe those other things don't matter as much from one person to the next. But the more they are in front of me, the more they evolve the way I perceive what I work on. And so, I try to never really isolate any kind of aspect into maybe, like, a stage or a sprint that we're doing as a team. It's just sort of this holistic kind of hippie vibey way to look at sites, but I want to make sure that it's always, like, we're always starting from a very, very broad place that involves every aspect, and all team members and stuff like that. VICTORIA: Well, I love that because I try to think about that in the same way from the other end, like, on the operations perspective when you're talking about site performance. And, you know, like, is the site responding fast enough? And it comes back to the question of, like, well, what is the experience, expectations of the user? And what's important to get done on the site? [laughs] And having those conversations, like, early on and integrating all these different teams from the design and development and operation side to have that conversation so everyone knows what is the goal of the site and what is the important aspects of the user experience that the system needs to be able to support? So, I also like that you said that it's like, well, should you be familiar with the materials that you're using? [laughs] Thought that that was really cool. Like, I'm actually...my husband and I are renovating our home. And I'm talking about why we should invest in design [laughs], and part of it's because there's things to know about the materials. Like, if you're choosing a floor for your house, like, the designers will know, like, what's the durable ones? What's the ones that are going to fit your need, and your cost, and your budget? And so, like, they don't necessarily need to be a person who's going to lay the floors [laughs], but they need to know what to expect out of what you decide to use. TRENT: Yeah, it's, like, all of these constraints. And so, being familiar with the real-world implications of the decisions we make, you know, inform that. So, yeah, I mean, I think that's pretty similar, too. It's like, well, you need this floor because it's more durable in this climate or whatever, same thing for, you know, the websites that we build. It's all contingent upon the outcomes that, hopefully, we can mutually agree on. You know, there's kind of a general sense of, like, performance is important, and accessibility is paramount and extremely important. But then there's some nuance to that as you get into some smaller decisions. So, having these kinds of discussions early on and frequently and almost...the way I like to think about it is rather than, like, a check-in where we say, "Okay, this is it," but having a place where we can all look to check in and find information and share information that's maybe not so fast. One thing I like to think about is things get lost in chats and maybe even tickets, so as you're closing tickets and opening tickets. There's a bug. I solved it. It's gone. Can you send me this logo? Can we tweak this? These micro changes they open and close very, very quickly. And so, there's this firehose that happens. And so, I find that having a place separate from that for discussing these things and remembering these things, and referencing these things while we are in our code editors or inside of our Figma or any kind of design tool that we use to sort of cross-reference and simmer on things as we think about the decisions that we have to make, as opposed to just knocking them out super quick, always being mindful of those constraints. And again, yeah, the [chuckles] materials we're working with, whether it's just, you know, HTML, CSS, and JavaScript or whatever, but all of those things. It's good to be mindful of that. WILL: I know you said that you've been in design for a while, and so I love just picking the brain of someone who's been into it a while and see how far we've come from, especially just the 2000s. So, in your opinion, with design, how do you feel about where we've come since the beginning of tech to where we're at now and, also, I guess, where we're going with the design? TRENT: Yeah. So, I guess I can really just frame...this is going to help me remember just framing [laughs] where we were. I started off on Homestead, which is sort of like GeoCities. I was in college. I graduated, and I think it was 2001, maybe 2000, anyways. And it was mainly just taking images...I didn't even have Photoshop at this point. And you realize you could, like, tile a background for a build your own website. Homestead was one of those kinds of deals. And I thought that was very interesting. So, I had this cheap digital camera. It took a lot of cords to figure out how to, like, port that onto this old, crappy Hewlett Packard computer that was, like, a hand-me-down. Fast forward a couple of years, I had graduated, did not study design, so I'm all kind of self-taught or just taught by the web, the peers, the information that has been shared and been influenced by. But Dreamweaver was out, and Macromedia was huge, and I loved Fireworks. And so, Dave Rupert, I paid him $80 to teach me HTML [laughs], and so we've been together ever since. This is right out of college. And so, the tools that we used there were pretty rudimentary, but Fireworks was rad. Like, it was kind of web-based. It felt like it made more sense. I love Photoshop, and that's kind of, like, a primary graphic design tool that I still use to this day. But early on, it just felt like everything was so harshly limited. So, if you had any kind of idea that you wanted to execute that you could just draw on a piece of paper, mock it up in Photoshop, the amount of work that you had to do to get that to happen was either extremely high, or it was just impossible. And then, if it was impossible, I bet you can guess what we did. We went to Flash, and we made, like, a crappy video of a web page that was not accessible and really hard to use. I was heavy into Flash for, like, two or three years until kind of, as I had been warned by Dave that, you know, HTML and CSS are going to be the way the web works. But when I came back to that, there was this wonderful time where it felt like we were charting out every single...it was just new territory. It's like we had come to this other planet or this other world, and everything that needed to be done, we had to figure out how, like, getting web fonts onto pages, rounding borders. I mean, getting that done aside from slicing images in Fireworks felt like this new monumental discovery that changed the lives of many. Maybe it did, maybe it didn't, but in my world, it felt like that. And so, early on, you can look back on it and go, gosh, everything was a pain in the ass, like, living with all of these limitations. But for me, I do look back at it like that, but I also look back on it as this wonderful time where we were building the web that we're working on now. So, all these things that make designing easier and quicker come with some sort of a, you know, an evolution of your perception, and [inaudible 13:14] fond memories of work along the way. For me, it's sort of I've just always sort of been around working on the web and watching design evolve, and every little step maybe feels like a tiny one or a large one. But these days, it just seems like, oh, this is exactly how it should have [laughs] always been, like, convenient grids and convenient box shadow and all that kind of stuff. But yeah, it's been nice to sort of grow up only being a web designer. Like, I mean, I've done graphic design. I've done brochures and, print design, and logo design for sure. But, I have always been anchored to and centered around web design and thinking about things in the context of how they will be applied to the web first and foremost. MID-ROLL AD: Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you're tight on time and investment, which is why we've created targeted 1-hour remote workshops to help you develop a concrete plan for your product's next steps. Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. Find out how we can help you move the needle at tbot.io/entrepreneurs. VICTORIA: So, what was the turning point for you that led you to found Luro? How did it all get started? TRENT: With Paravel, the agency days, we had a lot of fun. I think, for us, our big agency spike was when responsive web design came out. Ethan coined the term. There was a lot of people on the web, you know, a lot of agencies or a lot of teams, a lot of companies that needed to pivot into that. And so, we found this great working relationship with companies where we would come in and sort of had a little bit more practice just because we got in early learning kind of how to do that well, I think. And it was a sort of we're going to redesign a page, a homepage perhaps, or, like, a marketing page. You'll do that project; three to six months go by. And then the next thing turns into, well, we have this giant network of e-commerce stores. We have this giant network of pages with, like, download centers and support documents. And now, we need to make everything responsive, and it can be anything. We need to make everything accessible. We need to make everything performant. We need to update the brand on everything. And I don't think we're alone in this. I think this is the beginning of the greater design system discussion as it applies to the web. Obviously, design systems predate the web; design systems pre-date, like, 2012 or '13 or whenever we got into it. But projects started to migrate from, "Hey, can you design this really amazing, responsive marketing page," to "We have a system, and we need you to solve these problems." We love working on those problems. I still do to this day. But the reason why we switched from kind of being a, you know, individual contributor-type agency consultant type roles to building a SaaS product was because we were realizing that things got complicated...is a very, like, boring way to say it. But to get a little deeper, it was, we would see things not ship. So, like, our morale went down. The teams that we were working with morale kind of went down. And as I was digging into why things weren't shipping...and when I mean ship, I think, like, pages would ship, of course. Like, here's a page. It just needs to be built, somebody decided, or a new feature needs to be built. Of course, those went out. But the idea of, is our design system or the system that we're designing launched? Is it applied? Is it fully adopted? Is it partially adopted? It never felt like the amount of traction that we were promising or that we were being asked for. And I don't mean we, as in just the three of us, but the entire team or the entire organization who, in many cases, all were bought into the idea of design systems. So, what we found was, when things got real, and we had to give up things, and we had to work on things and prioritize things, it became much more difficult to work in that capacity, probably partially because of the cross-discipline nature of those things. So, as opposed to what I consider maybe a miserable way to work in many cases, is the classic; here's my Photoshop comp. And I have a red line document JPEG that I will give you, whatever engineer I'm working with, or it's myself, and I'm just giving myself a red line document, but you're just going through and trying to make those things match. And that is sort of not fun for the team because now we're just sort of chiseling each other and sort of, like, going through and critiquing our work over and over versus really kind of in the spirit of prototyping and inventing together. I find that products are diminished when you do that. So, as you try to get into this design system part, it requires a lot more insight into what everyone around us is doing, kind of, as I was saying at the beginning, how to have this cross-discipline view of what we are actually working on. And that view is what we thought, and we still believe in many cases, is absolutely missing. So, you can spin up a design system. And Luro is not the only design system tool. Of course, you can spin up your own. And what I mean by that is, like...I'm maybe going to answer, like, three questions in one. Maybe you haven't even asked them yet. But just to kind of frame this, if you ask anyone what a design system is, it might be a different answer. It might be these are my Figma components that I've created and I've shared out, and there's a public link. You know, an engineer might say, "Well, it's the GitHub repo of components that I'm actually using." So, the design is helpful as documentation. But the design system is the code, or the design system is the actual...or the actual components that are live that users see, which I would argue probably is the most accurate, just because we're talking about user experience impacting whatever business objectives we may have. So, those components need to make their way into live sites or products. So, finding out what that answer is, what's the source of truth? What is our design system? What are our components? What are our standards? You have to have multiple sources for that, just because there's multiple people with multiple opinions and multiple measures of success involved in those. And all of those opinions and measures of success, I would say, are valid. So, accounting for those and kind of crossing the streams, if you will, in one sort of central UI, we believed was crucial enough that we should jump out of the agency days and into a product-building scenario. VICTORIA: That's really interesting. So, you saw this pattern in the delivery of your work as an agency that made you want to build a solution to create better outcomes for a potentially exponential number of clients, right? [chuckles] TRENT: Yeah, hopefully. I think that working on how you work together as a team is vitally important, and if you can find the right environment, then the actual product will benefit. I mean, and I'm not even just thinking about these maybe soft things like, oh yeah, if engineers and designers can work together, the typography will be a little bit better, and the site will feel a little bit more cohesive, and it'll be maybe a little bit easier to digest. I believe that. But I also believe that there are people in organizations doing research, financial analysis, customer analysis, A/B testing, you know, all sorts of work that contributes to the decisions that we make about our sites and products that sort of just gets lost in the shuffle, in the firehose of the day to day. So, having something that takes not only a, I guess, what you could classify as the what for a design system, it could be the design of a component. Maybe it's actually even, too, as well, the code that makes up that component. But then there's this giant why. Why does the button look the way that it does? Why does a card have a border around it? Why? Why? Why? Why? Why? These things maybe they come up during meetings. Maybe there's something that, as a designer or an engineer, I found maybe on the company's shared OneDrive or somebody mentioned in passing. Those things are vitally important, and they need to be, again, back to the morale and perception evolving; they need to be accessible to everyone. But it's a needle-in-a haystack situation. It's funny. We would consult. And one of my favorite stories is we were building this prototype. We were hired to build a prototype for a startup in Austin. They were on a big, open floor-plan office with the glass meeting rooms. And we were showing off our prototype, and we just felt really clever and witty about the way we were going to solve this and the pages that we were going to build. And who is a friend now, a person named Angela walks by, and she's like, "What are you working on?" And we told her what it was. And she says, "Oh, wow, you know, six months before you started contracting with the startup, we did this all, and we've user-tested it. Everybody's been reorged, and nobody remembers. But I have this PowerPoint I can send you, and it will show you the results. Some of these things you're doing are probably going to be great. The other things you should absolutely not be repeating these mistakes." And I thought about how likely it was that she walked by and happened to see that through the window and happened to look on the sharp television on the wall. And it's probably not very likely, and as we become, you know, we're remote and working remote the likelihood of those things happening maybe goes down. The idea of building a product that increases the likelihood or almost makes it seamless that you can find information relevant to what you were working on, even if you're new to that project or you haven't worked on it for a long time, is very, very key. So, within Luro, you can build a design system. You can add your styles. You can add your components, configure your tokens, and do all that, but you can also integrate those things that I was mentioning: prototyping, research, and testing. We also do an accessibility and performance through Lighthouse and give you metrics there. All of those things are associated to the pages that your site is comprised of. They're associated to the components that you use to build everything. So, we're sort of crossing the streams here. So, if you're going into imagine a button component and you're like, okay, the border-radius is four pixels. The type size is 16 pixels, and here's how you code it. We're putting in an actual button. The class is dot btn. That's all great. It's helping us build the button. But if you are asked by leadership or anyone, "Why did you decide this?" Or "What is the impact of design?" Or "What is the impact of the product team on our bottom line? How are you moving the needle? How are you helping us as an organization achieve?" The answer isn't, "Well, we made the border four pixels just like the design [chuckles] said." That's great. Good job. But I think having all of this information associated with design and associated with engineering not only makes us more informed as contributors to teams but it helps us to articulate the value of what we do on the daily in a much more broad organizational sense. So, you can say, "Well, we user-tested this, and we realized that if we took out these form elements from a signup flow, we get more signups by having fewer steps. And so we removed a step. We user-tested it before and after, and signups went up 30%." That's a much cooler answer than, "Well, our design system helps us be consistent," even though we know that that is vitally important, and it makes our app or our site feel much more cohesive, and it contributes to that sign up metric or a sales metric just as much. But having this data and associating it with a component so it's not something that you have to sort of...I guess it almost sounds subjective if you bring it up and say, "Well, we're moving faster, and we're selling more stuff." That's not great. But if you can link and say, "Well, here's a PowerPoint before," or "Here's a summary of a user test before and after. Here's real numbers," it helps you to portray yourself as the designer or engineer or product team member who thinks very deeply about these things, and it helps you to accurately portray yourself in that way. So, I went on a real tangent, but actually just there, I think I just was describing sort of the nuts and bolts of why we built Luro to not only be a design system tool but, like, what we kind of also call a product development tool, a product development system. So, it's extending the idea of design systems to the practice of building a product with an entire organization. WILL: That's really, really cool, and you did a great job explaining it. I'm excited to see it and see where it's going. I felt like a lot of what you were saying was the why you're doing stuff, why you chose, you know, X, Y, Z. Is that where the analytics and the tracking portion of Luro comes into play? TRENT: Yeah. I think that one thing we heard a lot from agencies or even just teams within an organization that are working on design systems is back to that articulating the value of maybe a design system or articulating the value of the work that we do as designers or product builders and similar to we've done a user test and these are the results, and sales or signups, or whatever the case may be, have improved. I think one of the key metrics for a design system is, is the component adopted? There are other ones, and people will mention those, things like, is it helping a team be quicker? So, if there's a design system team, and then there's multiple product teams within an organization, and they all want to work together, and they want to be able to take the components that they need and build their ideas quicker, prototype quicker, that's a great metric as well. But one that we find vitally important is, are the components live to users? And so, being able to track that has a lot of value. One, obviously, is that communicating that to the greater organization, saying, "You know, we've spun up a design system team. The card component is on 49% of pages. The button is on 100% of pages." And then if you're trying to be more tactical about how to improve the product or even just track down, you know, which components or which pages or which experiences aren't, I guess, consistent with the design system, you can say, well, "There's 49%, and there's 51% of pages that may or may not have the card component." And so, you can go find outdated components if you're trying to phase new ones in, and all of those sorts of things as well. So, the metrics are sort of great from a thematic sense, saying, this is the value that our design system is, you know, affording us as a business and the users are experiencing while they're using our app or our site. But then, also, you can drill down into these metrics and see, okay, the button is appearing here. I can click into pages and see views where it's being used on the page level and see, is it being used properly? Those kinds of things. You can track legacy components as well, so, for example, if we've rebranded the site that we all work on together and our old button was, like, dot button and the new button is dot BTN or however we would want to class those things. And you can use classes. You can use data attributes, all those kinds of things. But I would say we can track legacy along that. So, if your goal is to completely adopt the new design system across the entire network and products within six months or whatever the case may be, you know, month over month, week over week, you can check our, you know, line graphs and see, hopefully, the legacy occurrences of that going down over time. So, if, like, the button is being used less and less and then the dot BTN is being used more and more, you can see those sort of swap places. And so, what we have found is talking about things in sort of an objective or fuzzy way, saying, well, we're trying to ship this, and we're doing these inventories, and we're going through all the pages. And we're clicking around trying to find old things, or we're redesigning pages. But it's very, very difficult. This is just an instant quantification of where our components are manifesting in the product. So, what we do is, with Luro, you can give us...whether it's behind an authentication layer or not, we crawl web pages, first and foremost. So, you can give us a site. And this is all optional. You can spin out a design system without this. But we crawl the site, and then we will go ahead and do performance and accessibility scores for there. So, that's one way to itemize work, where you can just say, well, as an agency, we're going to work with this company, and we want to show them, like, the starting point and expose weak points on where we might be paying a lot of attention to. In the design or engineering phase, we need to improve the speed here. We have accessibility violations we need to think about, all that kind of stuff. And then, once you crawl those, you can add your design system, and then you can cross-reference those, and I kind of mentioned that. You can use CSS classes to do that. And so, you'd enter in dot BTN for button. We've already crawled your pages. And so, we can tell you every time that that class appears inside of any page inside of the network. So, it's this very, like, two-minute way to get a wealth of information that's shared and communicated with...the entire organization will benefit. Like I said, like, leadership they can get a sense of how the design system is being used and adopted, but also, the active teams working on things so that they can go find outliers and work on replacing those. VICTORIA: It's been over a year in your journey with Luro. What challenges do you see on the horizon? TRENT: I still think it is an adoption challenge. I think that, you know, one thing that we found is that a lot of teams, and this is going back to our agency days, but I sort of sort of still see this happening now is that building the design system, you know, let me separate these two things. I think designing components and building the design system in the sense of picking styles, and choosing fonts, and iterating upon something like a search box or, a footer, or a modal that's a lot of work. That's just design and product design and product development in general. But the act of, you know, creating the design system, maybe it's the documentation site, or however, we're communicating these standards across the organization. That part, to me, it's always kind of taken too much time and effort. And to be really candid, the amount of budget that's being allocated for those tasks is less. So, we're having a lot of users who are saying, "Well, I wasn't in charge of a design system. We had a team for that. We don't anymore. And now I'm responsible for it," or "The team's been combined, and I'm working on, like, three things at once." And so, something that's very, very crucial to us at Luro is to help with the struggle of spinning up a design system. For us, I fully believe that there are design systems that can be fully custom available to the public and need to have, you know, every page and view needs to be unique unto itself. But for Luro, the starting place that we get you with, you know, you can link in your Storybook. You can link in Figma components. You can add components manually and all those sorts of things. Where we can get you in a few minutes is really close. And then, if you started to fold in, you know, the idea of performance, accessibility, and then all of the other insights that you can then integrate, so if you're doing A/B testing or user testing and doing research, and you want to make sure that that's all involved inside of your design system, then it becomes a really attractive option. So, I think that decreasing the time it takes to get started and to spin up a design system is the number one thing we see people struggling with and the number one thing we want to bring. I kind of like to compare it to services like Netlify. Like, I remember I used to have to set up servers to demo things for clients, and it would take an hour, and I don't know what I'm doing. And I would break stuff, and they would have to help me fix it. So, then I'm bothering him. And then, now I'm just, you know, will either link to a CodePen or drag and drop a deployed URL from something like Netlify. And it's this amazing, almost like it feels like deploying is just as difficult as, like, sketching something out on a napkin. We want spinning up a design system to kind of feel that way so it's not so precious. You're not worried about...it is just easy to get started. And so, we're kind of integrating all these other tools that you use to make that easier and quicker because if you do have other things that you're working on and you need to move beyond that so that you can focus on prototyping, or designing, and building the actual components, you can do that. And you have that option as opposed to having to be mired in some of these other details. VICTORIA: It seems like change management and integrating change into larger organizations is always the biggest challenge [laughs], even for great innovations. And I'm curious: what types of people or groups have you found are quick to adopt this new method and really the right group for you to center your message on? TRENT: Yeah, it is...I was joking, I think, maybe before the podcast started, but it's, like, very ambitious because it's easy, I think, to say, "This tool is for designers. And if you're a designer, you can integrate your Figma, and then you'll have your components published to your team so that they can use them." And that's absolutely true. Like, if you're a designer, Luro is for you. If you're an engineer and you have just received components, and you need a way to document that and show your coded version alongside the design version and be able to collaborate with people in that sense, it is absolutely for you as well. So, you can see how it's almost like you almost have to frame Luro for individuals across the organization. So, it's one of those deals where...and we've kind of experimented with this with the marketing. And the way we've discussed it, we talked to lots of, you know, leadership, heads of product, CMOs, even CTOs, things like that. And so, it's like, if you're trying to get your entire organization to work better, to ship, you know, more effectively, then Luro is the tool for that as well because we're getting into knowledge retention via uploading. Like, my favorite story there is if you're an A/B tester, probably, and this is what we've experienced, is you run these tests. A lot of time and effort goes into building the prototypes for the test, whether that's you or an engineering team that's doing those things. This is one of the things we used to do as an agency. We would be brought on to prototype something totally new. We would test that alongside the existing experience. And an A/B tester, we'd work with them, and they would create, like, a PowerPoint or something that would explain the pros and cons and what should happen next and summarize the test. And that would live on that person's hard drive, whether it's on their computer or, like, a Dropbox or a OneDrive account. And no one ever thought about it ever again. You would just move on to the next test. But the amount of money spent on us to build the prototype and the amount of money spent on the SaaS to spin up the, like, A/B testing environment and all of these things, and then the time spent on the A/B tester to analyze the results and generate a PowerPoint it's not nothing. And so, one of the things that we find pretty appealing for leadership within Luro is the idea of integrating all of these tools and all this work that you do in mapping them to components so that when you pull up, for example, a button component, you'll see all the user tests that have been added over any period of time. So, if you were a new hire and you're trying to onboard, you can go interview everybody in the organization and ask them about the history of a button or a card component or the history of a sign-up page. But then, also, in a self-service way, you can just click into Luro, click a button, click a card, click to the sign-up page, any of those things, and find all that stuff I was mentioning earlier, whether it's a test, or research, or prototyping, or any kind of documents that have been written. These aren't the arguments that Dave or I might have around the actual border-radius value. Those are small things that probably should be lost in the firehose. But if we have learned an outline button with a stroke is performing way better than a solid-filled button or vice versa, that's important information that doesn't need to disappear in six weeks. So, that's the other kind of metric there is explaining kind of the holistic version, telling the holistic story of Luro to those types. And so, yeah, navigating that and trying to get, like, buy-in on a broad level is kind of what we're working on these days now. WILL: Sweet. So, I actually really like how it's almost like version control. You can see the history of what you've been working on. And I really like that because so many times...you're correct. When I go to Figma or anything, I'm like, why are we doing it this way? Oh, we made these decisions. Maybe in comments, you can kind of do it, but I think maybe that's the only place you can see the version control. So, I like that feature. Like you said, you can see the history of why you did something like that. TRENT: Yeah. And think about that, so if I am a front-end engineer and I receive a design and everyone thinks that, why are we doing it this way? I would hate to code something...I can do it. It's my job. But if I don't understand why, my feeling about work and maybe the quality of my work goes down, you know what I mean? I guess what I'm trying to say is, like, feeling like you understand, and you're lockstep with the entire team, and you understand what the goal is...what are we trying to do? What are we trying to achieve? Like, what have we reviewed that has made us believe this? And if you don't have that information, or if I don't have that information, like, there's some traction within the team, whether it's actual momentum forward and the amount of tickets that are being closed, or just the spirit of what we're doing, that the product is going to be diminished. These are all these little things that add up, up, up, up, up over time. So, being able to show this information to be able to access this information kind of passively. So, for example, if you got VS Code open and Luro open and you can see here's the user test from six weeks ago that shows us why we went with option B, you'll say, "Okay, cool. Even better." You know, you can review those things way before you get things handed to you. You know, it's much more kind of this utopian vision of an open, collaborative deal. And the way I would say that is it's, you know, we all kind of hand things off. So, of course, like, there's some version, even if it's like a micro waterfall that happens on a daily basis. We're all doing that. Like, somebody needs to be done with something to hand it off to something else, so we're not all up in each other's space all the time. But one thing that we like about Luro, whether we use Teams, or Slack, or whatever, it's not a real-time thing where I have to say, "Stop, look what I'm doing [laughs]. Come over here and look because I need you to know this." You can get notifications from Luro, but it's not something that is a context-switching demand type of a situation. So, the idea is if you're like, I'm wondering what's going on. I know this is coming up. I'd like to review. Or I could let you know and tell you, and just on your own time, you can go see this. So, separate from, like, the firehose of tickets and chats, you can see the actual product evolving and some of these, like, key milestone decisions on your own time and review them. And if they've happened before you even started on the project, then you can do that as well. WILL: I think that's probably where the breakdown between developers and designers that collab that's where it probably breaks down, whenever you're trying to get your tickets out as a developer. And then there's a change while you're working on it, and it's a complicated change, but you're still responsible for trying to get that ticket out in time. So, I think, like, what you're saying, you can get it beforehand. So, it sounds like, to me, Luro would be a huge help because you have to have developers and designers working together; if you don't, you're just in trouble in general. But anything that can help the relationship between the two I think, is amazing, and that's what I'm hearing whenever you're talking about Luro. It helps. It benefits that relationship. TRENT: Yeah, that even makes me think a little bit about the ongoing collaboration aspect. So, it's like, if something is shipped...or maybe let's go the agency scenario here. You've launched a site. You've launched a product. How do we know how it's performing? Of course, you'll have everybody...they're going to have analytics, and we'll be talking about that. And are signups up or down? But Luro will run tests. It'll continue to run component analytics. So, you can sense whether, like, somebody is changing a component. Or, you know, is the fully adopted design system not being utilized or being utilized less or more over time? But then, also, we're running, again, performance and accessibility metrics. So, we've seen it where we've shipped a product for a client. You know, we've had Luro running. We've sort of used that as our hub to collaborate over time. And then we'll notice that there's a giant performance spike and that, like, the page speed has gone way down. And we itemize issues and can point you to exactly the page that it's happening on and give you some insight into that. Of course, you could go through after you've worked with the client and run Lighthouse on every single page in your own time for fun, but that's not reality or fun. So, you'll get this information. And so, you almost...before we were telling people who were using Luro, we were kind of using it ourselves just to help ourselves do a better job. About a month into a project, we were able to email a customer, a former client, and say, "Hey, site's looking great. Amazing to see this. There's a 3-megabyte, 50-pixel avatar. Someone uploaded a giant image. It displays as 50 pixels. But somebody must have uploaded the full one to your homepage, and your page speed score tanked." They're like, "Oh, wow, they must [laughs] be monitoring us and checking in on us every day." We love them dearly, but we were not doing that. We were using Luro off to the side. So, there is this other aspect of just sort of monitoring and making sure things stay, you know, as they were or better once we ship things and move forward to the next. VICTORIA: That's really interesting. And I'm excited to explore more on my own about Luro. As we're coming towards the end of our time today, I wanted to give you one last chance to shout out anything else that you would like to promote today. TRENT: Oh, that's it [laughs], luroapp.com, you know, that's the main thing. Check out component analytics. We have a YouTube channel, and I would say that's probably the easiest, a lot of effort, even though the videos maybe I'd give myself an A-minus or a solid A, not an A-plus on video production. I'm trying to get better. But explaining just, like, how to set things up. There's, like, a one-minute, like, what is all this? So, if you want to see all the things that I've been trying to describe, hopefully well on the podcast [chuckles], you can see that really well. So, I'd say Luro App and then the YouTube channel. We've got, like, five, six videos or so that really kind of help get you into maybe what your use case would be and to show you how easily things are set up. VICTORIA: Great. Thank you so much for joining us today, Trent, and for sharing about your story and about the product that you've been building. TRENT: Yeah. Thank you for having me. This has been great fun. VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. WILL: And you can find me on Twitter @will23larry. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Come back with us to the days of mimeographed and photocopied booklets filled with writing and art of often terrible quality! Fanzines showcased all the raw enthusiasm of fandom with very little editorial gatekeeping until the rise of crappy Geocities web pages made them financially impractical. Hear us doing dramatic readings and even SINGING, at least when we aren't laughing! We remember Pitney's old friend Vivian (may she rest in peace) and share a story about our own attempt at creating a zine. And then we give you a song.   Promos: Ignorance Was Bliss  https://iwbpodcast.com 2 Skeptical Chaps http://www.2skepticalchaps.libsyn.com/  (Want to swap show promos? Email us!)   We love you for listening! Please take a moment to rate and review us, and earn a STICKER! (Everyone loves stickers!) And please subscribe or add us to your favorites list on your favorite platform so you never miss a show! And share us with your cool friends, not the lame ones.     Questions? Comments? Complaints?   Write to us at PitneyAndAmelia@gmail.com! Tweet at us at @bitchenboutique! https://twitter.com/bitchenboutique  Stay up to date by liking our Facebook page! https://www.facebook.com/Pitney-Amelias-Bitchen-Boutique-1082838478590821/   If you want to be supportive without a lot of stuff cluttering your feed, follow us on Instagram at @pitneyandamelia! https://www.instagram.com/pitneyandamelia/ And if you're feeling generous, buy yourself a little something at our merch shop and help to support our show! (Turn off that Content Filter to see the "uncensored" stuff!)  https://www.teepublic.com/stores/bitchen-boutique?ref_id=30433&utm_campaign=30433&utm_medium=affiliate&utm_source=Bitchen%2BBoutique   Who the heck are Pitney and Amelia? A gay guy and his fat friend talking about everything! We've got 40 YEARS of stories to share about stuff we love, stuff that annoys us, people we've known, places we've been, and things we've seen. Geeky, silly, and always opinionated. NAMES ARE CHANGED TO PROTECT THE GUILTY!     We may be awful, but we're right! Here, queer, and in your ear. Every other Friday.   The Bitchen Boutique is all about mental health and openness and honesty and if you're in crisis and in the US, call or text 988, or go to 988lifeline.org to reach the National Suicide Prevention Lifeline.  And if you just need some friends, you've got two right here. LGBTQIA+ | Comedy | Pop Culture | Fandom | Horror | Spirituality | Mental Health   #doctorwho #fanzines #zines #classicwho #leela #filk #fandom #myhr #slashfic #startrek  #LGBTQIAplus  #Comedy #PopCulture #Fandom  #Horror  #Spirituality #MentalHealth

Cybernetic aliens attempt to assimilate humanity into their collective, and only the crew of the USS Enterprise can stop them. Listen as we lament lost GeoCities websites, ponder if aliens could unite humanity, and make a predictable Moby-Dick joke. Resistance is futile as we find out if Star Trek: First Contact stands the Test of Time.

Cassie, a student at Sunnydale High, confides in Buffy that she has foreseen her own death. Everyone has a theory: Dawn blames Baby Mitch, Buffy and Xander shake down a deadbeat dad, and Anya would likely say it's bunnies, but no one asked her.   Hear us discuss… Missed opportunities to process Willow's grief Nice to see the gang back together doing research Cassie is genuinely so kind, RIP Kara misses the Geocities era of the web Don't these demon-worshipping white boys even know who Buffy is??   Trigger warnings Assault, attempted murder, fatphobia, kidnapping, medical content  

In this Liquid Weekly Podcast episode, hosts Karl and Taylor are joined by Sam Isseyegh, co-founder of Discount Kit, a leading Shopify app. They explore Sam's journey from gaming and web development to full-stack Shopify expertise. The team goes way back on Sam's experience in web development experiences, all the way from playing Age of Empires to creating Geocities websites. Sam shares his Shopify journey, from working on Pizza Hut's ecommerce platform to app development, reflecting on the challenges of launching Stackable Discounts just before Black Friday. The conversation shifts to Shopify's Checkout Extensions, emphasizing their significance, sandboxing benefits, and differences in running Shopify Functions compared to Scripts.The power of Shopify Functions is explored further, with insights into enhancing customization and configuration using GraphQL schemas, input variables, and metafields. Sam shares tips on effectively utilizing metafields and passing settings between functions. Explore the provided resources and links to dive deeper into the topics discussed in this episode. Don't miss out on further Shopify insights—subscribe to the Liquid Weekly Podcast for your weekly dose of developer insights. // Guest Information // Follow Sam Online - Twitter (X): https://twitter.com/SammyIsseyegh - LinkedIn: https://www.linkedin.com/in/sammyisseyegh/ - Discount Kit: https://discountkit.app/ - Optizio: https://optiz.io/ // Resources // Miro App: https://miro.com/apps/ Notion: https://www.notion.so/ Shopify Functions links: - https://shopify.dev/docs/apps/functions - https://shopify.dev/docs/api/functions Checkout Extensions: https://shopify.dev/docs/api/checkout-extensions Cart Transform API: https://shopify.dev/docs/api/functions/reference/cart-transform Shopify Devs Shopify Functions Playlist - https://youtube.com/playlist?list=PLvQF73bM4-5W79CMjKV9GoDE58c9jS5TD&si=mQ99N-oUmMZiu7zb // In the Community // Collab Request default - John Speed Twitter Thread: https://x.com/John_Speed/status/1734287034133492087?s=20 DMCA Takedowns - Tobi Lutke Twitter Thread: https://x.com/tobi/status/1734345068868157547?s=46 Public Roadmap for Shopify Apps - Sam Twitter Thread: https://x.com/sammyisseyegh/status/1732095102367957490?s=46 // Changelog // Customer Accounts Extensibility in Preview: https://shopify.dev/changelog/customer-accounts-extensibility-is-now-available-in-developer-preview Webhook Topics for Discount Events: https://shopify.dev/changelog/introducing-webhook-topics-for-discount-events Automatic discount functions for B2B: https://shopify.dev/changelog/automatic-discount-functions-now-apply-to-b2b-sessions New Modal API latest version: https://shopify.dev/changelog/modal-api-added-to-the-latest-version-of-app-bridge // Picks // Karl - That Mitchell and Webb Look Sketch Comedy: https://www.youtube.com/watch?v=dOBhf8f7cXM Sam - Gleam (Luey Pillford) - a new programming language that brings types to the Erlang ecosystem: https://gleam.run/ Taylor - Bicycle trainer: https://amzn.to/3vKgoNw // Sign Up for Liquid Weekly // Don't miss out on more Shopify insights—subscribe to Liquid Weekly at https://liquidweekly.com/

Creative Director and Design TikToker Zachary Winterton joins Sean to talk about the people in your (Geocities) neighborhood, bad leadership advice from cheerleaders, and Charlie the Cactus: the supermarket mascot of our dreams?Zachary is probably best found these days on TikTok (tiktok.com/@zacharywinterton), Instagram (instagram.com/zacharywinterton), and YouTube (youtube.com/@ZacharyWinterton) where you can find his latest short form design-centric videos. You can sign up for The Creative Brief, Zachary's weekly newsletter, on his website at zacharywinterton.com/newsletter. That same website, zacharywinterton.com, is where you can see some of his past work.This episode was recorded Sunday, November 12, 2023. Hosted on Acast. See acast.com/privacy for more information.

In this episode, I chat with Brent McCreary, the teenage visionary behind the go-to Beanie Baby information site in the late '90s. Brent takes us on a nostalgic journey, recounting the Beanie Baby mania and sharing insights into the tech stack that powered the site during that era (Geocities, anyone?) We also discuss why we love to collect things, and the sense of community among Beanie Baby enthusiasts. Brent also dives into the monetization strategies employed during the late '90s compared to today. Tune in for a fun conversation that intertwines nostalgia, old school tech, and the magic of Beanie Babies! Follow Brent on IG: @crazyforconcerts Follow Brent on X/Twitter: @gaygay4gaga

Zdravo. Ker ples ni več v modi, tokrat stavimo na revolucijo. V šamponu. Oziroma, v šamponih. Vsaj na kakšno novo revolucionarno formulo čakamo, ki bo krasila novodobne šampone, ki bodo primerni za podnebne spremembe. V predigri se posvetimo divje netočni zgodovini interneta, tehnologiji WAP, SMS-om in Geocities. Obelodanimo, da odpuščamo tudi v našem malem podkastu, ker je to pač popularno početje v našem (podkasterskem) sektorju. Poslovimo se od scenarista, redaktorja, montažerja, oblikovalke, režiserke, tajnice režije, organizatorke, odgovorne urednice, strokovnjaka za družabna omrežja in tonskega tehnika. Slava jim. V poglavju se posvetimo povratku Forda, oz. snidenju Arturja in Forda in se spomnimo na Carja, ki zna oživljati skoraj tako dobro, kot Aljo, ki Carja ni gledal, ve pa, kako se to dela po zadnjih standardih.

Welcome back to The Kotaku Australia Podcast. It's a show about video games, and this week, we've got a special episode for you! This week on the show, we're doing something a little bit different. During PAX Aus last weekend, we caught up with South Australian game developer Chantal Ryan. You might have heard of her game DarkWeb Streamer -- you may have even played it, if you stopped by their booth at the show. Chantal's interview with Emily was so fascinating and wide ranging we decided that make it this week's episode of the podcast. If you've not heard of Chantal before, or heard her speak about her craft, we're very excited to introduce you. Chantal is as much an anthropologist as she is a game designer, interested in people and what makes them tick. It is this willingness to burrow into the human psyche that has made DarkWeb Streamer, the first game from her South Australian studio We Have Always Lived In The Forest, one of the most hotly anticipated local titles in years. In this interview, Chantal speaks with Emily on her extremely unorthodox pathway into gamedev, how her deep study of the Geocities-era of the internet informed DarkWeb Streamer, and why she thinks the internet of today feels so bereft of personality by comparison. Head here if you want to see more Australian content!: http://trib.al/d7EeR7T   Follow us here for more updates on games and the gaming world: f: https://www.facebook.com/KotakuAustralia t: https://twitter.com/KotakuAU ig: https://www.instagram.com/kotakuau/ twitch: https://www.twitch.tv/kotakuau tiktok: https://www.tiktok.com/kotakuau Get all the gaming news daily on Kotaku Australia!: https://www.kotaku.com.auSee omnystudio.com/listener for privacy information.

Where do Josh and Chantal get all their cool stuff for the store? Some secrets must remain but in the second episode they pull back the curtain on what it's like to go on a road trip to buy vintage items. What makes a successful buying trip? How did a Geocities website lead them to a midnight drive to a Maryland farm? Shoutout to the La Quinta Inn and Dunkin' Donuts!Follow In Vintage We Trust on Instagram @invtgwetrustProducers: Ben Agbeke (@benji.agbeke) and Alex Wong (@stevenlebron)Cover art by: Tristan Douglas (@halfgood_)Music by: SHWING (@shwingmusic, @plutoniclab, @builtbybronze)

In this classic, Yuki and TV Guru take us down internet memory lane as they talk about Web 1.0 with sites like Angelfire and Geocities.  From the classic: Our Experience With 90s/2000s Internet.   Find us @   http://swarthynerd.com/ https://twitter.com/swarthynerd https://www.youtube.com/channel/UC-E7IKrrIY3WTEi-2--RYAw Hit us up at swarthynerd@gmail.com Yuki's Social Media https://www.facebook.com/yukithesnowman/ https://yukithesnowman.com/ https://www.youtube.com/channel/UCnW2H7VD6ahR4xXPba-DYLQ https://twitter.com/weebtrashyuki Cash App: $BenjaminASnow Tv Guru's Social Media https://www.youtube.com/channel/UCxRviGx_yUWnDD0oABAT85g https://mobile.twitter.com/superlostfan108 Cash App: $superlostfan108  

How did the desire to be a writer lead to an opportunity to be part of the emerging web 2.0 scene within social media marketing? Why were technical skills in account/brand management roles so valued by digital marketing agencies? What are some attributes of successful startup employees that can also make them not the best college or university students? How have the scope of problems that startups are solving for today become much more complicated than those being built in the early days of web 2.0? Have the barriers to entry for becoming a software startup employee increased or decreased since the early 2000s? What are the benefits of shipping embarrassing products that lack features and has lots of bugs? Why is it so important to have uncomfortable conversations with customers who aren't using your product? How many billions of dollars in deposits as Rhino saved renters so far? Why are thorny technical challenges so motivating for technical founders? Bryan Woods - co-founder of Rhino, joins Proptech Espresso to answer these questions and discuss his path to web development which came about while growing up as a 90s kid during the glory days of Geocities where he learnt HTML and CSS in order to build websites for multiple groups including his high school track team and a highly popular 2Pac fan website.

Eastwing Rickman keeps the world's greatest collection of assassin information on his Geocities page. He's getting too close to the truth though and his previously unknown nemesis has come out of hiding to call him out right on live TV. It's 1995 so it really meant something. Thanks for listening! --- Send in a voice message: https://podcasters.spotify.com/pod/show/wehaveasituationhere/message

Welcome to Episode 350! I can't believe we're here. I'm coming up on 7 years in podcasting, which is incredible, and I've had the chance to talk with so many amazing people.  Every 10 episodes I do a solo show. And it's really just me! No team. No people sitting nearby. Just me sitting by myself at my desk in my office/recording studio. I wanted to do something fun for this episode, so we're doing a “Get to know me” show. 2:02 – Get to know me Back in high school, I created my own website on GeoCities. People used to share fun “get to know me” info. Let's jump into some questions you have about me! 5:11 – Am I named after anyone? No, I'm not named after anyone. My name is Irish. My parents always wanted to have a girl named Molly. 5:33 – Do I have kids? Yes, Lily and Amos. And two boys, Elijah and Malachi, who went to Heaven during pregnancy. I always wanted 5 kids, so I adopt my friends' kids. 6:03 – Last time I cried? I cry all the time. I'm a sympathy crier. 7:01 – Do I use sarcasm? Not as much as my husband. 7:34 – What I first notice about people? What they're wearing and if I think they're real or phony. 8:43 – Scary movie or happy endings? Hard pass on scary movies. 9:09 – Favorite smells? Flowers – roses and peonies. Also, the smell of my house, especially my bed and sheets. Is that strange? 11:14 – Hobbies Playing guitar and reading, if I have time. Also, anything farming. I have several “granny habits,” like canning, cooking and food preservation. 12:54 – What did I want to be when I grew up? I wanted to be on Saturday Night Live. Seriously, that was my dream. 13:56 – How tall am I? I'm 5'3” on a good day! 14:48 – Favorite and worst subjects in high school? Loved writing, hated math. 16:07 – Favorite childhood memory When my mom took my friends and me to see NSYNC in concert. 18:24 – Extrovert or introvert? I'm an introvert … really! I just love my alone time. That's how I recharge. 20:02 – Am I a good cook? Yes! I love to cook. 21:02 – Where would I love to live? Right where I am. 22:43 – First movie I saw The Wizard of Oz. I was obsessed with it. 23:02 – One word that describes me Loyal. 23:56 – Something that amazes me Living on the farm and seeing life happen around me. FEATURED QUOTES I love doing this podcast. I get to sit down with so many cool people. I cry all the time. I'm a sympathy crier. Do I use sarcasm? Not as much as my husband. I have developed what I call “granny habits” over the last couple of years. I really like to can and cook and do food preserving.

This week on the Why Do Podcast, Ben and Ram sit down with Elijah, also known as @toastedbyeli, a Toronto-based graphic designer who's been making hundreds and hundreds of posters as a means of self-growth, healing, and spreading a positive message. We talk about Geocities, internet forums, astrology, making art every day for a year, making art to help yourself and those around you, finding inspiration in therapy, not caving to the demands of social media, and more! As always, our theme music is brought to you by the great @computrnerd. Please rate and subscribe if you get a second we appreciate you very big time much!

WITH SPECIAL GUESTS NIGEL KITCHING & RICHARD ELSON! We had to do something special, didn't we? Sonic the Comic the band joins me, Chris and some "surprise" guests for this hunky-chunky celebration episode. It's the biggest STC ever went.

 If we've learned anything from watching the turnover of tech giants like Yahoo! and MySpace, it's that internet darlings rise and fall. And there's something darkly fascinating about watching it happen in realtime.Maybe we're seeing it now with Twitter and Facebook– some of us will mourn the loss of the communities and connections that we've created in the virtual spaces owned by these billion dollar companies...While others will enjoy visiting the graves of these once unstoppable behemoths  to tramp the dirt down.Either way, the values and trends and hopes and ambitions that go into the architecture of the virtual world say as much about us as the architecture of the real world. And that's what these two stories are all about.The Lost Cities of Geo Redux

PotAdvisor.com was started by two friends in Southern ME, Dan McGarry and Travis Sjurseth. Both have a history of working in the tech space. Dan owns and operates his own web development company, focusing more on backend development, while Travis worked mainly in front-end and marketing throughout his career. Their goal as more states legalize cannabis consumption is to provide a place for new and seasoned cannabis consumers to learn more about ins-and-outs of safe cannabis consumption, including how to consume the various forms of cannabis, finding a nearby dispensary, what questions to ask your budtender (whether for medical or adult rec use), discover new strains, get industry news, and learn more about independent producers within the industry. Discussed this week: Popcorn, crunchy salted nuts, apples, Cheez-Its, weed - it's, wasabi peas, the 420 of Yelp, getting kicked out of the Navy, building a website, crunchy and salty, food as an activity, hinging out alcoholic bonbons at graduation, the Elvis dog, baklava, minimal Delights, cookies, DARPANET, UC Berkeley, hyrax, mermaid Confections, Travis and the giant Apple, Apple pipes, scoring weed from older siblings, cigarette testing, going up to camp, Adult Rec, haughty attitudes, filling a notebook, Geocities, our first dispensary visits, feeling niches, Weedmaps and Leafly, and more! --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app --- Send in a voice message: https://anchor.fm/potluckypodcast/message Support this podcast: https://anchor.fm/potluckypodcast/support

Some movies get a bad rap, but they do really deserve to be held in such low regard? Join Jonnie Sea as he dives into bad movies and ultimately lets you know if they need to be tossed out with the JUNK! The deep dive of BATMAN & ROBIN concludes with ACT III! Mr. Freeze and Poison Ivy have hatched their diabolical scheme and even the combined forces of Batman and Robin may not be enough to stop them! Luckily, Barbara Wilson is a top notch hacker, and BATGIRL is born! With the day saved, Jonnie is finally forced to render his final verdict… Plus: Mr. Freeze battles GeoCities, The Max Headroom Incident, Bane celebrates Harvey Dent Day and so much more!

This week we have two researchers to talk about web archiving, its politics, its goals, and how web archiving is often mobilized to address problems it really can't help. We're talking Tumblr and GeoCities, Twitter's feared implosion, Internet Archive, and the space to mourn our platforms and communities.    Jessica's social: https://twitter.com/jessogden  Katie's social: https://twitter.com/ktcmackinnon; katiemackinnon.xyz Readings https://www.tandfonline.com/doi/full/10.1080/24701475.2021.1985835 PDF: https://drive.google.com/file/d/1EEODs_kMMUj0vywKLZMf7aetgUcBdh1q/view?usp=sharing https://www.tandfonline.com/doi/full/10.1080/24701475.2022.2051331PDF: https://drive.google.com/file/d/16305lQTUYB2IK_G-eSnjvCEgt5YdOCQp/view?usp=sharing  Media referenced Jessica PhD thesis https://eprints.soton.ac.uk/447624/ Jessica's publications: https://research-information.bris.ac.uk/en/persons/jessica-ogden  Katie's PhD: https://tspace.library.utoronto.ca/handle/1807/125246  Katie's publications: https://scholar.google.ca/citations?user=zKGIFGEAAAAJ&hl=en  GeoCities Tumblr research project https://www.tumblr.com/oneterabyteofkilobyteage Dead-and-dying platforms: a roundtable https://www.tandfonline.com/doi/abs/10.1080/24701475.2022.2071396  Baltimore Uprising; A Teen Epistolary https://www.activedistributionshop.org/shop/books/3963-the-2015-baltimore-uprising-a-teen-epistolary-by-various.html 

This episode is about what happens when the metaphors we use to speak about things change. But mostly it's about Geocities. Full Show Notes: https://www.thejaymo.net/2023/01/14/301-2302-the-geocity-and-the-city/ Support the Show Watch on Youtube Permanently moved is a personal podcast 301 seconds in length, written and recorded by @thejaymo

For the first ep of 2023, Erika joins us to showcase her new podcast about when she used to eat at strip mall Italian restaurants in the 90s. Her regular waiter from back then, Vincenzo, even pops in to say hello. Finally, we divert into talking about the Ricky Martin fan site Erika made in 1999 (it even won an award!). PSA: If anyone can dig up the defunct Geocities site "Erika's Ricky World" from the archives of the internet, please contact us @realpodcasttown on Twitter. Seriously.

https://upmyinfluence.com/wp-content/uploads/2022/08/McDermott-Wide.png () In this episode of the Thoughtful Entrepreneur, your host Josh Elledge speaks with Marketing Coach and Podcast Host of https://therecognizedauthority.com/ (The Recognized Authority), Alastair McDermott. Alistair McDermott focuses on helping others through determining their specialization and making an authority content plan. Alastair explains the stages of gaining authority in business. Within the novice stage, one must gain experience and figure out the things they prefer over others. At this point, one can still have a successful business through referrals and word of mouth. Alistair explains that to go further, you have to focus on a specific field, which can be scary to decide as it can cut off other areas of possible connections or revenue. Alastair explains that results come from consistency and a routine over a significant period of time. This is important as it gives others more trust in a business. Alistair says that time and experience is important to creating a good image for yourself or business. Key Points: Alastair's thoughts on how authority helps business Alastair's thoughts on the journey to authority The importance of specialization Alastair's advice on how to build authority The importance of trust between consultants and clients Why taking your time is important to a business Alastair's focus as a consultant and how he works with them   About Alastair McDermott Alistair McDermott is an author, consultant & coach who hosts The Recognized Authority Podcast and The Specialization Podcast. Alastair helps consultants and invisible experts to become The Recognized Authority in their field so they can have more impact, command higher fees, and work with better clients. Alastair got into digital marketing and business when he built his first website on GeoCities in the “before-time” of 1996 – he has been hooked on websites ever since. Alastair left a “safe” corporate job in early 2007 to start and grow his first business during “the worst recession in modern history” – that was a wild ride. Along the way he co-founded several start-ups, some of which were mildly successful, and he has written a book called “Running a Website with WordPress: A Quick Guide for Business Owners”. His podcast and email list are called “The Recognized Authority”. You can download his free book “How to Sound & Look Good on Zoom & Podcasts” from SuccessStore and Amazon.   Want to learn more? Check out The Recognized Authority website at https://therecognizedauthority.com/ (https://therecognizedauthority.com/). Check out The Recognized Authority on LinkedIn at https://www.linkedin.com/company/the-recognized-authority/ (https://www.linkedin.com/company/the-recognized-authority/). Check out Alastair McDermott on LinkedIn at https://www.linkedin.com/in/alastairmcdermott/ (https://www.linkedin.com/in/alastairmcdermott/). Check out The Recognized Authority on Instagram at https://www.instagram.com/recognizedauthority/ (https://www.instagram.com/recognizedauthority/). Check out Alastair McDermott on Twitter at https://twitter.com/WhatStrategy (https://twitter.com/WhatStrategy). Don't forget to subscribe to The Thoughtful Entrepreneur and thank you for listening. Tune in next time! More from UpMyInfluence: ️  We are actively booking guests for our The Thoughtful Entrepreneur.https://upmyinfluence.com/guest ( Schedule HERE).   Are you a 6-figure consultant? I've got high-level intros for you.https://upmyinfluence.com/b2b ( Learn more here).   What is your #1 Lead Generation BLOCKER? http://upmyinfluence.com/quiz (Take my free quiz here).