The Changelog: Software Development, Open Source - Making the command line glamorous (Interview)

Episode Date: February 26, 2022

This week we're talking to Toby Padilla, Co-Founder at Charm — where they build tools to make the command line glamorous. We talk about the state of the art, the next big thing happening on the command line and in ssh-land. They have an array of open source tooling to build great apps for the terminal and Charm Cloud to power a new generation of CLI apps. We talk through all their tooling, where things are headed for CLI apps, the focus and attention of their team, and what's to come in bringing glamor to the command line.

what's up what's up what's up welcome back this is the changelog thank you for tuning in if this is your first time here subscribe at changelog.fm if this is your fifth hundredth thousandth time back thank you for being such a loyal listener as you may know we have a membership for our loyal listeners if you want to skip the ads and support us check it out at changelog.com slash plus plus today jared and i are talking to toby padilla from charm where they build tools to make the command line glamorous we talk about the state of the art the next big thing happening on the command line and in ssh land they have an array of open source tooling to build great apps for the terminal and charm cloud to power a new generation of cli apps we

talked through all their tooling where things are headed for cli apps the focus and attention of their team and what's to come in bringing glamour to the command line big big thanks to our friends and our partners at fastly for having our back, our CDN back that is, all our pods, all our assets, our website, everything is backed by Fastly and it's fast globally because they are awesome. Check them out at Fastly.com. This episode is brought to you by our friends at Square. Millions of Square sellers use the Square app marketplace to discover and install apps they rely on daily to run their businesses. And the way you get your app there is by becoming a Square app partner.

Let me tell you how this works. As a Square app partner, you can offer and monetize your apps directly to Square sellers in the app marketplace to millions of sellers. You can leverage the Square platform to build robust e-commerce websites, smart payment integrations, and custom solutions for millions of businesses. And here's the best part. You get to keep 100% of revenue while you grow. Square collects a 0% cut from your sales for the first year or your first 100 Square referred sellers. That way you can focus on building and growing your Square customer base and you get to set your own pricing models. You also get a ton of support

from Square. You get access to Square's technical team using Slack. You get insights into the performance of your app on the app marketplace. And of course, you get direct access to new product launches. And all this begins at changelog.com slash square. Again, changelog.com slash square. So we have Toby Padilla here from charm toby thanks so much for joining us on the show thank you for having me charm y'all build tools to make the command line glamorous i landed on your website and i thought i am the target audience for these folks really cool stuff thanks yeah we like to be glamorous. How many people are in this charm group? Because I just reached out to all y'all and said like,

hey, come on the show. And I think there was a handful of people that responded or there was, you know, there was some talk on your side who should actually be the representative and end up being yourself. But who else involved? There's six of us. So there's myself, there's our the other co founder, Christian Rocha. There's Muesli, who's been with us since almost the very beginning. There's Carlos Becker, who's the GoReleaser guy. There's Eamon Begabus. He does a lot of the soft serve development and a lot of our DevOps stuff. And then we just hired Julie Zhang, who worked with us at Betaworks. She was a VC over at Betaworks, and we brought her on to the business side two weeks ago. We also have Pengu. Got a shout out to Pengu. He's our intern. Amazing, just open source guy, friend of Muesli.

Shout out to Pengu. So I know Carlos Becker. He was on GoTime last year. Yep. And ever since then, him and I have been working together to get him a GoTime t-shirt shipped to his location because... He mentioned today that he hasn't got his t-shirt yet. So, yeah.

No, but we've tried over and over again i think he's in brazil or somewhere he is and you know shipping things is hard these days and so we just actually decided to start from scratch hopefully we try a second time he just got stuck somewhere in customs who knows who knows what happened but yeah carlos and i have been talking for a while ever since his go time appearance carlos is a good guy. We're excited to have him on. He actually started as a contributor and a person who is just kind of around the charm project. And then we brought him on as a contractor and around four months ago, I believe he came

on full time. So y'all have a bunch of tools. It's kind of hard to decide where to start and which one to go into. And that was one of the things when I first landed on your site, site, I thought, here's an easy changelog news link up. Then I started scrolling and I'm like, holy cow, there's a whole bunch of different projects here. Which one do I link to? Then I was just like, I'm into command line stuff.

I was like, we just need to bring them on the show and talk in more depth. One thing I've already keyed in on, I'm sure Adam's keyed on it because he's all about the founders talk, is you said my co-founder. And I'm looking at a whole bunch of open source tools. And I'm just very curious, how do you guys approach charm? You said there is an incorporation. So tell us about, I guess, what is this entity? So we are actually a seed funded startup. And we started because we wanted to make the command line more fun. We wanted to make it glamorous, right?

And that sounds insane, but it's something that we wanted to do. But it actually means a few things to us. So Kristen and I were at Betaworks together. And then, like I said, Julie was there too. And we were doing various projects for them. We have a long back story with them. We've done multiple startups. I was a VP at TweetDeck, which was a Betaworks

founded company. So we'd been in the Betaworks space for a while, but we wanted to do something together because we like the entire time we've known each other, even when we were doing other startups, we were exchanging VimRC tips, bash tips, all of these things. We're like, you know, we're really passionate about the command line. Why don't we see if we can turn it into a company? You know, it needs, it needs a rethinking. It needs a rebranding. And we want to just work on it. That's what we want to do this, right? It's a fun thing to do. And so what we wanted to do was, A, make it more fun to work on the command line. B, bring modern product thinking to the command line. That was something, if you look at the history of the

command line, it was very much rooted in 1970s and 80s mainframe technology, right? It's designed around multiple users per machine. It's not really set up for the internet. It doesn't have a ton of sort of built-in encryption. It does sort of now, maybe at the disk level or something like that. But we wanted to modernize it. We wanted to make it look nice because it doesn't always look nice, right? Sometimes it looks really raw and looks can be important. And so we wanted to, Christian's a designer by trade and he's a really great designer actually. And so we wanted to sort of apply that to the command line. And then we wanted to make it easy to take all of these concepts and for us to build tools with it, but also to have other developers build tools with it.

So we built like a bunch of stuff. You're referencing like a lot, there's a lot of projects, right? And sometimes it can be hard to talk about everything. But we kind of have two separate areas that we focus on. One is apps and one is libraries. And the apps are focused on solving things that we see are big problems on the command line. Use cases that we think are important. So, for example, Glow is meant to solve reading documentation on the command line or discovering documentation on the command line. And so that's a first-party app that we built.

But an example of a library is like BubbleT. So we built BubbleT to build Glow, and now it powers all of our apps, but it also powers hundreds of apps that people in the open-source community have built. And BubbleT is a 2E framework based on the Elm architecture. So Christian was a big Haskell guy, loves functional programming. We all kind of came in to go.

We'd been doing it a bit before we started Charm, but we're like, let's bring other ideas into this space. And so one of the very first things he built was this Elm-based 2E framework so we could build some really cool, exciting command line stuff. We got a bunch of other projects as well. A lot of them are focused, the libraries are focused on really the front end. So there's sort of like a lip gloss, bubble tea, bubbles, harmonica are all front end apps.

They have interesting names, I know. But then we also have back end apps. So charm is a bunch of things. It's not just the company. It's also a tool. It's a set of frameworks and it's the server. So we make everything self-hosted. So charm libraries are based on storage, data storage and encryption and identity, things of that nature. And then on top of that, recently,

we've been really focused on SSH and pushing SSH forward because we think that's one of the most exciting, interesting, powerful technologies on the command line is SSH. And so we're doing a lot around SSH identity, SSH access, remote access via SSH. And so we built this thing called Wish, which is a framework for building SSH tools. And you can wire bubble T apps up into Wish. And so you can SSH into something and get a bubble T interface and have it do whatever. We also have sort of Git middleware inside of Wish. So one of the things that inspired a lot of what we're doing is the Git SSH interface, kind of how GitHub does this, right? So you push and they know who you are based on your public key. You add your public key to their server. And so we built SoftServe, which is a 2E-based self-serve Git host. And that, again, is using Wish and BubbleTee for the interface.

Wow. Low on mine here. It's just so many tool and BubbleT for the interface. Wow. A little mind here. It's just so many toolings. I love the direction. It's crazy that just to see somebody come out swinging like this on the command line, like you almost feel like it's boring in a way. You know, from the outsider's perspective, those who think like, oh, the command line is just a kind of a drag. But, you know, this is really cool tooling.

I mean, I'm super impressed. Thank you. Yeah. And that is sort of a perception that's there. And it's partially true. And it's partially not true, right? Like, it's difficult. Like, one of the reasons we built this is because Kristen and I have been on the command line each for like 20 years a piece. And neither of us considered ourselves like experts, because the learning curve for this stuff is just a sheer cliff wall, right?

Like you could spend your life learning about that. And that's shows you the power, but it's also scares a lot of people off. And so there's like, you know, command line, no, I don't, I don't want anything to do with it. And then a lot of the tools are really dated. Some of the data tools are excellent. So I'm a huge Vim guy, right? Like not the most newest editor out there, but still I use it every day. There's kind of on the command line, you get these things that look like lifer technologies, where it's like you invest your life into learning this thing and it'll pay off in the long run. I spent a lot of time moving to Vim from like TextMate or something like that. And it was difficult at first, but I knew like suffer through this and it will pay off 10 years from now, 20 years from now when you're SSHing into a server and you're just like kicking ass editing text.

