Unwrapping Moonpig: Architectural Insights into Personalization and Scalability

Whether you need to send greeting cards or flowers, Moonpig makes personalized gifting for any occasion easy. But behind the simplicity of Moonpig’s platform are complex technologies that enable the deep customization that customers love. To talk about the architecture behind Moonpig, Principal Engineer Alexis Lowe sat down with our host David Joy.

Join as we discuss:

• How serverless technologies are helping Moonpig manage costs and handle spikes in usage

• The failover solutions that are implemented to ensure Moonpig can provide an always-on experience even during high-traffic events such as holidays

• How Alexis experiments with new AWS services and why he loves Lambda

David Joy:

What is up everyone? And thanks for tuning in today’s episode of the Big Ideas in App Architecture podcast we speak to Alexis Lowe, who is a principal engineer at Moonpig. Alexis and I talk about Moonpig and how they have built a truly efficient and optimized solution to run their business. We also get into their use of event-driven architecture to scaling the applications for zero downtime across multiple regions. So pump up that volume and get ready for an intriguing conversation with Alexis Lowe.

All right, Alexis, welcome to the Big Ideas in App Architecture podcast. For everyone listening in, Alexis joins us all the way from the UK and Alexis now works at a company called Moonpig, and we’ll get into all of that. But before I butcher the intro, Alexis, why don’t you let people know about what you do a little bit and your role?

Alexis Lowe:

Yeah. So I’ve been an engineer for about three and a half years now, but as a pure engineer. But before that I was in the security world doing everything from cyber-diability engineering for security teams, but also penetration testing and all of that good stuff there.

David Joy:

Very cool. And for people who are not going to see this, I mean of course if you go to the YouTube channel and see the video, you have a really good background right now with a lot of Lego bricks and ship or rocket ship and stuff like that. Are you a collector? What’s the deal with that?

Alexis Lowe:

Yeah. So, massive fan of all things NASA, and when Lego started doing NASA ships and all of that stuff, it was far too easy to buy them. And then I’ve also got a small collection here of old consoles and stuff like that.

David Joy:

Nice. I can see the PS5 actually, the PlayStation, the old one. Yeah. Very cool.

Now you’re a principal engineer, you work at Moonpig, right? First time I heard the name, I was like I got to figure this one out. What does a company do a little bit? Tell us about your role. I know you’re a principal engineer now, you’ve been with the company for three and a half years. But break down what Moonpig is, what you guys do, and tell us a little bit about your role right now.

Alexis Lowe:

So Moonpig is a e-commerce website. We’re very popular in the UK, but we’ve also got stores we’re available in Australia, US, Ireland, and then we’ve got a few other companies with their acquisitions and they’ve become brands that sell the same things as Moonpig does. What Moonpig really is at its heart is just a technology platform that allows to bring customized products to our customers. But we don’t purely focus on the person purchasing, we mostly focus on the person receiving. So it’s all about gifts, cards, flowers, those kinds of things. And we’ve become one of the leading e-commerce platforms for that. So yeah, it’s quite exciting to be in this space.

So I am a principal engineer there. I mostly focus on what we call enablement, which involves our platform teams. It also involves our developer experience for our engineers. So everything from supporting teams to build their new features and deliver quickly to making sure that all the infrastructure is reliable, secure, and available.

David Joy:

From what I understood is it’s like a personalized solution where folks can come choose a card, say it’s Mother’s Day or International Women’s Day, you can put a particular message on it and make it unique and then you guys ship it out or mail it out to the individual and that requires a lot of things to go in. So was this something that before you came to Moonpig, you were aware of the size of domain and things like that?

Alexis Lowe:

So I had heard of Moonpig in the UK, their jingle is actually quite famous. I’m not going to sing it because I do it horribly. But yeah, they’re quite a well-known brand. We were founded by one of the Dragons' Den people. So from that point of view, it’s just very famous. For me, it was the first time moving into e-commerce, so I spent my entire time in banking and for me, e-commerce was already quite new. But finding out this isn’t just a store, which there’s loads of technologies, companies out there that just sell easy store to use and et cetera. This is far beyond that because of that personalized aspect of the card, we’ve got a very complex editor that allow people to write whatever they want, put stickers in places, change the text on the front of the card, which might be a special font. There’s all sorts of things going in there. And then the fact that we can deliver those cards in all sorts of sizes and as a postcard, not a postcard, there’s so much variety from that.

