Bethany Janos 
Brittany Ellich 
Eggyhead 
Jonathan Tamsut Bethany (00:00) Welcome to the Overcommitted podcast, where we discuss our code commits, our personal commitments, and some stuff in between. I’m your host this week, Bethany, joined by…
Erika (00:09) Erica.
Brittany Ellich (00:09) and I’m Brittany.
Bethany (00:11) We
are software engineers who initially met as a new hire group at GitHub and found a common interest in continuous learning and building interesting projects. We continue to meet to share our learning experiences and discuss our lives as developers. Whether you’re pushing code or taking on new challenges, we’re happy you’re listening. I’m really excited to welcome Nick Gierakinis as our guest this week.
Nick is a fellow co-pilot engineer and in his free time has been building an event platform on top of at Proto Network. And I’ve been following him on Blue Sky and I’m just like, this is so cool, but I don’t understand half of it. So I am just really thrilled to finally get to pick your brain. Nick is just truly one of the most intelligent people I’ve had the honor to work with. So very, very excited.
Nick, do you want to introduce yourself and give a high level introduction?
Nick Gerakines (he/him) (01:01) Yeah, hey, thank you for the warm welcome. My name is Nick Jerikiannis. I am a software engineer at GitHub. I’ve been working all over the back end space doing online education, infrastructure, DevOps, a lot of AIML, CS stuff, and video games. Also back in the day, I was doing a lot of web 2.0 things, which is sort of my origin story about how I got to where I am. And I’m very excited about that.
Bethany (01:23) Awesome. Well, let’s kick it off with what exactly is at Proto. Really just curious the overview and what are the benefits? Why would somebody want to build on top of it? What makes it fun to work on now and if there’s any frustrations.
Nick Gerakines (he/him) (01:37) Yeah, that’s a fun question. A lot of people have been asking what is Ad Protocol, AT Proto, Authenticated Transfer Protocol process. It goes by a few different names, but Ad Protocol is really a set of technologies that center around identity and data. Like a lot of, you know, just decentralized technologies these days. There are a couple of things that make it different and they’re worth pointing out though.
⁓ The first is that it uses this thing called a did a decentralized identifier as the core
identifier for individuals, organizations, agents, whatever else is operating in the atmosphere. A did is a string that has a structured prefix. So did colon PLC colon data, did colon web, et cetera, that describes a shape of an identifier. So like did method PLC, one of the core did methods used very heavily in the atmosphere, which also I get a kick out of that word atmosphere. Every time I use it, I sort of laugh at myself.
has a data portion that is a cryptographic signature of the genesis record used to ⁓ create the identifier.
Another did method officially supported in that protocol is did method web, where the data portion of the identifier contains a host name. So the goal of dids is to really create a way to look up a did document. A did document is this JSON structure that has a couple things like this is my ID, it’s self-describing. Here are my cryptographic keys called verification methods. And then here are my core identity and data services. So that sort of spills into the next major component.
of that protocol and that is the personal data server or PDS is there commonly referred to. A PDS is a host. So it’s a web service, right? That is referenced by DIDS and allows for at protocol records to be stored in them, keyed off of the identity, a collection, and then a record key. In fact, those three components make up what is commonly referred to as an ATURI or an at URI.
Things like social media posts, interactions like likes or reposts, profile information, or really anything else that’s created and used in the app protocol ecosystem. It also stores blobs, so like your images, your video, your other non-record files, PDFs, attachments, etc. that are also associated with records. So
The real important thing about app protocol and why these two things are so important is because together they provide for user mobility and data ownership. So when you look at where and how blue sky social, the public benefit corporation formed, it came out of Twitter pre Elon with the goal of creating a better public forum where users have lasting control over their identity and their data. So with that protocol, once you mint a did that data is yours. It’s yours forever. Right.
you have the keys, like the private keys, which are the counter of the public keys contained in your did document, right? And you can control where your did document points to what server is hosting your data, and you can control the signingness, the validation of the data that’s stored in your PDS. Yeah, so if you don’t want to host it on one…
organization or business, your PDS that is, you can move it. You have the ability to change your geographic homing of data, for example, which is very appealing depending on your interests.
Erika (04:58) So one question that first comes to mind. if anyone, well, so how do you access it? First of all, how do you access it and prevent other people from accessing or spoofing your identity?
Nick Gerakines (he/him) (05:00) Yeah.
Yeah, so everything that you do is central to these verification methods, these keys, right, that are found in your did document. So when you have a data repository, the actual internals of the PDS are such that it’s a sort of…
self-signed, not encrypted, but cryptographically signed data structure. And it’s based around Merkle search trees, MSTs. And the idea is that all of your records, you export a repository, they contain signatures. It’s actually kind of structured similar to how a Git hierarchy, like internals, you have a root commit, and then every additional change is an increment thereof. Therefore you have a chain of authenticity of this structured data.
So it would be very difficult given modern equipment and practices to fake or break the cryptographic signatures that are associated with your specific records.
Erika (06:08) So you technically own your data, but it would be really hard to modify it.
Nick Gerakines (he/him) (06:13) Yeah, so.
Any operation will it be really hard to modify it without the cryptographic keys, right? So every time you go to change or append information, you’re basically saying, hey, here is an action or a transaction that is, you know, replacing or appending additional data. And here’s the cryptographic key, like the content identifier, the proof that this chunk of data content change is from me, the owner of this data, and it should be stored.
in a way that is alongside all of the other data that it can be verified as well. Yeah, all of this really, all of it is really important to, you know.
allowing content to be trusted but verified in this broad way. The relay system, for example, when I have information on my PDS and I create a new post, it actually gets transmitted to a relay and that relay broadcasts not just the record, but also broadcasts the cryptographic signatures and verification. So any consumer can go, hey, I just saw this new record being posted by this user. And there’s also a
check
some next to it, a signature, and knowing the verification method from their DIP document, I can verify that that content is actually from that person specifically, because no one else has access to the keys, thus it’s more difficult to spoof it. Yeah.
And that relay system in a very broad sense also enables the whole concept of user choice, right? So in the atmosphere, there’s this concept of algorithmic choice. It’s a really important like key phrase. And what it does is it’s the emphasis is on user control and choice. So a user may not have the infrastructure and tooling to download every record as they’re coming down the fire hose, right? With almost 40 million users, it’s a lot of data, you know? However, services like Graze.
social or some of the other feed generators, they have the ability to let people mix and match and create their own feeds, right? So you can view content the way that you want to, not just the way, you know, one of the existing social media providers tells you you should observe and consume like the activity and the data of your network. So that’s like a really big thing.
The goal of the goal really is like composability and choice labels and the moderation architecture is built with the same mindset. And, I know that there’s like a lot to it. but it’s been, it’s been a lot of fun in some ways. ⁓ Paul, the CEO or the CTO, ⁓ made a comment, post a while ago saying something, something to the effect of every identity is effectively a host name because all users are URLs. And when you think about like where.
and
how people have this core identity and the ability to move it and change it, I think that makes a lot of sense. And it’s very simple, but not simplistic view of the world.
Erika (09:02) Yeah, well then.
If I’m understanding this correctly, you correct me if I’m totally off the mark here, but I would have control over my identity because I’m the one who generates it. So if I wanted to take myself off, it’s my data server, my data that I could then delete instead of expecting Facebook or whoever to respond to my delete request. And who knows if they actually fully delete me out of their database or, ⁓ yeah.
keep dangling records around.
Nick Gerakines (he/him) (09:30) Yeah.
That’s exactly right. And I have some notes for later when I talk about smoke signal, but that’s really the core of this concept called the credible exit, right? With, you know, a lot of services and tooling like users and their data and their activity are as much as the product as the actual product that the users are using. Right. And, the whole concept of the credible exit is that because everything is open and users have ownership.
and mobility of their identity, and then of course control and mobility of their own data, then if they’re like, hey, I don’t want to use the Blue Sky app view to view feeds, I want to use dear.social or some alternative, then they can do so. And because they have all of their data and the protocol is based on agreed and open standards, they can just start using the next tool, hopefully with minimal ramp up time.
Brittany Ellich (10:25) So question about this, because I know very, little about this, but I use Blue Sky an awful lot. So the idea is, is if you’re using something like Blue Sky, Blue Sky is built on this protocol, correct? And so if one day Blue Sky falls out of favor, I could take all of the data that I posted to Blue Sky and then move it somewhere else? that? okay, cool.
Nick Gerakines (he/him) (10:26) Yeah.
Mm-hmm. Yep.
That’s the idea. Yep.
And it provides some really interesting alternatives for other scenarios. Offline and local networks, censored or censorship across regions or businesses, depending on how things go. All of those are real scenarios where if you want to be able to post freely and openly with your community, it allows you to do so.
Yeah, I’m gonna put a little pin on that though. That’s actually sort of an interesting segue.
Bethany (11:10) Awesome. Well, let’s since you mentioned it, how did you end up starting to build SmokeSignal and what has the development process been like over the past, it’s been a year and it just, I saw things about it turning one recently. Awesome.
Nick Gerakines (he/him) (11:26) Yeah, in fact we
we just had a little one year anniversary party Partners and I and some friends. Yeah, it’s been a lot of fun originally smoke signal Okay, I need to step a little back
A long, long time ago, I was in the Web 2.0 scene and worked at Live Journal and then at Yahoo on social search on Delicious, right? So I was sort of steeped in the whole ⁓ Flickr upcoming Fire Eagle Delicious space, working a lot with Yahoo Answers.
building some fun stuff. And I think what I really loved about Web 2.0 ⁓ is that it was like that whole movement was really brought. ⁓ It really spoke to me because it was all about social utility. The idea was that, you know, using the product itself wasn’t the end game. You weren’t just like dooms rolling. You were on there with the intention of extending, building, creating, and discovering connections with other people who wanted to do other things. You know, I shared my bookmarks with you because we have similar interests.
I go to upcoming because I want to go to events. I go to Flickr because I want to experience the world from your perspective and so on and so forth, right? There was a lot of really engaging product that was not trying to just control like totally and completely assume consume your attention and energy. So fast forward a while. I had written a book about making Facebook applications. I had
made some products and sold some things and got really excited about ⁓ Activity Pub as a spec and what was becoming the whole Fediverse. And I started building this thing called AP Events, Activity Pub Events. And the one thing that felt like a real blocker, an insurmountable challenge was…
The fact that your identity within a Mastodon instance or something was pretty fixed, right? You couldn’t really authenticate against it and it wasn’t really meant for a broad ecosystem of connected applications. It was meant for a broad ecosystem of connected instances. And it became difficult to home your data for events outside of your Mastodon instance or whatever. The whole inbox outbox
model is really, ⁓ it’s, I think there’s a lot to it and it has a lot of merit, but it does have some considerable limitations and it, was hung up on it. So when blue sky and that protocol came around, I was pretty intrigued and I thought that the, the, the way to represent these decentralized identifiers, it, it really, it really stuck out. It felt like a good solution to this problem. So yeah, it came out of my frustration with walled gardens and places like Facebook.
events and meet up.
I gave a tech talk at a conference earlier this year where I, I don’t really, it wasn’t really like railing on it per se, but I definitely do name names and call out the fact that like, you know, these companies are looking at people as the product and they make a lot of money on your attention. And that sucks. Communities should be able to outlive the platforms that they, that they use. And with Facebook, if you decide to stop using it, or if your community is not big enough to pay the meetup fees, the annual
fees which are growing year over year, then they end up closing and that sucks. We shouldn’t be limiting people and their ability to make connections because of those factors. So it sort of plays off of the whole credible exit thing. Yeah, came out of frustration. I think that’s the best way to put it. A little while ago I wrote this blog article called Why At Protocol and it sort of expands on this.
So yeah, the past year has been, it’s been a lot of fun. And I’m pretty happy with where smoke signal is going.
Bethany (14:59) Really cool. And was Smoke Signal your first kind of voyage into the at-proto space, the first thing you built on that?
Nick Gerakines (he/him) (15:09) Yep. I was playing around with some code called a white wind, which is like a blogging, like long, long post form content tool. And yeah, it was one of the earlier applications, you know, that people could actually use and do stuff with outside of the core B sky.app, like app view and, and feed viewer. So it’s pretty exciting there.
Bethany (15:32) That’s awesome. Like bleeding edge for sure. What was the learning curve like for getting on learning the app proto ecosystem and especially being one of the first apps on there?
Nick Gerakines (he/him) (15:35) Yeah.
Yeah, the learning curve isn’t too bad. The primitives that make up the protocol ⁓ are all things that a lot of developers are familiar with. DNS, HTTP, JSON, WebSockets. There are a few more advanced concepts and features like content signing and verification, and then of course, OAuth, is ⁓ sort of core of how authentication works within the ecosystem. But…
There are a lot of really good libraries and SDKs that help keep those interactions pretty high level so that people don’t really have to go too far deep.
Bethany (16:17) That’s awesome. And since seeing everything, this ecosystem grow and I’m sure flourish since starting SmokeSignal, beyond social media, application categories are you most excited to see built on this protocol?
Nick Gerakines (he/him) (16:18) Yeah.
So I’m really excited about new forms of social engagement. I think that more and better tooling around groups in communities is where it’s at. Because when you look at some communities, right, there’s this one large community called Black Sky. And what they’re doing is very open but private sort of gated community model where they have a large number of custom feeds, a large number of
Custom tooling around label to help people exclude bad actors and to promote and highlight black voices and different clusters of content in those feeds and communities. I think that’s really exciting. Feeds are really critical to a lot of how I think the atmosphere is going to both operate currently and succeed. Gray’s Social is doing a ton of amazing work making feeds both accessible and
feature rich, so like you can create really fascinating customized feeds for books or for the know the NBA draft and NBA championships they recently did and stuff like that. It’s pretty cool. Yeah, I think it’s also worth pointing out that the developer community has been super open and engaging. I know that there’s…
some views about the types of people and sort of mindsets that are more…
prominent on Blue Sky. And I don’t necessarily think that’s a bad thing. I think that generally speaking, everyone is really welcoming and kind. There’s, you your affordance of engineers of all forms and backgrounds, which does mean that there will always be friction because people have different views and ideas and desires about how to go about things. But what the developers and non-developers coming together and doing is pretty exciting.
So, you know, some of the examples that come to mind are Ryan and his organization that’s bridging the Fediverse and the atmosphere together with cross post viewing is pretty fascinating.
Obviously Rudy and what he’s doing with Black Sky and R Sky is pretty cool. And then of course, Boris and Ted in this like at protocol developer community, they’ve been running conferences and workshops and meetups. And it’s been, it’s been really, really nice to be a part of it.
Erika (18:41) Well, we’re going to dig into another topic that you have been working in and have some expertise in that we are going to pick your brain about, which is OAuth for MCP. So starting out with, know, why is OAuth for MCP a topic that might have its own category? What are some of the considerations
for OAuth and MCP context compared with traditional web applications.
Nick Gerakines (he/him) (19:11) Yeah, so OAuth is a pretty complicated spec. MCP and agentic systems also have their own vast complexity, right? So merging the two together is a really interesting.
It’s a really interesting process and the experience is tricky. So like when you think about what OAuth does, OAuth is a protocol that allows a user to indicate that an application can verify that they are who they are and then take some actions on their behalf, right? Literally the goal is to say that there’s an authorization system like Google, right? For Google flavor to OAuth. And I as a website want to allow you, for example, to come to me where I
direct you to Google, get some proof that you are who you are, that you’ve authenticated, and then with that proof, I can make API calls, review your calendar, display profile information, et cetera. So when you think about what OAuth does at a very high level, it’s really user focused, right? It’s user focused and user action focused. Users have to click things and do stuff.
In the agentic world, the way that you interact with tooling is completely and totally different in every way. Right. When we talk about like LLM and AI browsers and all of these different things that people are doing to like, you know, view and roll through the web and take action. It’s not you doing it. It’s this entirely different thing that doesn’t have the same core user experience components that you’re used to doing all that stuff. So when you add on top of it, the idea that you have this separate
entity that’s not really a website per se, and it’s not the authorization service, but it does need to access protected resources like an MCP backend to provide your calendar functionality or your smoke signal events, right? The idea is that those different interfaces have to, they have to come in alignment. So, OAuth, along with dynamic client registration and key components like
PAR, pushed access requests, then DPOP, which is distributed proof of possession. All of these things allow for clients to assert themselves as the client that they say they are and provide the prompted interface to allow users to get the credentials and the proof that they need to give to those agents to then make those directed calls.
It’s a lot of moving parts and a whole lot of places where something can fail and then you’ve got to bubble up errors, which is also a really tricky spot.
Erika (21:43) Cool, thank you for that overview. What are you thinking the sort of like growth or evolution areas are for MCP authentication as the agent ecosystem matures and other technologies advance in this space?
Nick Gerakines (he/him) (22:01) Yeah.
⁓ I think that there are some really interesting things that need to be sorted out and I’m excited for the amount of energy and attention that they’re getting. Kind of like how, you know, the rapid advancements in solar farms led to enhanced battery, you know, production and discovery. I’m really hoping that AI and LLMs help improve the way that we handle authentication and proofs like this. So like the problems that immediately come to mind when I think of this include, you know,
Do I have to refresh my access token every 30 minutes? What happens if I’m automatically logged out? Do agents get proactive pushes or can they perform or do they have to perform checks or heartbeats to see if credentials are still good and then
When you talk about really enhancing the capabilities of an agent, you’re probably talking more than one set of MCPs for it to interact with, you know, on working with GitHub and Co-Pilot, right? There could be the GitHub MCP that provides repository and some amount of profile or organizational data. You could have an MCP agent that generates commit messages for fun, right? Or another one that is used to generate test data for
or the specific types of data that you’re working with that’s specific to your application, another for infrastructure and staging that of course does not delete your production database. And then, yeah, so it’s a lot of different tools. So does that mean that as a user, I need to go to each and every one of them and authenticate and perform those processes? Can we simplify it with some sort of trusted or credentialed token exchange system? If my attributes are similar
similar enough for me to say, or the types of data that they’re interacting with are similar enough to say there’s one signed token that could be shared or used with different audiences in the issuer audience OAuth attribute system or with similar claims to be able to go, hey, I can read calendars for this user regardless of what system this token is being used on and then have the backend tooling with distributed proof of possession perform some sort of additional
check or token exchange to get that? don’t know. So I hope that those are some of the things that we can sort through because what I absolutely don’t want to do is put in half a dozen MCPs that I’m actively working with throughout the day and then have to re-sign in through everything every 45 minutes to two hours. That would just be a bad user experience.
Erika (24:22) This is more of a user experience and less of like a deep technical perspective, but I think I would really like to have like before an MCP executes a plan, like a verification of that plan. Like, cause I think the other thing that like kind of freaks me out about like MCP servers active on my behalf is like, if I give them access to a bunch of things and maybe one of those has like, you know, some kind of paywall or like
Nick Gerakines (he/him) (24:26) Yeah.
Erika (24:48) some kind of like pay like paid access tier and like oopsie I go over that limit like you know or I think it’s some of the it’s like some of the github
Bethany (24:56) Or a way to drop a database.
Erika (25:00) things that we see where somebody is like creating like 500 repos at once or something. And I’m like, I kind of think that’s a mistake. Like I don’t actually know if they’re intending to do that, but like they might’ve accidentally given a bot, you know, an extra zero or something like that, you know? So like, yeah, that for, for my two sons, I would love to be like, yep, yep, yep. Looks good. Like it’s going to cost me this much if there’s any sort of like pay implications or whatever.
Yeah, kind of similar. Yeah.
Nick Gerakines (he/him) (25:27) Absolutely. I
think there’s also a really interesting sort of separate but related, this is more agent than MCP, but how can…
either with MCP tooling or with agent tooling or some sort of structured process around them. When you have, you know, a fan out of agents performing tasks, right? How can you provide a stream of context? Like what is your inter agent bus per se look like for cached information or referential information or just contextual feedback, right? So if you are building a web app and you have one system working on the react component
it and then one system working on the backend and another spinning up a staging environment or performing some sort of like proactive testing. You know, if you give prompts to two different agents that are working in different languages with different goals, right? Or perhaps even the same goal, but different prompts specific to the model that’s best for it and the immediate objective with that language, you could end up with a backend and a front end that has gone off quite a bit, right? Quite a bit of divergence. But if you had a mechanism
to allow them to share information. So the back end said, hey, I’m starting to look at this data model. And the front end says, good, I see that you’re working with this data model. I’m gonna start crafting the client interactions with it accordingly. I think that would be a really interesting problem to solve. And the way that agents provide both file access and prompt access, I’m sorry, the way that MCPs support file access and prompt access, there could be a solution there that helps.
you
Erika (27:02) Absolutely.
Brittany Ellich (27:02) very cool. ⁓ Yeah, so I’m curious, it sounds like your experience has really been around for a while working in the Web 2.0 space and now in the app proto space. You’ve been working on this sort of like bleeding edge of where technology is going for a long time. So you’ve been doing this for a while. What’s your approach to building and, you know, finding community within those spaces?
Nick Gerakines (he/him) (27:03) Yeah.
You
Yeah, you know, when I was younger, the advice was like, just be yourself. And everyone’s like, no, no one’s going to like that. But that’s really the truth. You just be yourself openly and publicly. And it’s, thank God it’s a big web. There’s a lot of people that are probably like you. And I’d take a certain comfort in knowing that a lot of my problems are not unique and other people have both dealt with them and gotten through them. telling people what I’m working on and being humble or.
trying to come off as humble as best you can in 300 characters or less. Yeah, that has been a big part of it. Openly attending groups and giving people space to talk about what they’re working on and listening has been a big part of it. then, you know, just using feed readers aggressively over 15 years to see what’s going on in Hacker News and other places to, ⁓ you know.
pay attention to discovery. That’s been a big part of it as well.
I also attribute a lot of interesting technical discovery to the art scene. Artists do wild and weird things and you got to pay attention to the weirdos, don’t disrespect, to see what they’re coming up with to, you know, go, hey, what was their inspiration for this non implemented but like interactive system or component? What are they, what’s the vision that they’re trying to represent here? And then to go, what if we, what if we
did this and started working toward it. think that there are, I think there’s a lot of usefulness and diversity of thought and pure creatives or mostly creatives take us there.
Brittany Ellich (28:53) That’s cool. I feel like a lot of the advice that I see online is like, find your niche and just stay there. But there’s just like so many things out there that the average person finds incredibly interesting. finding community in these different pockets is a nice thought.
Nick Gerakines (he/him) (29:06) I
mean, I’ve conflicted opinions about that. think finding your niche is like super important because when you, it takes time and resources, right? Resource and the time being the resource most of the time to get good at something. I don’t necessarily believe in the whole like 5,000 hours or 10,000 hours thing. But.
You know, just like with spring dance, swing dancing in order to get better, you have to do it and you have to be comfortable being bad at it at first, you know, that said diversity of thought makes a huge difference. am a vastly better engineer than I was before. well, a with therapy, but B with functional programming and the two are not related in any way. fact, one has probably led to the other, functional programming, doing a lot in Erlang has
been instrumental because like really getting into the actor model and understanding the Erlang virtual machine and getting into the nitty gritty changed how I thought about procedural and object oriented programming and like really, really big ways. And I don’t do a lot of Erlang nowadays. Like it was just sort of a stint, right? But much like when you’re a swing dancer, the recommendation is you dance with a lot of different people, go to different dance styles, you experience them, and then you use
information to inform what you’re doing in other places, think programming is the same way.
Brittany Ellich (30:21) I love that. What advice would you give to developers who want to get involved with open source or want to start building on some of these emerging technologies like at Proto? Where do they start and how do they get into it?
Nick Gerakines (he/him) (30:33) Yeah, that’s a great question. I’m the type of person that learns by doing. So I think example applications or example projects or the example directories in libraries and toolkits are a great place.
there are a lot of really good data explorers and because really like one of the, one of the characteristics of well-designed applications is a solid domain of data, playing with data models and exploring what is stored and how, and then reading up on the decisions or trying to get the context of, why, why did they store this as an integer for timestamp instead of this other thing? Or why are they indexing things this way in this backend?
or what the hell’s going on with this, if it makes no sense at all. And then getting stumped into asking questions and getting that context, super helpful.
I also think that onboarding people to open source projects through tests are really helpful because if you can spend some time getting someone to understand why it behaves the way that it is, you can get them to think about what they would do different, especially if they’re fresh. So you could start with saying, Hey, this is a low coverage area. Let’s write some tests. I’ll pair with you, you know, this evening with a beer or something. And they go, well, why are we testing it this way? Or even better, like why?
like the tests and the functionality doesn’t seem right. What if we did this other thing instead? That’s a great opener, right? In conversation and in development to reevaluate what you’re doing and see if you can learn from new people. So yeah, be confident and humble, go through example projects, openly ask questions when you don’t know what’s going on. And then of course, don’t be afraid to…
you know, look like an idiot, right? Because you’re not going to be aware of all of the places that documentation exists and other people have thought about stuff so much that it feels like common sense to them, but not new people. you know, be humble and be proactive.
Bethany (32:24) definitely makes sense. I think that’s good advice in open source and in life. ⁓ I also love the idea that either Erlang drove you to therapy or therapy drove you to Erlang. I don’t know which was which, that was my experience using Erlang for Advent of Code for sure.
Nick Gerakines (he/him) (32:30) Yeah.
When I was working at Yahoo, I left Yahoo to go work at EA on some game services that were Erlang based and the going away gift from…
going to Wege for my team was this wonderful mug that says Erlang is my life and then underneath that it says I don’t have a lot going on but thanks y’all.
Bethany (33:02) That’s amazing. that’s great. That’s great. Alrighty. So that was a really fun conversation. I feel like I’ve learned so much in this, what, 40 minutes? I have so many things and so many more questions to look up after this, but we’ve got to go to our fun segment. So…
Nick Gerakines (he/him) (33:02) It was very applicable at the time.
Bethany (33:23) I was surprised when I discovered Nick made a site called whatthecommit.com, like a utility for generating commit messages. And I was like, this is genius. So normally, you write the code and then you write the commit, right?
So I forget, I figured that we would play a game of commit charades and rather than that, we’ll see the commit and then try to imagine what kind of code it goes with. So I’ll start just to give an example, but I, the one that came up was last time I said it works, I was kidding. Try this.
And to me this evokes when your tests pass locally but they’re not passing in CI or there’s something nuanced about CI that keeps breaking and you have to like push and push and push code to like actually fix it. So that’s kind of what that’s evoking to me. So I’m not sure if you all want to generate your own commits or I can generate them and say what you get but.
Erika (34:23) I think I need a new one because the first one that popped up for me is to colon write meaningful commit message.
Nick Gerakines (he/him) (34:29) You
Erika (34:31) Let’s see, the next one I get is, it compiles, ship it.
Nick Gerakines (he/him) (34:31) Perfect. I just pulled,
Erika (34:38) So to me this evokes a typo or a YAML formatting error and you’ve been banging your head against a wall for two hours on why this thing isn’t compiling and none of the error message is helpful and you realize it’s a period or a whitespace character that you didn’t see.
Nick Gerakines (he/him) (34:57) I love the visual here,
right? I love the just sobering acknowledgement of everyone just nodding their heads going, yeah, yeah, we’ve been there. That’s, it’s very revealing. Let’s see, I just got copy and paste to fix previous copy and paste. That is a, no, I can’t read that one.
Erika (35:03) Yeah. ⁓
Nick Gerakines (he/him) (35:14) So the fun thing about this project is it started, I speaking at OSCON like 10 years ago or something like that. And I was, no, no, I got to be 15. It was back when I was working at Blizzard.
Anyway, was a long time ago. And I was making fun of the random commit messages that were in our code base from trying to ship some stuff for Diablo. And ⁓ all of y’all’s names are actually in it. So if you look at the source code for it, it’s just a big dumb Python file. stuff’s there. this is probably, it was a lot of fun to write because there are so many contributions. So for example, this one is a revert, quote, just testing remember to revert,
Bethany (35:44) you
Nick Gerakines (he/him) (35:55) is the oops I accidentally shipped something to prod with debug code in it and we’ve got to get that out as quickly as possible hopefully your deploy process is quick and this is a super appropriate one thank God for copilot which is more recent and also thank God for copilot
Brittany Ellich (36:13) That’s amazing. I got debug line test, which ⁓ it speaks to me because this seems like something that I would do where I would be like committing something to debug it in CI because it’s faster than running it on my local machine. That’s what a lot of my commit messages look like.
Nick Gerakines (he/him) (36:17) you
Yeah,
shout out to all of the print line debuggers out there. I am one of you. We are us.
Bethany (36:38) yes, definitely, All right, well, I guess we will go ahead and wrap up. Thank you so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky and share with your friends. As a reminder, we are still in the early phases of our Looks Good to Me book club.
and there is still plenty of time to get involved. It’s mostly async, so feel free to contribute. Check out the show notes for more info and until next week, goodbye.