Right. So that's one or like piping commands together, learning sort of basic Unix workflow stuff there. All of that stuff. It's a big investment, but it pays off in the long run versus learning a proprietary stack or even a proprietary bit of technology. I'll use a web example for this. And this is by no means to bash the project, but like D3, I always look at D3 and it's like, hey, you can do awesome stuff with D3 in terms of visualizations. And then I start learning and I'm like, this is so much to learn. It's so much to learn just this like very specific framework in this very specific spot. It's not going to be knowledge I can apply sort of across the computing board so when we think about command line stuff um doubling down into your knowledge there should be applicable across a whole range

of tools so i tend to agree with you but i wonder how big the audience is for tooling like this i think of the command line as a subset of technical people or maybe developers or you know let's just call them tech oriented people of those there is a subset who prefers the command line and of those i am one and many of our listeners are that's why they listen to the changelog and they hang out on you know hacker news and changelog news and github and these things but when you're building did you say you're vc backed is that what you said we these things. But when you're building, did you say you're VC-backed? Is that what you said? We are, yes.

Okay, so when you're talking to venture capitalists and trying to make a business case for this type of a company, don't you butt up against that feeling of it being old and very niche and saying, well, we're going to bring it to the future, but is the future interested in the command line? I personally am, so I'm easy to sell on the vision, but I'm wondering if other people are harder to sell on the vision. It can be like that.

There are some good examples of doing what we're talking about doing. So GitHub is a great example of modernizing the command line. They took Git, which is an extremely powerful, let's say edgy tool, right? Like requires a lot of knowledge through it, right? And they brought a bunch of what we call modern product thinking to this they brought social interaction they brought a nice web interface they invented some sort of terminology and use cases like prs pull requests that's a github thing that's not a git thing and so git was designed for the linux kernel and mailing

in patches and all these things that i like really, really small audience to do that kind of stuff. But GitHub mainstreamed this and almost every developer, not every developer, but lots and lots of developers are on GitHub because they kind of did what we want to do. But then they kind of stopped. Right. Like they they did. They did a lot of innovation. They've been acquired. They're part of Microsoft. They're really focused on GitHub actions and stuff, which is really neat. But it's an example of building a huge multi-billion dollar business off the back of a command line tool. And so we think that we can do this. And if you look at DevOps and things of this nature, this command line is really important there. SSH keys are really important there. The workflows for deployment are often in these developer tools that live, in a sense, on the command line. So there's maybe not a trillion people,

especially myself coming from the consumer internet side, music, TweetDeck, things like this, right? Where it's like, oh, you got to get a billion users or whatever. We don't necessarily need a billion users. We're happy with 30 million hardcore developers. And ultimately, our business model is to sell into enterprises anyway, and solve enterprise use cases and developer workflows inside of companies. And so we think that getting that developer mindshare will help us in that business sense.

Well, shout out to your designer, because when you land on charm.sh, you accomplished what many people fail at, which is to immediately have a recognizable and distinguished and interesting look and feel. You mentioned the somewhat, you didn't call them silly, did you? You said you have lots of different names. I can't remember the adjective you used. I don't want to. We like to be unique.

We like to be unique with our naming. Okay, so the unique naming convention. Tell us what inspired this. I mean, you got bubble tea, lip gloss. You mentioned harmonica, soft serve. There's like an ice cream theme going on, kind of like a dessert-y theme going on. Talk about that for a minute. So Christian is the co-founder and designer. So he's doing all of this design. 3D background. So you'll see a lot of 3D models there, which people don't necessarily put in the command line design sensibilities, right?

From the get-go, we wanted our brand to be My Little Pony meets Fist of the North Star. And I think that we're trying to accomplish that, right? Like we want it to be less intimidating than the command line has traditionally been, but even more powerful, right? Like you can do just this amazing, crazy stuff with this, but by making it friendly, it's kind of changing the culture around the command line. Like we don't want to be 1970s MIT, right? We don't want to be like gray beard, Unix. Those guys did a lot of amazing stuff, but it's 2020 now. And so updating the language that we speak to people with is a big part of the project. And we actually like think about culture a lot, both like in terms of our product, our branding, but also the team and how we run it. We like to do things a little differently internally as well. Do you see, I guess, when you get to a certain point, when you SSH, let's say, into your production server,

do you envision where this kind of apps and tooling, the libs, I'm not sure how you divide them, because I'm still learning the product graph you have. But do you envision, because I'm looking at Wish and make SSH apps and you got the parrot doing the dance and you can SSH into a certain server. Do you imagine that someday someone would replace or make their production server easier to navigate and maybe even Linux tooling that you have to constantly Google or whatever, kind of be front and center. Is that what you hope for at some point where you enable a future generation to build on top of the tooling you currently have, basically? Exactly. That's what we're doing.

I would say the best example of a Wish app is SoftServe. So if you SSH to SSH git.charm.sh, you will go into our Git repos. And so this is a soft serve instance, anyone can access it. If you have a public key, if you don't have a public key, it'll ask you for your password. And I think you need to enter and I'll let you in. So custom SSH, right? Like we're letting everybody in, come on in. We've seen you for the first time, come on in. This was something we could do with Wish because it's custom SSH servers sort of divorcing the user accounts from the machine and the application. SSH is really powerful because you know who somebody is. Everything's obviously encrypted, so that's nice.

If you think about setting up a server today on the web, you get HTTPS and you have to manage those certificates. Maybe Certbot manages it for you, but you still have to set that up. You have to do a DNS entry or whatever. You have to think about HTTPS and your domain name. With SSH, you don't do that. You just, and one of the things Wish will do is actually make the server keys for you just when you started up for the first time. So you don't even have to think about that. You should store them someplace secure, but it will generate them for you. But you just fire it up and you have

encryption. And you also have identity in a sense, because people, when they come into SSH are presenting their public key to you. And so you can say like, okay, this public key is attached to this identity. And we've got kind of really far down the rabbit hole with that, with charm, where we allow you to link multiple public keys to one identity. And then we actually do a bunch of encryption stuff where we make symmetric encryption keys, encrypt them for all of your public SSH keys, and then store those encrypted on the server. We don't store private keys at all. So your SSH private key stays on your machine. You pull down all these symmetric keys, decrypt them with your private key, and then you can decrypt all of this encrypted data that's been pushed up to the charm cloud.

So end-to-end then. So you're end-to-end. Yep. Very end-to-end. We don. So end to end then. So you're ending. Yep. Very end to end. We don't know. We don't want, we don't want your data. Data is a liability.

It's not our business model. It's just, we don't, we don't want it. We don't want to know what you're doing. We want to see what you're doing. We are very big on privacy.

So for instance, we don't put analytics into our apps. Your privacy is more important than our business metrics, period. There was a, There was a year period we didn't know how many people were using Glow because we didn't have any Charm Cloud

functionality. It was just a Markdown reader that was not networked. So before we invented the Charm Cloud and all this encryption stuff, Glow was simply a Markdown reader. You pass in a Markdown file and then style it. It will style it with a style sheet. So that's what Glamour is. It's a library that styles up Markdown according to an ANSI style sheet. And it will also detect your background. So if you have a dark background or a light background, it'll give you the right colors there. GitHub, by the way, has used Glamour

in their official command line client to render Markdown. So if you use CLI slash CLI on GitHub, all of the Markdown rendering is happening with Glamour. But we didn't have metrics. We didn't have analytics. And that was fine because we wanted people to have privacy. We also don't think that's even a good way to develop product. You should develop products as the product owner or developer because you have a vision for it.

You have a need you're trying to solve. And you can just bang that out. There was no analytics or A-B testing that went into Git or Vim, right? This was somebody had a vision and they made this incredible tool. And even going to the consumer side, all of my favorite products have been created by usually one person. So I went to work at TweetDeck because I loved TweetDeck. And Ian, the TweetDeck founder, just made this thing. He's like, I want to look at tweets and columns, right? I'd make an error to do that. Last.fm, that was, RJ was a college student and he invented Scrabbling as his university project. He's like, I want to track all my play counts. That blew my mind. I was a huge music fan. I was like,

I've never seen anything this cool in my life. Delicious. Joshua was like, hey, tags, no, freaking cool. Let's just build this thing. and so you see these amazing products come out not because of analytics not because of studying user behavior but because i have a vision that i need to make this thing and that that to us tends to be the most exciting stuff to build so we'll obviously go deep into all the different product areas but going back to jared's question with beta works obviously beta works has a track record so i think there's potentially some inherent risk you know de-risking of maybe putting you and a team together to do stuff like this. But how do you – what is your trajectory then? Like how do you passionately go into this world – very well done, by the way, but like how do you get to this – how do you passionately go into this world thinking out the other end something commercial will come to play. Something valuable will come

to bear of this. You mentioned delicious. Those are great examples of like just scratching an itch, essentially. Like how how will this itch turn into something commercial? Well, we were we were lucky in that we were at Betaworks because they're all about just making cool stuff and seeing what happens. Right. Like they're not they never go into something saying like, let's turn this into a business at first. Right. Like having success is important, but it's always like, let's build something interesting and see where it goes. Technology is great about that. You can invent stuff that doesn't have a clear path to monetization at first. And then it turns into that, like Git again, Git wasn't clearly monetizable and GitHub didn't monetize it for a long time,

but eventually it turned into a real business that was worth billions of dollars. And so we came from this VC firm that was very, very freedom loving and very just creative and very art loving. And so we're like, we want to build stuff on the command line. And John Borthwick, who's, who's the CEO of Betaworks, he's like, Toby, Christian, you know, you guys have done a lot of stuff for us. We believe in you. Let's do some pre-seed and get started. We also had the support of Alex Chung, who's the Giphy founder. So Giphy's another Betaworks sort of like investment slash incubation project. And so Alex is another one of our angels. And so just having this like crew of people who had worked together before building experimental things. Giphy was an experiment.