In most recent years we’ve really taken that and started depending to it. So most recently we acquired a company called Buy Gift Red Letter Days, and they specialize in selling experiences. So the idea is that buying, for example, a hotel for two or restaurant experience, and we’ve taken that and made it available in the card. So now you can buy your card and have that voucher inside there. And that was a fairly big technological feat because we integrated directly with their system. So when you do that, you’re creating that object over there because it’s all just printed and data, it all remains just being tech.

David Joy:

I’ve had a little bit of experience working in retail and I used to work at Walmart and I’ve worked at Sam’s Club, which in the US is a retail store like brick and mortar, but they also had a digital experience where you could go Sam’s Club online shop and they would go select stuff up and you have to fill up a card and check out and then put that order through. And then what I realized during that process was you just don’t have to make a website with all the products and catalog and all the options, but you also have to cater to the supply and the demand part of it. And there is a lot that goes behind that I never realized. It’s fascinating from what you were sharing with me just now about how everything works. So I would love to go into that a little bit more and learn.

But before we get into that, tell people a little bit more on what’s the principal engineer, how is that different from a typical engineer? Because I know many people come across and they’re like, well, at the end of the day we are engineers. But how does your role change a little bit in terms of day-to-day function?

Alexis Lowe:

Yeah, so principal engineering, like you say, has got a lot of definitions across the different companies. At Moonpig, it usually is the natural progression from a senior engineer. You would become a principal engineer if you didn’t want to go down the management route. So it’s one of the paths we allow people to remain as an IC.

The biggest thing I think is we focus less on the code we’re delivering or the exact how to solve this problem. Rather we’re looking at the bigger picture. So I spend a lot of time actually in front of designing solutions and coming up with nice architectural diagrams and et cetera, but also working closely with teams and engineering managers, but also the engineers themselves coming up with, okay, what’s the limitations of the system that you have today? How can we make this better and how can we deliver that new feature that might be coming up on the roadmap?

The other thing we’ve done at Moonpig is our principal engineers are responsible for keeping all engineering to our set of, we call them principles, but we make sure that everyone’s following those and adhering to those. So a lot of what I do is actually writing up documentation or RFCs or standard ways of doing things so that we can keep the entire business aligned from an engineering point of view, which is being super useful for a lot of the pieces of work we’ve had. So we’ve had a fairly big migration a while back and that standardization has helped us do that move. There’s that, and then there’s always the occasional moment where it’s like, okay, no one wants to fix this thing and none of the teams have time, but we need someone that knows how to code to go and quickly deliver that piece of work. And so that’s maybe where I get the closest to the keyboard.

David Joy:

Thank you for breaking that down. What motivated a young Alexis Lowe to choose a career in tech then? Obviously you were inspired by the galaxy and space and physics and stuff like that. What made you choose engineering? Tell us a little bit about that.

Alexis Lowe:

Yeah, so I’ve just been fascinated with computers since a really, really young age. I wrote my first program at the age of nine. It was on Visual Basic 6 on my dad’s Compaq. And it was a really silly, I think it was a man that shot at a target. I know I’ve got the code somewhere, but I’ve not been able to rebuild it anymore. How things work was always something that would make me obsess about those things. And computers were one of those things that were really important.

I think the thing that pushed me the most into this is the way I was brought up was my parents didn’t let me have all these consoles you see behind me. I wasn’t allowed to have a gaming console, so the only thing I had was a computer and my dad said, you can play games but you have to figure out how to make it work on a computer. So that always led to me figuring out how to do these things. And the very first games I played were on a Mac… Not a Mac, a laptop that only had DOS. And so I had to learn how to use a prompt to start my games. It was way before when I was nine that I was doing this. So that’s where I learned, these things became natural for me.

David Joy:

