wasp/web/blog/2024-10-24-pilcrow-os-maintainers-interview.md
2024-10-24 18:33:59 +02:00

9.3 KiB
Raw Permalink Blame History

title authors image tags
The Faces Behind Open Source Projects: Pilcrow, author of Lucia Auth 🔒
milica
/img/os-interviews/pilcrow_banner.png
webdev
auth
os-maintainers

import Link from '@docusaurus/Link'; import useBaseUrl from '@docusaurus/useBaseUrl';

import InBlogCta from './components/InBlogCta'; import WaspIntro from './_wasp-intro.md'; import ImgWithCaption from './components/ImgWithCaption'

We're back with our series of posts in which we interview open-source maintainers and showcase their amazing projects they keep pushing. This week we've talked with Pilcrow, an inspiring young dev from Japan, famous for his auth library Lucia and love for auth and security.

Lucia is one of the open-source tools that we use under-the-hood at Wasp. It grew to 9.5K stars on GitHub since October 2023. Although Lucia itself will be deprecated as a library in 2025 and converted into a learning resource, Pilcrow is also working on other projects related to auth, such as Copenhagen and Oslo. You can learn more about his work and projects on his blog.

We hope this interview inspires you to contribute to the open-source community yourself. Let's dive in!

  • Could you tell us a little about yourself and how you got into coding? What led you to focus on authentication and tooling for developers?

Im Pilcrow. Im a university student in Japan working on various open source projects around auth and security. I started programming like 4 years ago so I'm still new to the field. I love designing APIs a lot and that's probably the biggest reason I enjoy working on libraries.

  • Lucia brought you recognition within the dev community. What inspired you to create it, and how did you decide to dedicate so much time and effort to it?

I was asked to build several websites for school events and the part I struggled with the most was auth. Half of it was my inexperience, but I also found third-party offerings like Firebase to be unintuitive. Most of their features and APIs at the time were aimed at SPAs as well and didn't work well with server-rendered applications. The open source offerings weren't great either. To this day, I still don't really know how to actually use NextAuth (now Auth.js) or Passport.js.

Over summer break, I decided to build a more leaner NextAuth for SvelteKit so I could use it for my projects. It was my first open source library but it got some attention in the Svelte community. I made it framework agnostic a little while later and it grew naturally.

Working on it got me hooked on library development, and I found designing APIs and even documenting them to be very enjoyable.

:::tip[Would you star us on GitHub?] If you'd like to keep reading more about other open-source maintainers and help Wasp grow, could you please star us on GitHub as a sign of your support? 🙏 :::

  • Managing an open-source project like Lucia must come with challenges. What were some unexpected hurdles, and how did you handle them?

I honestly don't find anything about maintaining open-source projects specifically to be challenging. It just requires a lot of your time with answering questions on Discord and writing documentation. I've definitely changed my approach to library development from when I started though. I now put most of my effort into designing APIs and writing documentation over adding new features.

giphy applause

  • You're also working on The Copenhagen Book, which focuses on authentication guidelines. Why is authentication such a key area of interest for you?

I find figuring why something is and isn't vulnerable a fun mystery to solve. I also love that there are so many rabbit holes you can find yourself in. You're searching about some protocol one moment and the next you're reading a 50-page RFC on some obscure encoding format. It's a field that pushes you to learn more.

(As a bonus, I don't have to deal with CSS).

  • Oslo provides auth-related utilities. Could you walk us through its main features and the problem space it addresses?

Oslo is a collection of packages for various auth and cryptographic operations. Base64, WebAuthn, SHA-256, ECDSA, TOTP/HOTP, ASN.1, etc. It doesn't rely on third-party dependencies or runtime-specific APIs, so it's super lean and runs everywhere. The APIs are relatively low-level compared to similar libraries as well. It requires some knowledge on the underlying standards, but you don't need to learn any library-specific concepts, which is a very big win in my book.

Also, it's a very simple feature but just having some kind of documentation is a big plus.

  • How do you balance your time across multiple open-source projects while ensuring each gets the attention it deserves?

I wish I had a better system, but I just work on whatever I feel like. Im not very good at multi-tasking and prefer focusing on one thing at a time. I don't get a lot of bug reports anyway so it works for me.

  • How do you keep up with evolving security standards across projects, and what advice would you give to teams building their own auth solutions from scratch?

To be honest, I don't think web application security evolves that fast. At least compared to the JavaScript ecosystem (but I guess nothing does). It's rare for a cryptographic algorithm to break overnight and the threat model and basic recommendation is still the same from 10 years ago. A lot of vulnerabilities are still broken access controls and insufficient input sanitation.

But just a lot of reading. Understand the framework and protocols you're dealing with. RFCs and documentations already cover a lot of possible pitfalls. I guess this applies to those who are planning to delegate auth to a third party as well, at least to some extent.

  • Open-source maintainers often struggle with burnout. How do you stay motivated, and what keeps you coming back to these projects?

Maintaining various projects definitely helps with avoiding burnout. My projects arent that big in scale and actual bug reports are rare, so I dont worry about switching my focus to a different project or taking a break for a week or two.

I also see open source as just a hobby. I'll still try to address bugs quickly, but I don't rush myself to add new features.

relax gif

  • When collaborating on open-source, how do you manage community contributions and keep other developers involved in a meaningful way?

I don't think my projects are particularly good examples of open source collaborations. I usually ask people to open GitHub issues for new features and I'm not really open to pull requests except for bug and typo fixes. I like to take my time experimenting with various API designs and I personally find it easier if I do the initial design phase by myself. There's also a certain flavor of code I like and I really want to keep my code "beautiful" (yes, I know it sounds dumb).

To be honest, I don't like pull requests in general since I feel like I wasted the contributor's time if I reject it, even if the code is objectively awful.

I'm well aware that this closed approach doesn't work in bigger projects, but working on open source is ultimately just a hobby, so I think I should be able to have some fun with it.

Most of the community aspect comes from Discord, and I really appreciate people who are active daily and answer questions there. Honestly, it's probably some of the most valuable contributions I receive.

  • What would you do differently in the development and management of your projects, knowing what you know now about open-source and developer tools?

Defining the scope and goals of a project early on. I dont blame myself for not thinking much ahead when starting Lucia since it was literally my first open source library, but it wouldve made development on subsequent major releases much easier. Theres only so many features you can add to a project before the code becomes a mess. You cant appease everyone, so pick a lane and be the best for that purpose.

I also think that libraries that are flexible in how and where they can be used, instead of flexible in their behavior, are more predictable and easier to work with. Clearly defining the line between library and user responsibility is going to make it much more enjoyable to use.

  • What is your favorite type of ramen?

Probably tonkotsu, specifically from Kyushu (the third-largest island of Japan's four main islands). The broth is based on pork bones, which gives it a creamy and rich texture, and the noodle has a bite to it (like al dente pasta).

Tonkatsu ramen

Hope you enjoyed this interview. If you have any suggestions about whom to interview next, join us on Discord and let us know!