It was a weekend experiment that Alex built. He's like, GIFs are cool. Let's make a GIF search engine. And then he figured out how to monetize that. But that was sort of the history and the DNA of the early team and investors. It's good to get that trust right away, though. I mean, to have that like, hey, you've done some good work here. Let's do that.

So you said you're a pre-seed. Is that right? We're seed now. So we've raised a few rounds of pre-seed. We closed our seed rounds in December of 2020. So our seed rounds led by Cavalry. They're a German-based seed fund. They're awesome. We just clicked with them immediately. I have a fairly extensive investor network in Europe because Last.fm and TweetDeck are both European startups. So we kind of knew them through that network. Betaworks, one of our lead investors. Also Fuel Capital. So they're a Bay Area based investment firm. They're really, really cool.

And Chris Howard over there has been supportive of us from like essentially day one. So he was in the pre-seed, in the seed round as well. Kevin Carter, he's in all of our rounds as well. He's really great guy. And Tokyo Black, the Looker founders, Keenan Rice and Ben Porterfield, they've been investors. Then we have a bunch of other angels as well. Gotcha. What's the total funding so far? A total $3.6 million. Okay.

You got a burn rate. You have like a slash open page on Charm.sh. I love that, by the way, when people have slash open and it's like, here's all the things we're doing because they're so just transparent about what they're doing. We are. We're transparent. We're not we're not uber transparent. We like surprises. It's like, hey, look at this cool thing that we built. You know, you didn't you didn't know about it. And here's something new. Our burn rate is low where we have six people. So we like to keep the team is a lot like code, right? Like the less code you write, the better. The fewer people you hire, the better.

Don't bloat your team. Don't increase your burn. Hire the right people. The way we hire is we don't do technical interviews. We find people we want to work for us, and then we try to convince them to join us. And the way we find them is they're often just contributing to us. And it's like, okay, here's some of our top contributors. Here's somebody who built something really, really cool

with our technology. Can we get them to join us? Or somebody else that we know sort of like through our network. So we're very proactive in our hiring. And so when you find these people who have really demonstrated the ability to make something from zero to whatever, right, and ship it and support it and make it successful,

you bring them on and one Carlos or one Muesli is worth 50 non-Carloses or Mueslis, right? Like GoReleaser is an amazing technology. We were quite excited when Carlos agreed to join us or even talk to us. We're like, we're fanboys. We love it. We use it all the time, right?

Like, so it's really cool to just proactively sort of seek out the right team members. And it means you can keep the team a lot smaller like that too. What that tells me though is like when we have this listening audience

paying attention to these shows we do and we ask a question like that, we're not just probing like, hey, what's your actual burn rate, Toby? Like, I don't really care necessarily. Like, I kind of want to know, but what I want to hear

is the wisdom behind it because it's one thing to be able to produce this kind of tooling and have this kind of inertia and this innovation. But it's another thing to command it with wisdom. Right. We can almost respect and appreciate what you're doing way more because you have this innovation side of you, but you're also doing with discipline. You're not just like, let's just throw money at it and hope it works. Let's just hire everybody who's ever creative like some companies might do.

Or you see some companies like just acquire a bunch of talent. You're just like, wow, they're just vacuuming up everybody. Whereas here, like you're doing it with a bit more discipline. I think that's an admirable trait, honestly. Thank you. And we actually, even speaking to the burn rate, we need to keep it low because we like time. Time is innovation, right? Like we need time to innovate, to throw things against the wall, to see what sticks,

to iterate on ideas, to try new things. So think very much like an R&D project where you don't, you can't have these really short term time horizons where you're, you need to raise the next round, like next week or whatever, right? Because you're you need to raise the next round like next week or whatever right because you're not going to do the right things that you're not going to make the most innovative thing that you could possibly make like sometimes that takes a little while like you don't ever want to go heads down for two years and go on these like secret missions right like that everyone has a tendency to do that myself included it's like oh man this is i'm gonna make my magnum opus see ya ya in two years, everybody. You know, like that's always a temptation, but you mix short-term thinking and that, and you try to come out.

So we did a long development cycle on this. We did a recent release with the self-hosted Charm Cloud, Wish, SoftServe, a bunch of stuff. that was like 11 months in the work. And that was quite frankly, as far as we should ever go without having launched anything. And it was starting to get to the point where it's like, okay, we're, we're just, we're just iterating and iterating and iterating. And we need to get this out there into the real world. So you want time to try exciting, fun, new things, but you don't want to, you don't want to bury yourself under an ocean and try to swim up because that's, that's just not going to be good and it doesn't make good product that way either you need to get it out there in the real world so finding that balance um requires helpful

to have a low burn rate so you have you have some freedom This episode is brought to you by our friends at Sentry. Build better software faster, diagnose, fix, and optimize the performance of your code. Over 1 million developers and 68,000 organizations already use Sentry. That number includes us. Here's the absolute easiest way to try Sentry right now. You don't have to do anything. Just go to try.sentry-demo.com. That is an open sandbox with data that refreshes every time you refresh or every 10 minutes, something like that.

But long story short, that's the easiest way to try Sentry right now. No installation, no whatsoever. That dashboard is the exact dashboard we see every time we log into Sentry. And of course, our listeners get a deal. They get the team plan for free for three months. All you got to do is go to Sentry.io and use the code changelog when you sign up. Again we talked about how you can ssh right into get dot charm dot sh for what is kind of a tabbed interface of with a menu of your different projects i'm assuming this was all built custom by you guys

to provide this interface. Before we get into how to build these things, are you imagining a world where a bunch of these SSH apps exist as an alternative view from your website, sort of? I mean, it's its own thing, but it's a content viewer, which a web browser also is. I'm thinking about changelog.com and how we have news and podcasts and search and things on our website, but we could have a cool SSH interface where you're doing similar things. And I'm just curious if like, are you imagining

a world where a bunch of SSH apps exist that are kind of like links, you know, customized in terminal browsers, or obviously GitHub uses theirs for you to do get interactions, you know, to use the get service. So different kinds of services, I guess, just start by saying what, what do you see people building with SSH apps? So SSH can do a lot of stuff. And and what you're looking at there is a two way, right? So it is a menuing system. It's to browse through. One of the nice things is that it keeps you on the command line. So you're going to git clone something from the command line. So going back and forth between a web browser and the command line. If you think about one of the sort of innovative things that GitHub did was

this flash-based clip cut to copy to clipboard of the SSH clone URL. Remember? And I think maybe that's natively supported in the browser, but it wasn't at first. I remember that. Yeah. And so that was just a way to get something from a web browser into the command line. So there's some value to being on the command line. But I think there's a few things that can happen with SSH. One, like you alluded to, it's a Git API, right? And so you can start to do really interesting things by layer. You add the Git middleware to Wish, and we give you all the hooks for when projects are pushed and when pools are happening and how authentication can happen. You can start to build applications around that. So for instance, SoftServe is configurable by Git.

So when you first run SoftServe, the very first thing you do as the host is clone the config repo. And so you clone the config repo, and it has a markdown file, a readme file, which is what you see when you first get into git.charm.sh. And it has a YAML that lets you configure access, customize that menu, add collaborators, add their public keys, all these things. So all of that happens via Git. And so you can imagine other configurations happening like this. We're also about to release a version of SoftServe, so we haven't released it,

but probably in the next couple of days, that adds non-interactive SSH functionality. So 2Es are great. They're great for discoverability. They're great for having some kind of UI on the command line for remote controlling various things. But on the command line, the real spirit of it

is composing things, right? So piping the output of something into something else. And it turns out if you run SSH with a command, by default, it does not issue you a TTY, which means that you do not get an interactive T. You'd have to put dash T to get in. So if you do SSH dash T, get.charm.sh space soft dash serve, you'll go straight into soft serve. If you don't add the T,

right now it doesn't do a whole lot. The new update that we're doing, you can say ssh get.charm.sh space soft.serve slash main.go. And it will pipe out that Go source code directly to your command line. You can add the dash S, I believe, flag, and it will style it up. It'll do syntax highlighting on it. And so at that point,

you can start baking these things into command line workflows. You can start exploring, grepping things, manipulating the output of these files directly from a Git repo into other command line tools and pipelines, which we think is a really interesting idea. Because there's not a great way to do that. Now, yes, you can curl something if GitHub has the web interface for it, but this is very discoverable and it's very native to the way that the command line works and the way Git works. So the other thing that's

interesting about this particular 2E, which just for the listener's sake says TUI, Terminal User Interface, but I think they probably... It's actually text. Oh, text. Text User Interface, yeah. Well, thank you for correcting me. I don't even know what it is. I just assumed it was Terminal. Good guess. Because where else are you are you gonna look at your text why wouldn't it be terminal user interface yeah absolutely i'm ready to rebrand that sucker no so the text user interface

is at the command line there are certain things that you come to think about like pagination or you know piping things into less or something. And there's like standardized key combinations that usually work, of course, usually depending on which variant of Unix you're on or whatever. But here you're kind of reinventing a few things. Like you actually have tab-based selection, which navigates between like a menu item

and the content item. And I'm assuming that stuff was invented by you all inside of the build text-based UIs tool, which I can't remember which one that one's called. That's BubbleTee. That's BubbleTee. Thank you. There's a lot of tools here.