I’ve met so many people who started their career in tech because of being gamers. I have a similar story where my family also didn’t give me access to computer until very late. And then I had to convince my dad that I wanted to learn C programming and get myself a PC. And then from there on all I did was actually burn CDs and actually play games. Didn’t learn C there, had to learn somewhere else. But that’s how most of us begin. It’s fascinating how all these things go inside.

I’ve also met a bunch of engineers who they could have chosen a career in physics. I thought that maybe physics was a path for me as well, or learning the solar system and things like that. Very fascinating. Thank you for sharing that.

Now I’ve been trying to do a little bit of research on you and stuff is fairly easy to get on the internet. So tell us a little bit about what is chimbosonic.com all about? Let me give the premise that’s your personal website where you have all your information. What’s chimbosonic? Bring it out for me.

Alexis Lowe:

This is super embarrassing. I was probably 12 or 13 when I came up with that name and it just stuck. It’s just my username. It’s basically the amalgamation of Chimborazo, which is a volcano I visited when I was really young in Ecuador. It just really impressed me, this massive mountain and I loved the name and it just stuck. And sonic because I couldn’t use the word Chimborazo as a username because someone else had used it. And that’s pretty much it. That’s the story behind that. But yeah, it just stuck and I’ve used it on every forum, every social account I’ve ever owned and I just couldn’t get rid of it.

David Joy:

Yeah, it’s a pretty brilliant webpage. I would love people to go and check it out. It’s very well laid out and it’s very unique and it starts with this whole idea that don’t panic and keep reading what’s going on here because it’s code, it’s written in that way. It’s really creative. I loved it.

Alexis Lowe:

Yeah, don’t panic comes from Douglas Adams' Hitchhiker’s Guide to the Galaxy book and the character is actually the emoji on the front of that book. This came along when I got my first tech job in security. There’s a lot of moments where you discover something horrible and it’s like, don’t panic, we can solve this.

David Joy:

And I think in what you said just a few minutes ago, your role at Moonpig is sort of like that as a principal engineer. If somebody can’t do something like hey, give it to Alexis, and we kind of figure that one out, so don’t panic. Very cool.

All right, so let’s jump into a little bit more on some of the things that you guys are working on that you were alluding to earlier. I know you were talking to me previously, you talked about this whole story making Moonpig more to the current architecture and today’s modern paradigms of infrastructure. And about five, six, seven years ago things were a little different, but you have changed it a lot. So tell us a little bit about what that looks like and what your architecture is today.

Alexis Lowe:

So a little bit of history. We were very much a virtual machine house all on-premise and everything was running on Windows with ISS and then .NET framework hosting the website. This predates me so I don’t have a lot of detail about it, but there was a point in time when the company decided to shift to AWS just full on lift and shift into EC2. And once they finished that migration and got the website in a place where they could easily scale it, they then started breaking down everything it did into microservices. But they made a conscious decision that it was going to be serverless first, SaaS and PaaS second, and then that’s it. If you can’t do it one of those ways, you just can’t do it, give up. And it’s worked out really well.

The architecture is mostly, like I said, microservices. We’ve got an event-driven model, so everything talks via events and we accept that trade-off of eventual consistency. Where we can’t accept that trade-off we go for a synchronous call between two services, but it’s very explicit and we can really see that when that happens.

The whole website it’s not really a microfinance, but it’s basically free web apps and then the whole back end is a federated GraphQL, which has been great to be able to build a single back end for not only the website but our two apps. So we’ve got the iOS app and the Android app and the web app and the feature parity is really good.

David Joy:

That’s awesome. Yeah. So I’ll let you comment, but I was just curious, what led you to move to an event-driven architecture? Was it like the business had changed, the expectations in the market had changed from the users? Why was it supposed to become so real-time? Tell me a little bit about that.

Alexis Lowe:

So we went for event-driven because there was one big thing which was we wanted to grow. Growing the teams but also growing the website, the amount of people that were using it was incredibly important, but also growing the amount of features we could build. And so the event-driven architecture has given us a way of separating our domains and keeping them decoupled, which means that we can build a whole brand new feature and we don’t need to involve 20 teams, we only need to involve the one team that owns the domain that is being affected by that feature. Obviously there’s always cross-talk and you have to deal with that, but that’s the business we are in and then that’s just how it works.

The other reason for serverless is for us it’s, like you mentioned before, everything we do is super spiky even throughout a day. So if you look at our graphs the amount of requests spikes around lunchtime because everyone’s got free time and lunchtime to go and buy a card because they remembered whatever they might have forgotten, they do it at lunchtime. And then in the evening it’ll spike again and in the morning there’s a little bit of traffic, but that’s pretty much it. But it’s very much a up and down spike. And with serverless, what that means is we scale immediately with that. And it’s not only scaling up where we can serve the massive amounts of people that try and buy a card on Valentine’s Day or Mother’s Day, but also we literally drop down to zero in the evenings.

And so at night our bill is close to zero, which is something that you can’t achieve with traditional hardware or ECTs unless you’re setting up cron jobs to turn things off and then turn them back on and et cetera, which has got loads of risk around it. From that point of view, that’s been the biggest driver is that cost management at that level is amazing.

David Joy:

I have kind of had the similar experience with working with bunch of other customers as well, where that type of access pattern on their applications leads them to make decisions where they’re like, well, why is our infrastructure just running for no reason and nobody’s using it? And I think what you shared is a recipe for excellent event-driven architecture for those kind of access patterns where the idea is that let the infrastructure come up when you need it to be used and then to go down because it helps you on your [inaudible 00:20:21] site. It gives the users experience suddenly say you have double… Somebody tweeted, hey, I got this card on Moonpig and it’s on Twitter, and everybody flushes in and it can scale according to that. So it’s brilliant that you’ve brought that architecture in that.

So I’m curious, is it like you run it on Lambdas or are you using EKS and running your application?

Alexis Lowe:

It’s all pure Lambda. We very much 100% whatever is the most serverless thing from AWS. So we use DynamoDBs, we use Lambdas. If it doesn’t have a serverless form, we tend to avoid it. So we do have a few containers because there’s loads of products that just have to live long-lived and for there we’ll just use Fargate for example. We try and avoid really about the needing to maintain or manage the scalability of the system. What it means is we can focus more on the actual features we’re developing and delivering.

David Joy:

Right. So let me ask you a question based on that. So when you were building this architecture and personally for you, there are different elements, obviously there’s the infrastructure side of things, there’s database setup, there’s event-driven Kafka, MSK, sort of Lambda. What is your favorite part in this architecture to put your fingers and hands on, keys on what excites you more when you’re trying to program it?

Alexis Lowe:

I think it’s probably the Lambda side of things. Being able to write a little bit of code, hook it up to an SNS queue, SQS queue, or hook it up to an API gateway and immediately get a web server out of it and have it do actions it’s so liberating because you just don’t need to think about, did I deploy this thing properly? It’s just did I push my code? Yes I did. Cool. And it really saves a lot of thinking.

The other thing that’s interesting about it is that it changes a lot of your thinking about when you’re looking at performance, for example, you’ve got performance of how quickly did I respond, how quickly did I do these things? But also that immediately ties into cost. So if you respond, let’s say 20% faster, that actually translates immediately into a 20% saving on your cost of running your infrastructure. And so it’s actually really easy to tell people the value of that kind of refactoring and that kind of work. And from that point of view, that’s really amazing. So that’s probably the part that I always am fascinated every time I’m working on the Moonpig is that any changes we make, if we make something slightly slower, you immediately in the bill, which is you don’t normally get that.

David Joy:

And I think the other fact that you said is because you have this microservice based architecture that maps to how your teams are set up and then you can ship features out independently of dependency and that decoupling really helps. One of the things I had seen was one of our customers that I had worked with previously had a similar situations and one of their team actually put out a feature. And what happened was as soon as they put out that feature, suddenly there was an error or bug in that particular feature that started impacting their transactions and suddenly they started losing some transactions in database. There was immediate panic on what’s going on, but it helped them kind of nail down, okay, hey, which was the features that were recently released and they could go immediately start looking at it as well.