It's BubbleTee and Bubbles is a selection of components built for BubbleTee. So some of that stuff is a bubble. It's a bubble that anyone can use. Some of it is custom components that we built for this application. Okay. So I guess what I'm driving at is

if people are all adopting bubble tea, at least in order to build some things, we can expect certain common paradigms inside of a bubble tea based TUI, right? Yep. Okay. Because I would be concerned that like everything would be ad hoc

and super Wild West style. Yeah. Like I like predictabilities of the command line. And it seems like this might lose it if people are all built in different ways. So we're seeing a lot of particular components being used quite a bit in other people's apps.

So the viewport used all over the place. And you'll see we have like a little help menu down at the bottom. That's part of a component. That's something everybody seems to like because they're baking in. There's challenges. We're inventing a lot of this stuff, right? It's kind of like component that's something everybody seems to like because they're baking in there's challenges we're inventing a lot of this stuff

it's kind of like being in the 1980s and inventing a windowing system so we have to take best practices that we've learned elsewhere try to come up with good ideas iterate and experiment there are downsides to it that we haven't completely solved for yet

so accessibility is one of those how do you get a screen reader to read a 2E? Whenever we launch anything, there's always a comment saying like, this doesn't work with screen readers. And that's true. Like it doesn't work great with screen readers. So how do we improve that in the future? We don't have an answer now, but it's on our radar, right? Like that's something important to do. Easy things we've kind of fixed and it's not even easy, but like I mentioned it before, do you have a light background or a dark a dark background when possible and this isn't possible with wish because you can't do

this over ssh but on a 2e that you're running native to your machine we detect your background color like okay you're on a light color we'll give you things that work with this since you can't do that over ssh we picked a color theme that works on light and dark it looks slightly better on dark because we're all on dark but it it still looks quite nice on light background. And so there's challenges that windowing systems and the web have come to solve over the decades that they've been in existence that we want to solve, at least to some degree,

but aren't all solved yet, to be completely honest. Like there's some things that we still need to work on, but because it's so early, that's also exciting. It feels like neat. You can come up with a new idea that works for the terminal and makes sense for the terminal. Some of these terminals are pretty cool.

So Kitty is the terminal that we all like to use. A lot of us like to use it. And Kitty is a really great terminal. And the person who made it has really pushed forward what he wants to be standards in terms of OSC codes, I believe that's what they are, sort of ANSI escape codes that do things.

And so he has native notifications that'll pop up like a notification, like a windowing notification. And you can trigger that from an ANSI code. He's got like windowing stuff, he's got sounds, he's got copy to clipboard is another one of these things that he's added. And so when you start looking at that, I think there can be standards that happen as these applications become more rich that we can all embrace and solve for some of these problems, especially as a new generation of people come into these tools with different expectations. Because I think in the past, people were like, whatever, I'm a gray beard Unix developer, right? Like it works for me. So that's fine. One thing I'm seeing maybe bug report or just curious, this is the kind of stuff that falls out is with this two pained UI that you have

here. You have the menu on the left and then you have the content on the right, which is effectively looks like you're rendering markdown readme or or something that exists elsewhere it's the markdown readme yeah yeah you're using your lip gloss glamour glamour dang it glamour and lip gloss and it's got it's bubble tea glamour lip gloss it's got everything it's got all of our stuff in it yeah it's bubbles all the way down the works yeah so so when i like the git clone command in my terminal i'm just using mac os terminal.app like i can highlight git clone copy that works but when i try to highlight for instance the description for bubble t the fun functional stateful way to build terminal apps and i go multi-line it doesn't highlight the text i highlight the text plus things in the menu on the left and so this is the circumstance where like

you know the the new ui hits the real world of a terminal that's controlled by Apple Inc. Right. Yep. And these are things that have to be figured out and ironed out over time. Exactly. And maybe the answer to that is we changed the layout or something. Right. Because there might not be a good answer to that that exists today,

but that's exactly the kind of stuff you're going to hit when you start, when you start doing this. So I think that terminal in particular is often challenging to develop for. So you'll see the lines have spaces between them probably when you're looking at this. That is a bug in OSX terminal or macOS terminal. Its performance isn't great, but it's the terminal of choice for everybody, right? It's the default terminal for millions and millions of people. So we have to, we have to,

so we're always like, go download Kitty, go get it now because everything, we're super awesome in it, but we can't, we can't rely on that. And so hopefully we push this world forward enough that even Apple pays attention. And we've heard that there's a bunch of people at Apple using our stuff.

So it's a good first step. But ideally the terminal world starts to evolve as well. It's just an interesting world because you have like, in the web, you got browser vendors, right? And then really where you are, and the download kitty was like the old go get Firefox, you know, like back in the day, right?

Yeah, exactly. Yeah. It's like, well, you can't expect everybody to do that. Maybe we'll get to 20% market share, but still the other 80% are running IE9 right back in the day. That'd be lovely, but it's probably 0.1%, unfortunately. It's the same exact problems, but a different space.

Adam, you were going to say something. I can see the coming terminal wars, man. At some point, maybe there's the terminal to rule them all. If apps become more prevalent, if this innovation keeps pushing forward and we hackers find more and more ways to use this and it becomes sort of mainstream.

Or at least developer mainstream. Yeah, I was saying to Toby in the first segment if in the future this evolves to the point where when we SSH into, let's say, our VPS for some reason, if I want to do that, I've got my identity attached to it. It's got a particular UI.

Maybe there's the common everyday command line. But what if we know our stack and so there's something with the Kubernetes pane of glass. We want to see what's going on ad nauseum across the deck. Maybe there's something like that where it's aware. I don't know. Maybe that's a thing. We've been thinking about possibly non-text-based UIs, right? You can use SSH as a protocol for identity and data transfer above and beyond terminal.

And in fact, X Windows does this, right? There's an X forwarding command on SSH that allows you to forward your X Windows over SSH that allows you to forward your X windows over SSH. So that's an old, ancient idea people probably aren't even aware of that maybe is a new life ahead of it, right? Like you can have a UI, having an SSH key is your identity. SSH is a great protocol for encryption, but it doesn't necessarily mean that you have to look at everything inside of a terminal. So we would love to explore this. And even thinking about a mobile app, right? Like maybe you generate some keys on an iOS app, and it identifies with an SSH-based API to figure out who you are. And talking quickly about charm

and our server, this is how this works. So you use SSH to get a JWT back. And then we use that JWT on a bunch of HTTPS APIs. And we do that for sort of performance reasons. And so other people can build APIs using technology that they're familiar with. But we've been doing a lot of sort of work, and we're going to do a big release around this soon with JWTs. So this is moving. Hey, here's who I am. Here's my public key, SSH. Okay, we know who you are the server who knows who you are issues

assigned credential saying we assert that this person is who they claim they are now web server whatever you can rest assured that this person is who they claim that they are and so you can imagine this in ios apps you can imagine it in other non-text-based apps so again going back to sort of the unix philosophy of doing one thing and one thing well and composable apps, by doing SSH well, it opens up the door to lots of possibilities. Are you familiar with the Raspberry Pi by any chance? Yeah, we love Raspberry Pi. And in fact, it's one of our, not all of our stuff works on it, but it's sort of like a

target platform for us. Because one of the things we pitched Betaworks when we started is, hey, there's a bunch of really, what we call low power machines out there that the command line is a really great pairing with. Whether that's a Raspberry Pi or a machine that's like 15 years old, right? There's a lot of hardware out there

that if you try to run the latest version of macOS on it or Windows, it's just going to slow to a crawl. But the command line interface is going to be like rocket fast on this thing. So let's target these lower powered platforms and make cool stuff for them so you can do cool things. I have like five Raspberry Pis and I have them all hooked up to my TVs and they're more or less just Kodi servers, right?

But I would love to actually use it as like a computer in a way that's more meaningful. And so if you start making these sort of rich command line apps, then these low powered sort of Raspberry Pi-esque machines become a viable computing option and you can do neat things on them. And so that's been sort of a Raspberry Pi thought that we've had from the get go. I was even thinking like that because there's a lot of people who have multiple Raspberry Pis in their home lab. There's maybe one for their surveillance or their automation, things like that. In my case, I have a Pi hole and that's pretty much it.

I've got a Plex on a whole different one. It was on Raspberry Pi, but now it's on a beefy Linux server, so I can't really call that a Raspberry Pi, but it's still command line. When I SSH into it, I have Plex running via Docker. It's running on ZFS, all that good stuff. But I was just thinking like when I pseudo Raspberry, you know, RSP Pi, like Raspberry Pi configuration, when I go into that, like that's some sort of like application, you know, some sort of like text application. If that, you know, if that world gets easier to build those kind of things, like that kind of config, is that also a future where you can see this is solving for that can think it's a lot easier for that developer or that team to maintain and build because this becomes

the react for SSH apps or command line apps. That's exactly what we're thinking. It's such a good answer to remote controlling something over the command line because historically you're editing a lot of files. You're going into Etsy and editing like a million flat files, right? To get the configuration you want because you don't have X windows or whatever necessarily all the time.

And so you have to do that. And so offering a graphical interface for that is good. And you've seen stuff like that, right? There's things that have existed, but they look like dots. And writing the code for that is like you're doing C++ or something like that, right? And so you mentioned React, but that's similar to Elm, right? In that it's sort of like a reactive functional design pattern. But that's what BubbleTee is. If you want to develop these

TUIs in a hyper-modern fashion, that's what BubbleTee allows you to do. Use functional programming to build these. Sort of what people have learned over the past 10 years in terms of building web UIs, taking those practices and being able to build a TUI with it, we think is cool. And that use case of

having a bunch of Raspberry Pis and you're controlling them through SSH is exactly the kind of thing that we want to solve. For instance, we launched another project. It was the first thing Carlos built. So when Carlos started, a week later he shipped his first project and it was called Wishlist. And he loves Wish and so he's really excited about Wish. And so Wishlist started as a proxy to other SSH servers and other Wish apps. So he built the Party Parrot thing and all of this stuff over Wish. And so you would SSH into Wishlist, and you would see a list of all of your other Wish apps or any SSH server, and you could go into it. Last week, we released local mode. So now when you run, you can run wishlist on a local machine and it looks at your SSH configuration file, finds all of your hosts

and give you a graphical interface for jumping into all those hosts. That'd be super cool. So discovery, topography discovery of your network, right? You got all your Raspberry Pis in there

and you don't have to, yes, you can tab complete it now, but having a 2E to jump off and discover all of your hosts is a good thing. It makes it easier to do this. You're getting me excited

because my cat config, when I do my SSH config, it's organized. It makes it easier to do this. You're getting me excited because my cat config, when I do my SH config, it's organized. I have all my machines in there. I've got local DNS resolving for machines because I run Raspberry Pi, the Pi hole, and so because I have that, I've got local DNS essentially for all my machines.

So I don't actually SSH to an IP address anymore. I've now resolved those to an actual domain name that makes sense that's only internal. So, for example, my Raspberry Pi or one of them is pimax.home.lan. And when I want to go there, I SSH.pimax.home.lan, and I'm in, right? But I have all of my host files on all my machines the same way. I kind of wish there was a way, build this tool next. Make it where I can command all my host files.

Build this one next. All my host files from one machine. Because I essentially go to each one of them and manually update them. If I can sort of manage all my host files, all my config files that manage those hosts. You should set up a local DNS server and just point all their DNS to your DNS server. And then it can resolve those, and then you manage it at local DNS server and just point all their DNS to your DNS server and then it can resolve those and then you manage it at the DNS server. I guess you could, but... You can

actually do that with PyHole. You can. So, yeah, yeah, PyHole has an option. So it's running its own local DNS server and you can add your hosts manually to PyHole. I've done that already, but what I haven't what I mean by that is like whenever I go to my SH config file,

each host has to be in there for each machine so that it knows what my host name is, what my username is for that machine, that kind of thing. That thing is tedious. No, if you SSH to a domain, like when you SSH to get.charm.sh, there's a DNS lookup that happens.

So those machines would just... But I think he means editing the SSH config. You've got to shove all of those. You make a new host. Great. You've added its pie hole. You've added to your DNS. You can get to it,

but you have to know its name. If you can put it in the SSH config, that starts looking nice. He's writing it into his config, so he knows the names. Okay, I see what you're saying, but it's... Right, so each computer has that SSH host file, that config file. So each computer needs to know so I can SSH and autocomplete to iMac Pro

or to Mac Pro or to whatever the different machines are out there. Like each machine, the DNS is done by a pie hole. But what isn't done is each machine knowing all the different hosts it has available. Like he's saying, like he can, I will say this as an area that we're exploring heavily. So, so check out wishlist for now, that'll get you at least a nice two-week browsing through your SSH config, but you can imagine that evolving for server discovery. I love it. Cause it's going to look at that file, see all the hosts I have defined in there, and give me a list of the things I can navigate as a result. That is exactly what it does.

And you can also run it as a server. So it could be a bit of a bastion host that you can configure and have it be a jumping off point to a bunch of hosts on that subnet or whatever. I'm listening, Toby. I'm listening. Keep going. Tell me more. Well, let's drill down into bubbles and bubble tea because you mentioned this is like your React's Elm architecture, declarative, easier, modern way of building these things.

And bubbles are the components and bubble tea is the framework. Now, this is a Go thing. So does this lock you into Go, is my guess? Yes. And all of our frameworks, all of our libraries, and all of our apps are Go. And we actually get a lot of questions. I just got a question about it yesterday. Do you have a Python SDK?

And the answer is no, we don't. I mean, we're a small team, so we have limited resources. But we think Go is a good language to build command line tools in for a number of reasons. One is you get a compilable binary that you can ship, right? A single file. And you don't have to force all of your users to install all of the dependencies that you've used to develop all Node.js or Python or something like that, right? And so it's sort of a natural fit for this type of tooling. Two, it's just a nice language. It's got a really good standard library. So a lot of stuff that you might want to do to make a really cool command line app is just straight

up available in the Go standard library. It's got an HTTP server. It's got an HTTP client. It's got a lot of stuff inside of it. And so that was why we focused on it. And we like lots of languages. And we come from backgrounds where I was a Clojure developer for six years. I was doing Rust, actually, for two years before I moved to Go. And I got Muesli. I follow him on GitHub. And I got jealous of all the cool libraries that he was starring all the time. I'm like, I want that because he's a Golang developer.

And he's like, super cool crypto thing or whatever. And I'm like, hey, that looks neat. I'm in Rust writing my own Ben coding library because such a thing doesn't exist. At some point, I just I'm like, you know, I love Rust. It's really cool. It's a super exciting language. I jumped ship. I'm like, I want to be more productive. I want to use all the fun toys. And so I started doing Go. And so all of us kind of some of us enthusiastically, some of us begrudgingly had moved to Go over the years just because it is

kind of the answer to building these type of tools. And so when people ask us like, hey, can I do a Node.js version of your stuff? Our answer is no, use Go, but come into our Slack and we'll help you. So we're very enthusiastic about onboarding people in the Go, teaching people about Go. We'll answer any question, no matter how basic, about Go in our Slack. So charm.sh slash Slack. Come on in and ask us about Go, because we'd love to answer it, and we'd love to see more people adopting it, especially for command line stuff. Are y'all in the main Go for Slack by any chance? I'm not a huge chatty person, so I'm not in a lot of Slacks, but

I'm sure that you stay in Carlos. I would say it might make sense to have a channel just for charm. That could be a welcome sort of a tie even like where maybe that channel can be shared between your slack and that slack. That way you can absorb some of the help at large, you know, in the main gopher slack. We can take,

we'll take some of the workload and we'll happily, we'll happily take that. Yeah. It'd be a good onboarding practice or a good growth strategy. I like that. That's really good. So one of the things I've been musing on

is some sort of a changelog command line tool. And I actually was considering Go as the language of choice for that because I really like the way GitHub developed their command line tool, which originally was written in Ruby, and they rewrote in Go. And I thought, if I'm going to just cargo cult a bunch of stuff off of somebody and not have to do the entire job,

I would probably just look at their source code and go from there. And then I found BubbleTee and Bubbles, and it seems like these tools are pretty much custom built for doing exactly what they've already done. So how would you go about writing a command line app with BubbleTee? So the readme is a good place to start, and it kind of walks you through a sort of semi tutorial of how to do things. It's highly based, like we said, on Elm. So there's some concepts that will help you sort of like immutability. And you can hack this and go and do it. You can either do it the go way,

or you can do it the Elm way. So we let you do either things. And some of us do it certain ways and some of us do others. But essentially, there's very few things you have to implement, you have to implement an update method, which is sort of like changing the state of things. And you update and you implement a view method, which returns sort of like changing the state of things. And you update and you implement a view method, which returns a string, period. And the string will look at the state that was updated in the update method and return the correct string. So you've logged in. So username is now set to Toby. When the string renders, it renders out my name or whatever, right? And then there's a concept of commands. And commands are if you're doing something that's blocking or a long running process,

you do a command and it returns. When it returns, it calls update with the result, the model. That's the result. And that's it. That's all BubbleT is, is those three concepts. So you learn about the view, you learn about update, and you learn about commands. And then you can start building BubbleT apps. And then you can learn about the bubbles. So if you go into the bubbles repo, you'll see

spinners, progress bars, input forms, viewports, pagers, that kind of thing. So you can just start stringing that stuff together. It takes a while to master this. And because it's so new, we're kind of inventing design patterns as we go. What should be composed? What should be inside of something else? How do you bubble up state this type of stuff but as we've built bigger and bigger applications we've learned better design patterns and we've tried to bake that into the documentation and bake that into into some of the examples so what's missing from the bubbles if we get into the components or is there anything glaring where you're gonna end up right in your own components because there's big gaps in the library i think that you'll you'll be pretty

good with just sort of like a basic chewy i tend to like to invent crazy things so when i'm making bubble tea apps i rarely start with a bubble i just start banging away and making my own stuff and then um often it'll get replaced by a bubble when somebody just start banging away and making my own stuff. And then often it'll get replaced by a bubble when somebody else takes over the project, somebody more sophisticated at doing this than I am. But you can do it either way. You can start composing these things that already exist. You can get a long way just trying things out on your own as well. So the string that returns, is this including all of the layout information? Or like, are you writing at this string, like a whole block of ASCII the layout information? Or like, are you writing at this

string, like a whole block of ASCII that comes back? Or what does it usually comprised of that creates the UI? So that's a great question. And that's actually what lip gloss does. So lip glosses are styling and layout libraries. So lip glosses so many libraries. Yeah, I know we've got a million of them. So lip gloss will do the coloring coloring and it'll do the layout of all of your stuff. So when you do your view, you'll use a bunch of lip gloss inside of the view and it returns a string. So lip gloss always spits out a string. So as renders, it has sort of essentially what looks like CSS style sheets. And then you style up your stuff with that and return it in your bubble TV. Okay. So I'm looking at lip gloss code right now. It very much almost looks like this.