Tell me a little bit about the way your scale is right now in terms of how it needs to be available and what’s the impact for these features and applications to be always on and things like that?

Alexis Lowe:

So the impact of the system coming down is basically immediately loss of revenue, that’s how critical the system is. If people can’t order, we’re not making money. So from that point of view it’s super critical for us to be resilient and the way we achieve that is everything’s deployed three times in separate regions, but the regions are specifically picked for being as close as possible to the customer. So we’ve got customers in Australia, for example, who we’ll deploy in Australia. We’ve got customers in the UK, we’ll deploy to the US one region, for example. All of these regions can act as failovers for the others. So if the Australian regions having a hiccup, we’ll failover to one of the other regions.

The other thing that that’s unlocked is it allows us to do canary deployments. So we know some of our regions have less traffic, so we’ll deploy to those first and test all our changes there first. And then, oh, okay, that didn’t cause an outage or yet the customers reacted it correctly, we’ll push forward. The other thing that is important to note is that we rely heavily on the AWS and their serverless products, which most of them have really high availability numbers and if they go out, the entire planet is off. So there’s a lot of times where you’re like, oh, the websites down and you go and check and it’s like, well, the internet is down.

David Joy:

I mean, the reason I asked that there was a particular reason because this week, I mean I don’t know if you follow this, but LinkedIn was down and then we also Meta was down and basically it was panic across. How I got to know that Facebook was done because my mom, who is basically a Facebook user, I don’t use Facebook anymore, but she still does, she was like, why is my app not working. She was the one who informed me. That was the most fascinating thing in this whole story that I got know about it from users and it was all over the internet. So I mean, in your case, obviously, making sure the application is up, that is directly hitting your revenue as well as the whole experience that you have to drive to your customers, right?

Alexis Lowe:

Yeah. And the separation of everything into microservices and et cetera means that each of those individual components are monitored separately, have their own heart beats. So as soon as any of those systems go down, whatever it might be, we know what it is and we can either isolate it or immediately go and fix it. So our response times to fixing things is pretty fast because of that.

David Joy:

You came from cyber security and security working at Capital One, I believe, right? How was that experience for you? Tell us a little bit about the difference in these two worlds actually.

Alexis Lowe:

In some cases in night and day. Capital One feels like a startup when you look at it, the way you work and et cetera. It’s all very friendly. People treated like a family and et cetera. And the way you work is very much like cutting edge technology all the time. They really spare no expense when it comes to having the best of the best. They also have amazing this idea of building everything. They would rather the engineers are building it rather than have this external reliance on others.

From that point of view, when I was working there we were building a Kafka cluster and it’s not just like you’re building a Kafka cluster, it’s like, oh, we are going to go and commit to upstream Kafka because it doesn’t work for us. And that experience there is very, very different to the way that Moonpig works, which is actually we don’t want to deal with those things. There’s experts out there that are dealing with that. What we want to do is focus on the product we’re selling and focus on the feature. And so it’s a very different way of working, but it also means that for me I’ve been able to focus on far more important problems than figuring out why a open source project might not be functioning in a specific way.

So from that point of view it’s quite different. But also I was in security, so I was doing a completely different role. Security is an interesting industry. There’s so much going on, so much to learn, so many things you’re constantly paying attention to. I had a Twitter feed open on my laptop 24/7 and that was part of the role. If you didn’t have that, you were going to miss out on something that was really important. So from that point of view it was maybe more stressful. I don’t know.

David Joy:

You brought up a really good point about this whole aspect of learning and continuing to grow, and I’m fascinated when I talk to everybody, I mean obviously in security you have to keep up with new features and new things that are happening. That’s the same thing that’s in a way happening with AI right now. With GenAI pretty much every day there’s something new getting dropped or some new capability coming in and then it’s a challenge trying to keep up. I have not never seen that level of pace. But how do you really keep up now with some of the new technologies and things that are growing? Obviously you have your family, you have to continue to work and how does Alexis keep up with, hey, what’s happening? What’s the pulse of the trend right now?

Alexis Lowe:

So I’m a lot on Mastodon, so I follow a lot of big tech gurus on there and a lot of, even not the tech gurus but maintainers of different projects and et cetera. And that’s probably one of the places where I get a lot of information. The other places, I think every morning when I turn on my work laptop, the first thing I do is open up Lobsters and Hacker News and look at what the latest news is and pick whichever technology there sounded interesting and give it a spin.

I’ve got a home lab, so I think anything that hits the front page usually ends up running on my computer. And I give it a try and if I don’t like it, I just turn it off and move on to the next thing. But yeah, that’s usually how I try and keep up to speed with these things, but there’s far too much going on to keep up.

David Joy:

I know. So tell me about this. Is there anything interesting that you kind of observed or tried on your home lab and you were like, that’s a pretty interesting project, I think that’s got some legs in going into the future?

Alexis Lowe:

I live in a world where I only use AWS products at work. We use whatever they have available and that’s it. But one of the things I’ve been really enjoying is building all of these products they have locally on my home lab. So there’s loads of small projects like MinIO that gives you an S3 bucket interface. To me, it’s mind-boggling that I can just spin that up on my machine and have my own micro cloud. So that bringing the cloud back on-prem is an interesting thing that is happening and I’m all for it. I think it’s great.

David Joy:

That’s very cool. I think I haven’t tried it, but I’ve been hearing about this a bit for a long time now, so I’m going to check it out as well.

I was curious at Moonpig, how do you and your team continue to innovate? Is there, you guys run some hackathons within to learn some stuff? How do you continue to grow internally?

Alexis Lowe:

Yeah, so within my teams I run Skillshares, so it might be something I’ve got to share or someone else in the team has to share and the subjects go everything from how to use Git to, I’ve been doing a few Rust programming courses where we’re all learning together how Rust works and et cetera. Really anything goes in that session. We’ve got one of our engineers is really into AI and he would just showed us how to run an LLM locally and none of us had ever done that and that was eye-opening and how easy that’s become. So that kind of stuff helps a lot.

And then Moonpig runs hackathons on a regular basis and that’s org wide. Everyone gets a team and we just bash out things and sometimes there’s some really, really amazing stuff that comes out of that. I’m not sure if I can mention any of them because I think they’re turning into products, but that’s how it works.

David Joy:

You can avoid that, I mean that’s fine. Yeah. I’m inspired by the way you’re using AWS right now. I’m pretty sure you’ve kind of touched most of what’s within AWS for your use cases. I was curious to understand whenever you have to go through a new product that AWS launches or something, how do you go about determining if it makes sense? What’s your process like around that?

Alexis Lowe:

Yeah, so we’ve got a pretty good relationship with them. So they tend to, for us new things and we’ll have a look. The most recent one was this new runtime for JavaScript. So a lot of Moonpig is running on TypeScript. AWS released this runtime called LLRT, and it’s just lightweight, super fast runtime, which cuts down your cold starts and your Lambdas by ridiculous amounts of… I don’t know the exact numbers, but it’s really, really fast. So that was published as a GitHub. We saw it, we went, let’s go and spin this up. And all of our projects are deployed using ISE and they can be deployed to DEV, UAT, PROD and some of these can even be deployed to several dev environments, so you can have several branches deployed at the same time.

If there’s a new technology, like the new runtime so we’re just go, okay, let’s go and try. Let’s try this out on the most core piece of a platform, spin it up, see what happens. In the case of LLRT, it didn’t really work. But yeah, it’s great. With a Rust project, Skillshare I’ve been doing, we rebuilt our main gateway in Rust in I think it was a week of. We call it 10% time. So in our 10% time, me and another engineer just bashed it out, gave it a try, and it was like, yeah, that’s 50% faster. Once we’ve tested it and we spiked that idea, I’m now taking it through the principles and those groups and et cetera to say, Hey, I think we should invest in this and how do we get there?

David Joy:

That’s what a principal engineer does everybody. If you are trying to learn what it is all about through Alexis. Alexis, I know we have to be focused on time as well. So tell me a little bit about what your advice is to engineers who are on a similar path as yours. I mean a bunch of us with similar stories, gamers, AI, and a lot of cool things that are happening. But what’s your advice to engineers who are on this path of learning and growing?