Does this go? This is go. It is go. So it's almost like a DSL that was written in go. Yeah. Cause it doesn't feel like go code that I would normally read, except for the format dot print line or FMT dot print line. Foamed.

Foamed. Yes, I know. I know. Uh, but I would say format. I don't know why. Okay. So you got lip gloss for gloss for the way it looks and feels and you've got bubbles for pre-built stuff and then bubble tea is like

what everything plugs into then toss it behind wish so that it's remotely accessible with ssh yep what about local storage or i mean these are things that you would just do like maybe use a bolt db or something like you just use whatever's available and go if you're not trying to do well for persistence we offer charm so charm is a lot of things so it was already a lot to take in charm itself is a whole ecosystem so the charm bracelet slash charm on github And you'll see it's a bunch of things. It's a tool that you use. It's a client. It's a server. And it's a set of libraries. So charm KV is a charm managed badger DB that stores your data encrypted in the charm cloud and synchronizes it across every machine that you've linked your account to. charmm FS is a fully encrypted Golang FS.FS implementation with writeability that stores

all of your data in the Charm Cloud and makes it accessible to any machine that you've linked your Charm account to. So if you need a key value store that's accessible across multiple machines, use Charm KV. If you need to access files or store files in the cloud encrypted, use charm FS. And charm crypt is there if you want just some straight up encryption library using those intermediary symmetric keys I had talked about earlier. And if you run charm server or charm serve, that's your own charm cloud. And you can point, you can set charm host equals whatever host you're running that on.

And instead of using our default servers, all of our tools and any tool built with our libraries will then start storing the data on your own personal server. What's going on, friends? This episode is brought to you by WorkOS. WorkOS is a platform that gives developers a set of building blocks for quickly adding enterprise-ready features to their applications. Add single sign-on with Okta, Azure, and more. Sync users from any SCIM directory. HRIS integration with Bamboo HR, Rippling, and more.

Audit trails. Free Google and Microsoft OAuth. Free Magic Link sign-in. WorkOS is designed for developers and offers a single elegant interface. It abstracts dozens of enterprise integrations. This means you're up and running 10 times faster so you can focus on building unique features for users. Instead of debugging legacy protocols and fragmented IT systems, you get restful endpoints, JSON responses, normalized objects, real-time webhooks, a developer dashboard, framework native SDKs.

And even if your team is not focused on enterprise right now, you can still leverage WorkOS so you're not turning enterprise away. Learn more and get started at WorkOS.com. They have a single pay-as-you-grow pricing that scales with your usage and your needs. No credit card required. Again, WorkOS.com. grow pricing that scales with your usage and your needs. No credit card required. Again, WorkOS.com. They also have an awesome podcast called Crossing the Enterprise Chasm, and that is hosted by Michael Greenwich, the founder of WorkOS.

Check it out at WorkOS.com slash podcast. And also by our friends at MongoDB, the makers of MongoDB Atlas, the multi-cloud application data platform. MongoDB Atlas provides an integrated suite of data services centered around a cloud database designed to accelerate and simplify how you build with data. Ditch the columns, the rows, once and for all, and switch to the database loved by millions of developers for its intuitive document data model and query API that maps to how you think and code. When you're ready to launch, Atlas automatically layers on production-grade resilience, performance, and security features so you can confidently scale your app from sandbox

to customer-facing application. As a truly multi-cloud database, Atlas enables you to deploy your data across multiple regions on aws azure and google cloud simultaneously you heard that right you can distribute your data across multiple cloud providers at the same time with a click of a button and the next step is try it today for free they have a free forever tier so you can prove to yourself and to your team that the platform has everything you need head to mongodb.com slash need. Head to mongodb.com slash changelog. Again, mongodb.git.charm.sh when you get in there for me at least in terminal and maybe this has been talked about i just missed it but i don't think so is this not interactive and i would imagine the i hope at least here the the the plan

for this future ssh app for change would be interactive we have obviously news links it should be interactive so if it's not that's definitely a bug okay so it's not interactive what do you mean by interactive meaning that i I can't click the links, for example. There is no selecting the... Oh, mouse support. Yeah, like there's mouse support to navigate. Oh, you have to use the keyboard to navigate it. I've got that, so I'm navigating it, but it's not like I can click the links.

So nothing is... For one, you can't play an MP3 in here. You don't have any, so you're not playing them. I would imagine we have MP3s to play. Well, I noticed also an image on one of them. I think Bubbles has an image in the... Or no, it's Wishlist. Wishlist has an image in the markdown

that says image colon screencast arrow. Right. And it points out to a GIF that we can't look at. Right. So that goes back to the earlier conversation about terminal capabilities. If you had Kitty, you'd be loving this right now. If you want Kitty, we don't actually, we don't default to it, right? Like we don't display

images because most people aren't going to be able to see it. So some terminals will show you an image. Most won't, or most meaning macOS terminal will not show you an image, right? And so we don't try to render that image because most people aren't going to support it. So yeah, it's not a rich experience. It's not a multimedia rich experience. I would love to see that. Like I like to watch a lot of videos and I would love to be able to do something with video and build some sort of like video app.

That's not today, but we can all try to get there as command line aficionados over the next five to 10 years, because I think it's ideal. One of the reasons we're doing this is because we have super web fatigue, like lots of things about the web suck. Like I'm sick of trackers, ads. I don't like the advertising business model. I don't like all this JavaScript that's running on my machine and just these bloated web pages and everything's bloated, everything's slow.

There's ads auto-playing and stuff. And so stripping all that away, getting to the point where you're not tracked everywhere you go is one of the reasons that we moved to the command line. But we lost a lot of stuff along the way, right? We lost YouTube. Bye-bye way, right? We lost YouTube. Bye-bye, YouTube, right?

Like, that's important. We need that. And so it's really early days in terms of that. There are solutions to this that are more or less interesting. So you could run a server that serves a custom web page that displays video or something, right? And then managing that server is certainly doable on the command line. But there's not a great way to make rich user interface.

Some people would like that. So I don't know if you guys are familiar with the Gemini project, but their entire philosophy is they're basically like Gopher 2.0, text-based web replacements, HTTP replacement. And they also have web fatigue probably more than we do.

And so they've gone into this world where everything's supposed to be stripped down. It's just text only, right? Like if it's not text only, they don't even want a part of it. So there's cultures out there that embrace just that. But I think it's really important to look forward and how we can make this even richer. Maybe I'll reframe my question there, or at least the statement I was trying to get to, which is, you know, I can't click the, you know, the get links or the different links in the read me's. So that's like a stopper for me. It's like in terms of what we're trying to build or what we aspire to build is then if we want to have an app, an SH app that is built with bubble tea, you know, style with glamor, all that good stuff behind Wish.

And we're doing all this fun stuff. And we want to allow our listeners, our audience essentially, to see our podcasts, see the index of all of our shows, but then also be able to play them. Is that a possibility? If it's not, what's the hurdles to get to that point from an interface standpoint with going this route? It is not if you go through Wish. So SSH itself is limiting some of this stuff. There are solutions. If you build, if you guys build a changelog command line app and you have people download it, you could have it open stuff.

You can have it open something on their user's machine. You can have it open a web page. You can have it do lots of things. Over Wish, that's running on the server. So you're not going to be able to say, hey, open this file or whatever. You can do that though, as long as you build a tool that they will run on their own machine. And you can do that in numerous ways. Sometimes the terminal itself, and I don't know if the OSX terminal does this, where they'll just take a hyperlink and make it clickable. A lot of terminals do that. So you can just open the browser. But you could also just execute in the background the open command or the xdg-open

command, and it will open up the appropriate application for that MIME type. And so you could open up an MP4 or whatever, right? And it would probably open it up into Apple Music or something like that. And so there's definitely ways to handle it if you build a local tool if you're trying to make it remotely accessible that's limited and that's actually a challenge we've had because those git clone urls you can't execute that right like it's you're back almost in the github world to some degree where you're copying and pasting it into another window. Now you're still in a terminal, so that's nice. But we're looking at options there. SSH to some degree as the viewer is limiting there and that it doesn't support linking.

Hypertext linking, right? Like that's not a thing on SSH. So do we write our own SSH client replacement that offers a bunch of cool, rich options? I don't know. we do it's like maybe you should just write your own terminal the one that rules them all and the reason why i kind of get there why i wanted to like sort of option click is because that's the experience you get in vs code for example yeah so traditionally in a even in an editor you're not necessarily interacting

with the links in it is so maybe pushing the boundaries of say playing a video or seeing an image or playing an mp3 maybe that's pushing the boundaries of the protocol but from a interaction standpoint i would desire or expect to be able to option click a link because that's what you could do in other editors and so this emulates it at least visually even though even though it is terminal and you know it's you're innovating that part of it, my expectation as a user is like, can I option click these links and do different things? But the answer is no right now. So it's more like understanding what the limits are. And how do you, if you're trying to innovate the command line,

how far down to the middle do you have to go? Like, do you have to kitty it? Do you have to go? Do you have to kitty it? Do you have to make your own kitty? You know what I mean? Or can you just adopt? Who doesn't want to do that? Right. I mean, but do you have to?

Is that how far you have to go? It's a great question. And we actually asked ourselves that initially. Do we want to make a terminal? And we explicitly said, not yet. Not right now. Because there's a lot of other stuff that has to get built at the application level. We're getting to the point where that's sort of the limiting factor.