Alexis Lowe:

I think the best thing I’ve been taught is to be curious. I don’t fear learning about the details of the different systems I’m using. So I’m using S3, but it doesn’t mean that I’ve gone and read… I haven’t gone, oh, I’m just going to use S3. I’ve watched and read nearly every single paper available around S3 to understand how it works in the backend because I’m just fascinated with how that works. And it might be any other technology. The minute you are using something, don’t fear going to learn how it actually works.

One of my favorite things is there’s always occasional talks on hidden Git commands and the amount of engineers that go, I wish I knew about that. And it’s like, it’s all there, it’s all in a man page, it’s all available. You are using this tool every day spend the 20 minutes to sit down and learn everything that is capable of doing capable, and you always learn something new and people like that because then they come to you for your expertise, which helps going up that ladder.

David Joy:

Oh, that’s awesome. Spoken like a true engineer who has gone through documentation. That’s one of my own faults too. I sometimes start reading documentation and I’ll have something starts working and then I’m like, I don’t know why it’s working this way. Then I have to go back and read the documentation and understand why it works and understand a little bit more. So it’s been an absolute pleasure having you on the podcast today. Tell me and the people where can they find you? Obviously you have your website, chimbosonic, which I’m going to remember that for a long time. But do you post stuff? Where can people follow you and learn from you?

Alexis Lowe:

Yeah, so my website, there’s all the links to all the different social places. Probably the place where I post the most is at chimbosonic@fosterdon.org on Mastodon. There’s a website called keyoxide.org, and if you search in there for my email address, which is alexis.lowe@chimbosonic.com, you’ll get all of my links there and they’re all verified using a really nifty project that I’m working on with some really smart people.

David Joy:

Very cool. Tell me a little bit about the Key Oxide project because it seems like it’s pretty fascinating.

Alexis Lowe:

So Key Oxide is an implementation of decentralized online identity proofs. So the idea is if I own a social account, I post something on that social account that proves that I am this profile in another place and that profile is cryptographically verifiable and it contains a proof that I’m the person on that social account. And so what that means is it is… Keybase did this, if you’ve ever heard of Keybase. But Key Oxide takes that idea and decentralizes it, so you no longer need to trust Keybase dot… I think it’s .com or .org, I’m not sure.

You no longer need to trust a single entity. Everything is open source, you can just use these things. The underlying technologies are super well known and they’ve been around for decades. It’s all either OpenPGP or we recently introduced a simpler version of the profiles, which we call ASP profiles, and they just use JWTs and normal cryptography. We don’t enroll anything ourselves or anything like that, we’re just using what’s there and I think it’s really smart. Hopefully at some point we’re going to make it easier to share and it’ll just be like, find me @chimbosonic@keyoxide and then you’ll find everywhere I post any social website. Yeah, it’s pretty nifty.

David Joy:

Oh, that’s awesome. What it reminds me of, I know obviously the implementation different, is Linktree, right?

Alexis Lowe:

Yeah. It’s noddy Linktree I like to say.

David Joy:

Yeah, yeah, yeah. No, it’s cool actually. It’s very fascinating. Anyways, I mean, I just wanted to say it’s been such an awesome time talking to you. It’s been a pleasure. Everybody listening in go follow Alexis. He’s a fascinating principal engineer, now working at Moonpig and doing some really interesting things.

Alexis, do you have any final thoughts for everybody around anything that you feel like they should go and do in tech right now?

Alexis Lowe:

I think the most important thing to do in tech right now is interoperable runtimes. I really think the next big thing is going to be Wasm amazing that people can just build whatever language they want, create a binary blob that anything can understand and run for you. I think that’s the future.

David Joy:

Nice. Yeah, I mean that’s awesome. I mean, I’m going to check it out myself and I’m pretty sure you’re going to talk more about it. So if you’re interested in this follow Alexis. Again, it’s been a pleasure, Alexis. Hope you had a great time. Thank you so much for coming [inaudible 00:41:53].

Alexis Lowe:

Yeah, cheers. Thank you very much for having me.