It seems like the apps are limited, though, by the current standards. And if you could evolve those current standards, maybe the process of putting these apps in the libraries and the different things you're putting on top of it might maybe i'm wrong because i'm not i'm not doing the work but maybe it might be easier to to just you know take a stab at it for a month do like a month project and see what it would take to do that or maybe longer building a terminal is a big task because it's got like 20 years of backwards compatibility that if you don't support people will be raging on you right away. Like, oh, it breaks. Because there's so many command line apps, right? Like, oh, Vim doesn't work through Tmux for me anymore

or whatever, right? So there's a lot of stuff that people are doing out there that you need to support. And it's actually a pretty big job to do it. We are, and this is talking about a sort of secret project that we were looking at at one point that we decided not to go down.

We're like, hey, VR is kind of cool. Maybe we should do a VR terminal. That's kind of an interesting concept, right? Like it's a new platform. How do you bring the command line to this new platform? How do you make a really good mobile command line? How do you make a really good mobile terminal?

So I think there's desktop terminals. I think there's other platforms that could have really cool terminals. I think maybe we even explore some of that stuff at some point in time. But as of right now, we've been really focused on, I mean, even though Bubble Tea and Bubbles are some of our biggest projects, Bubble Tea is actually our biggest project at this point. It just passed Glow in terms of stars last week. A lot of our effort and engineering research has gone into the SSH side of things. So the identity side, the encryption side, how you handle all of the Git protocols over SSH.

Fundamentals. Yeah, because it's also, it's a little more, it's a little more separated from the UI aspect. The UI is great, right? And it's what gets people in the door, gets people coming to us. It's really nice to show off. And it's fun. It's super fun building this stuff. And we need to keep pushing that forward. But a lot of the value of what we're creating,

I think, is at the identity level and really pushing SSH forward. So that's another area for us to kind of... There's deep rabbit holes everywhere. And you can start going down them. And as we get bigger, we'll probably simultaneously dive into multiple rabbit holes but for now we can kind of like dip into a couple of them so if we

redirect back to that side of things the ssh side you have soft serve which is a wish based get server correct yep you have wish list which is a wish-based SSH directory. Are there other wish-based apps out there or even an idea for apps that people can wrap their heads around? So yes, Charm is also wish-based. There's a version of Glow that's in beta now that will soon be launching that's based on the new Charm. So Glow sits on top of Charm as well. Glow is the markdown rendering thing. that will soon be launching that's based on the new charm. So glow sits on top of charm as well. And the use case in glow,

low is the markdown rendering thing. Glow is the markdown rendering thing. And the charm is the charm is the encryption and identity and cloud storage. Okay. And so in glow, if you open up a markdown in glow, you can hit S and S is stash.

And say you just downloaded glow for the first time you ran it in a project directory, they'll discover all the Markdown in that directory. And they're like, hey, this is interesting. I want to save it for later. S, stash. I don't know what that is. Seems cool.

Stash it. Okay, great. It's stashed. What we did behind the scenes there is generated you a new SSH key pair, generated you encryption keys, encrypted all of that Markdown's file, hit the charm server with your key,

created a new account for you on the charm server, and then pushed up that encrypted Markdown for your account onto our server or a self hosted server if you if you want that. And so all of that SSH mechanic behind the scene is happening through wish. And so Charm is a Wish app and Wish library that applications like Glow can use to satisfy any kind of storage or encryption or persistence or identity use cases. There are third party Wish apps that were starting to come out. We saw two Wordle clones launch in the last three weeks over SSH. Play Wordle over SSH. And they're really great. Like one of them was on,

Clydle was on the top of our Golang on Reddit all last week. And it's, I don't have its URL off the top of my head, but it's a great implementation of Wordle over SSH. And people loved it. Like they, something about this like resonates with people. It's like, hey, it's kind of like the BBS days days or something just the fact that you can be on the command line you can use ssh and all of a sudden you're playing wordle is kind of a neat idea and you can even like score stuff because it keeps your public key or whatever i know that they're working on a lot of this stuff

but it's like hey identity plus remote access building i didn't install anything i didn't install world i just had ssh lying around and I was able to use this thing. So we saw two of those launch. And then some kind of like toy kind of stuff, but it's pretty new. Wish is like, I think, a month and a half it's been out in the wild or something like that. So it's all relatively new.

But it's exciting to start seeing people not just build stuff with it, but gain some success. So we love it when people build with our tools and then they go to the top of Hacker News or they're trending on GitHub or something. It's like they're able to build something that resonates with the community with the tools we're giving them. And that's pretty neat. There's a lot of sort of popular BubbleTea apps. So BubbleTea has almost 500 applications that have been built with BubbleTea. It's been out there a little

longer. So there's out there a little longer. So there's this thing called Slides, this guy Moss created, and it's the second most popular BubbleT app besides Glow in terms of being just like a pure BubbleT app. And it's like PowerPoint for the terminal. There's, like I mentioned, the official GitHub client is using Glamour. It's not using BubbleT, but that's like a very big distribution of one of our libraries. MinIO and their official command line tool is using BubbleT. That's a new thing. SuppoBase, so I know you had the founder on recently.

They and their official command line client are using BubbleT. So we're starting to see good BubbleT distribution in some pretty large, pretty hot projects. And a bunch of fun stuff too. There's just like fun projects that people make with BubbleT that's really interesting. Mergestat is a great one.

This is treat your Git repo like a SQL database and run SQL against it. And he had a functioning tool and then he kind of discovered our stuff and started layering more and more. He tweeted out, he's like,

I just added a bunch of BubbleTee stuff to merge stat. I'm going to add all the charm stuff to it. We're like, yes, please do. You know, that's awesome. So we're seeing people get excited about it, build it, and then achieve some success with it which is which is neat i'm over here googling all these names that you are saying actually merged that

i think is by the ask get guy who we've talked about in the past so small world querying sql and whatnot or querying get like it's sql uh pretty cool stuff definitely hook us up with a list for the show notes i did find kleidel but uh you probably even think of more after you hang up with us and say oh here's another cool one so we'll have like a nice list of things using either wish charm or bubble tea and or bubble tea out there in the wild because you know sometimes just seeing that those things are the inspiration you need for the idea and actually make it click.

I think Bubble Tea right now clicks for me in a way that I'm not sure Wish does because I'm seeing the examples you're giving and I'm like, these are cool. But then I can't go anywhere from there beyond without more interactive things than is currently available with SSH. That being said, I'm just a guy with very small ambitions and can't think of cool things. I see them like,

oh, now it all makes sense. So the more examples, like you said, it's only been out there for 30 days. So more time, more people will start to play with this and come up with cool ideas. And if you're listening and you have a cool idea for something like an SSH-based app, definitely holler at us, let us know about that. And then let us know if you would like to try it with Wish or with Charm or with Bubble and Bubble Tea, all these things. So many names.

Lipgloss, Harmonica. Lipgloss, maybe some Glamour in there. I'm not sure Glamour does anymore. Oh yeah, StyleSheets-based markdown rendering for your CLI apps. Yes, Glamour. anymore. Oh yeah, StyleSheets based markdown rendering for your CLI apps. Yes, Glamour. As you were naming those examples, I was seeing how we are definitely,

our desires for what we want to do is certainly the edge case. Right? I think we could use BubbleTee for sure and build a really cool interactive changelog command line tool where you could play MP3s. As long as we can get that stuff done and go, right? Like to play the audio and and stuff which probably has some cross-platform libraries that you have to use to interact with the audio libraries of various operating systems

like bubble tea is just for the interface right like you can build full-fledged go applications and use bubble tea for your interface, right? Yes, you can. One thing I'm most excited about, and I haven't seen a lot of people build with it yet, but it's kind of futuristic and weird, is the Git stuff. Building Git-based apps, what can you do with Git? Could you clone a repo and you guys are pushing new episodes into it all the time and you're just fetching the new versions or whatever? Or is there a collaborative option there? For instance, this episode was maybe a repo and I could push up these links to it and

you guys could add stuff to it too or something like that, right? So I think Git-based interaction, super unexplored. And to me, that's the most exciting part of Wish is like, oh, you can start building these Git-based apps and using Git as a way to control things and as a way to collaborate. That seems interesting. And if you can probe it like a database, which it basically is,

then maybe you could use it as sort of like a pseudo-database almost to, like we have a web app, maybe Postgres can pull data from that Git repository via Webhook with GitHub or some other way to essentially be... We already do that for our show notes. Our show notes are synced with a GitHub repo. Right.

It's very similar to that. Yeah. You can make a Wish app that does that. So you would get in the Go code, someone's pushing something, here's what they're pushing. And then in the Go code, you could use your Postgres driver to just populate the database with the file or whatever got pushed into Git. So from a CMS perspective,

it's kind of interesting. And that's how we're doing the CMS bit of soft serve is with the Git, all the Git pushing. Soft serve being the self-hostable Git server for the command line. Each time we say a noun,

I have to describe which one it is because y'all have so many projects, man's crazy it is challenging to keep track of what yeah imagine having to make 3d models for all of these things well you're doing it on the hard mode you took that upon yourselves you know we did but uh that's the fun part right let's go maybe ask you one question here, which was, you named a few examples out there. When you were in the final stages, and this was Wish, right? Like, no, these were Wish apps, right? That you just described. I'm trying to keep track.

Sorry about that. When you were in the final days, I suppose, of pushing, and the team was dreaming, oh my gosh, when we get this out there, people will build this. What were those dreams? Like, you described some things people were using. GitHub using Glamour or Lipgloss, one of those two, and I think you mentioned Superbase, what they used. What were some of the apps you imagined we build with Wish? We actually built Wish and SoftServe because we had a very specific need for it. So we had built Charm, the new version of Charm,

the self-hostable version of Charm, all that Charm KV stuff, all of that. And we needed to launch it and we wanted to move Glow over to this backend. And the way doing all of this works in Golang is difficult because if you look at Golang code, when you import a library, put a git url you get it's like literally a git like github.com slash charm bracelet slash charm slash kb whatever right

whatever library you bring in is literally a git url and so we wanted to it was not ready for prime time but we wanted to get it in front of people. And so we needed another place to put this other than our public GitHub profile. And we weren't ready to overwrite some of these apps with the new versions and we wanted to bring them in. And this is kind of complicated inside of Go to make it happen. And so we're like, okay, we need a new Git place

where we can pull this stuff. And so we started building our own Git server. Like, let's make it on the command line. Let's make it over SSH. Let's do all this. And so we started, we created Wish, essentially backported it into Charm, but we created Wish so we can make soft serve so we could launch Charm. We wanted an alternative Git space that wasn't GitHub because there's times you need a Git repo. Git is very much about promotion. GitHub is very much about promotion, right? You put it out there, everyone's

going to see it, but you sometimes want to put something out where people can use it, but you don't necessarily want to broadcast it out to everyone. And so that's why we made SoftServe as your second Git host, right? Whatever. And so that was why we made Wish. But after we made it,

we're like, wow, it's kind of crazy. We just wired BubbleT up into SSH and we're wiring identity up and we can do all this really cool stuff with git and then our wheels started spinning we're like okay it turns out git is awesome for cms and so some of these things i just told you guys about like the podcasting and the notes and editing like that's my mind in wishland right like i've been i'm like now this is possible. These things are possible. So it's time to start thinking about how you can leverage Git as an API. How do you use Git as

the way you manage an application? Or what can you do from a collaboration standpoint with Git? That's not just writing code. And so I think it's really early days there, but it seems incredibly exciting. It seems interesting because it's not how you would typically do something. Being able to configure a YAML, check out the config repo, edit the YAML and push it back to soft serve and then soft serve behaves differently is kind of an interesting new concept. To use Git as a way of configuration seems pretty powerful. And I think we'll see more and more of that. I'll throw this out there too. I don't know if this is a one-to-one

because I almost would imagine just managing my own Bash profile or the ZSH profile. And I was thinking of like, oh, my ZSH. This is something that a lot of people install. It has config essentially where you can choose your theme and a bunch of stuff.

And I'm wondering like, would, oh, my ZSH be a good candidate for, you know, some sort of app like this where it's like rather than editing your actual profile, the ZSH profile file itself, would it make more sense to put that in a config? I don't know. Like is that where you see that too or like some tooling or dev tools have like config locally and an app makes more sense rather than like opening up the file i don't know what do you think we're looking at dot files as well so we've got we've got some stuff in the works there because it's a natural fit for what

we're doing and it's a lot of what you say like imagine you've got a windows machine more more realistically you have a macbook and you've got a linux, more realistically, you have a MacBook and you've got a Linux-based VPS running on DigitalOcean or something, right? And you've got Vim on both of them, or you've got some configuration that's slightly different. Tmux works different on Mac than it does on Linux or something like this, right? And so you have different versions of the same.file. How do you manage that? Well, immediately you think Git is useful there, right?

Because the way I'm managing my dot files now is in branches on a Git repo and it's quite hellacious. But it's a problem we're looking to solve. And we've actually got some prototype stuff around. I can't talk too much about it yet because it hasn't been launched, but we're close to launching some stuff that plays in this area. So helps in the dotiles area. Maybe even an actual.files manager. Potentially. And branches on a Git repository,

which would be so cool. Like each branch is a machine, for example. Like this machine is that branch. Yeah, and that's what I do now and managing that manually is not fun. I bet. So tooling around that is definitely desirable. Well, let me suggest a

name for this skunkworks project i would call it cupcake you know what i will tell you what its name is and its name is donut oh so close pretty close donuts cool so you guys are getting that you're getting the scoop on that we haven't announced it so charm.sh slash i'm just kidding don't insert name here but uh that's where it's going to live, right? Of course. Probably, yes. Donut sounds like.file. Doesn't it?

It looks like a. too. That's true. That's so cool. Okay, okay. I'm digging it. I think that. I'm interested, yes. Between Donut and what you're doing, I can definitely see why you are so passionate about innovating in this way.

My hope is that commercial opportunities in the future just because sustain. Yeah. But not so much that like I just hope that I hope that you have enough runway and can sustain enough runway to keep innovating because these are definitely cool things. I'm just just not sure except for on the wish Cloud, the Charm Cloud kind of aspect. That's where I can see a commercial offering for you when you get more and more people to adopt SSH-based apps. And why run your own when you can run it there? So it can be managed. I can run it on my own. I can run it on a VPS or do it on a Raspberry Pi, because I'm sure you've thought about that. But do I have to? Maybe I can pay $10 a month or Enterprise Pay $50

or $100 or whatever the number is. you know, like that's where I can see something at least in the near future. So, but you know, I'm loving the direction for sure. And the naming and the fun behind it, that's what really makes it fun. I mean, it makes your job, I'm sure more fun. I'm sure it makes the team have a lot more fun with meetings. Like calling a new project called donut is a lot more cool than something that's lame. Basically, you know, it's lame. Something like always better than something that's lame basically you know that's lame something like always better than something right right right anything else in closing what

have we not asked you that you want to share before we close out um i think we covered a lot here um thank you for having me on this was a lot of fun it's a lot of fun yeah i would say if people want to follow us come to at charm clI on Twitter and charm bracelet on GitHub. That's the best way to stay up to date. Or like I said, join our Slack charm.sh slash Slack. But other than that, this was, this was great. One last thing that I'll say before we close that, I just thought of this because I'm looking up charms license.

I would say that since charm is long-term, probably the enterprise commercial play, and it can be self-hosted. And yet, you know, maybe you want them to host it for you that's i just want to say you got street cred because it's out there it's open source it's mit licensed so like you really are putting your money where your mouth is in that regard even with that piece that is probably going to become you know the commercially viable part of all this stuff which is just free and open and really cool stuff. So props to you on that aspect as well. Thank you. I say even more props too on all the other tooling

being able to wire up to a self-hosted charm. Like, yeah, have it as a cloud as managed is cool, but then a single config, it sounds like, you know, I was thinking of like Ruby days and I've even forgotten all the terminology. I haven't done it in so long, but like wherever you point Ruby gems to, what's that file, Jerry?

Rubygems.org. Yeah, exactly. In the top of the file, you can just point it wherever you want to get your gems. Same kind of, it seems like similar, a similar change in terms of config. Just point to wherever.

It is. It's just an environment variable, charm host. You set your charm host environment variable. And in fact, once glow is launched, the new one that points to the charm pod, even glow, when you stash, it'll start stashing it to your CharmPod. Anything that's built with our stuff will just sort of magically

work on your self-host. That's important to us. And from a commercial standpoint, it's not necessarily a bad idea because what you need as a self-hosted person is quite different than what an enterprise of 10,000 people need, right? And Go actually makes this easy because we design all of our stuff with interfaces,

implement those interfaces in SQLite on the self-hosted side. And then, for instance, on our industrial strength charm cloud, we got Postgres backing it. And we just implement all these same interface methods in a different, more sort of industrial-grade backend. So we think through some of this stuff or stats like for monitoring and for all of this stuff. We don't even implement that on the self hosted.

But on our servers, that interface has an implementation that points to Grafana. Pretty cool. So before we let you go, we'd be remiss not to mention the footer of the website where you take haters. Oh, yes. And you redirect them to Dev Null. Tell us the story here. You're sending the haters to Dev Null.

Where else would they go? Where else would we want them? Good question. Well said, well said. And you've trademarked it. That's right. Well, I want the t-shirt. So put them on a t-shirt so I can wear it.

We are working on swag. Yeah. There is stuff coming soon. Cool. Give me a sticker. Give me coming soon. Cool. Give me a sticker. Give me a T-shirt. Give me a pin, you know, some sort of glossy pin. I'd be so excited about that. We will. Give me a cupcake and give me a cupcake. We were thinking about keycaps like we all have mechanical keyboards. So like something something like that. Yeah, that would be cool.

Yeah, for sure. Well, good luck to you guys and keep it up. It's a really cool's really cool stuff i'm definitely gonna check it out bubble tea for this skunk works change all command line thing that we've been playing around with so we'll give it a shot awesome and just let us know if you have any questions we're happy to help you all right toby thanks for your time all right thank you very much that's it this show's done thank you for tuning in. Big thanks to Toby Padilla for sharing his time today on the show. And of course, thank you to the rest of the team there at Charm for all the work, all the details, all the vision, all the focus on such cool tooling. We're so excited about what you're doing. And if you are too, let us know in the comments.

And on that note, big thanks to you for listening to the show. We appreciate your attention. Do us one big favor. If you enjoy the show, share the show with a friend. That is honestly the best way for you to help us to grow our shows. We mentioned Change All Plus Plus, but really what we want you to do is just share our shows with your friends. That's the best thing you can do to help us. And big thanks to our friends at Fastie for having our CDM back. Check them out at Fastie.com. And of course, Breakmaster Cylinder. Those beats are awesome. They're banging, as they say, slamming, as they might also say. Thank you, Breakmaster Cylinder. That is it for this week. We will see you next week. Game on.