うなすけとあれこれ

Translated by AI (and reviewed by me) from handwritten Japanese text. (日本語が後に続きます)

I spoke at 北陸Ruby会議02

Following up on September (?), I was given another opportunity to speak about QUIC in November. Thank you very much.

北陸Ruby会議02で基調講演をさせていただきました | うなすけとあれこれ

Here, I will provide more detailed descriptions of the QUIC-related progress from my presentation.

I’ve switched this blog to be served by my own QUIC implementation

Originally, after various iterations, this blog was operated as a static website where HTML generated by Middleman was placed on S3 and served via CloudFront. While it remains a static website powered by Middleman, I have replaced the delivery mechanism from CloudFront+S3 to my own implementation of the QUIC protocol.

I implemented two components: raiha, which also implements the QUIC protocol layer in Ruby, and the quic gem (described later), which is a binding for ngtcp2. I have both running on the same server and use pf to randomly route packets, ensuring that a response is returned from one of the implementations.

As I mentioned with pf, this is running on OpenBSD. There are two reasons for this. First, it is to verify whether it works in an environment with a cryptographic backend other than OpenSSL. Second, at RubyKaigi a few years ago, jeremyevans recommended OpenBSD to me, and I’ve always felt a sense of guilt for never having given it a try.

Just as osyoyu, who creates a profiler, implemented his own blog with Rails as a testing ground for that profiler, I felt the need to create a place where I could verify that my own implementation is working correctly, which is why I’m doing this.

Railsでブログ自作（2024） - osyoyu.com/blog

How is it? Seeing this instead of the website you expected? If so, it means HTTP/3 is working thanks to my implementation.

dohyo: The Authoritative DNS Server for blog.unasuke.com

In previous monthly reports, I mentioned that I’ve deployed a custom-implemented full-service resolver at home and am using it as a testbed for DoT and DoQ. While I will continue to operate it, a situation where I’m the only one inconvenienced when it goes down lacks a sense of urgency; moreover, it isn’t particularly well-suited for verifying DoQ. While I’ve been able to verify DoT by incorporating it into my systemd-resolved configuration, for DoQ, there are no clients to send requests to, even if the full-service resolver is listening.

To address this, I have implemented and deployed a new authoritative server called dohyo for blog.unasuke.com.

https://github.com/unasuke/dohyo

Claude suggested the name because names starting with “Do”—such as DoH and DoQ—are similar in meaning to a sumo ring (dohyo) when incorporating the meaning of “Zone.” If this authoritative server goes down, this blog will become inaccessible, which adds a sense of urgency. Incidentally, I am using socketry/protocol-quic for the QUIC layer implementation of dohyo. The reason it is not my own implementation is that my own implementation is tested by the web server for this blog itself; thus, I want to verify that protocol-quic—the other QUIC implementation that (for some reason) has commit access—is working correctly.

While this serves as a practical verification of DoQ, the reality is that even if this authoritative server were listening for requests via DoQ or DoT, widely adopted full-service resolvers would rarely send queries using DoQ, DoT, or DoH. However, an initiative called ADoX is currently underway, and the proportion of name resolution traffic that is encrypted will likely gradually increase.

ADoX Status and Deployment :: dnsprivacy.org

Of course, I also want to set up my own home full-resolver to support ADoX, so that when I access my own blog, the name resolution queries are sent and received in an encrypted state.

By the way, 「基礎と実践が1冊で学べる！ DNSマスターブック」 was very helpful for gaining knowledge about DNS. Reading this book helped me understand that operating my own authoritative DNS server (and doing so via a new implementation!) would actually be reckless, but well… yes.

Acknowledgments

Thank you to everyone who attended Kaigi on Rails 2026. Thanks to the speakers, those who submitted proposals, the sponsoring companies, and all the participants, Kaigi on Rails 2026 was successfully completed.

Below is a brief retrospective.

Kaigi apps

This year, we made significant updates to the conference-app and also modified the signage-app to better align with our specifications. Additionally, we implemented Kamal’s deployment for the conference-app and cfp-app. We benefited greatly from AI-powered coding assistance in these projects. I feel that the improved capabilities of AI have helped alleviate some of the workload involved in conference management.

Next year

I’ll do my best.

Translated by AI (and reviewed by me) from handwritten Japanese text. (日本語が後に続きます)

RubyKaigi 2026 follow up and Fastly Tech Meetup vol.1

I gave talks at two events in September:

At both events, the people I met there greatly influenced my progress this month. Thank you all very much. Perhaps I should make a habit of regularly stepping outside my home.

quic-ruby (quic gem)

https://github.com/unasuke/quic-ruby

At the follow-up event, I was encouraged by someone saying, “Since you’ve secured a good namespace, you should…”, which motivated me to finally address the untouched diffs in my repository. The diff in question was related to distributing the gem as a fat package by adopting LibreSSL as the encryption layer, as ngtcp2 had listed it as “experimental” in their README.

Later, during a conversation with kazuho at the Fastly event, he suggested using h2o/picotls. At that time, one unclear point was whether picotls would function properly when running on systems with LibreSSL instead of OpenSSL (specifically, whether the OpenSSL APIs picotls uses were available in LibreSSL). However, subsequent testing with MCP app revealed that this approach might actually work, so I decided to proceed with this direction. In other words, instead of distributing as a fat gem containing both ngtcp2 and LibreSSL, I modified the distribution method to download and install ngtcp2 and picotls at runtime, utilizing the C APIs of either OpenSSL or LibreSSL depending on the execution environment.

https://github.com/unasuke/quic-ruby/releases/tag/v0.0.2

Raiha

This is a Pure Ruby implementation. As previously noted in an issue reported by thekuwayama regarding TLS layer implementation, there were some inefficient aspects in the initial design. While I could use AI to drive the development process and successfully discuss the QUIC protocol, I realized that continuing implementation while carrying over these inefficiencies would be overly challenging, so I decided to thoroughly redesign the architecture.

My Personal MPC: mcp-coderunner-app

Throughout the extensive design iterations, there were numerous instances where I needed to write code to validate whether the design was reasonable or to determine which approach would perform better in benchmarks. While I could technically use Claude Code on my local machine, when I wanted to do this even on my smartphone while on the go, the terminal interface becomes significantly limited in screen size, making operations noticeably sluggish. Therefore, I developed a Rails application that communicates with MCP. The screenshot at the beginning shows the management interface for this application.

https://github.com/unasuke/mcp-coderunner-app

This is a MCP server that allows you to execute arbitrary Dockerfiles and scripts on your home machine via MCP and return the results. While lightweight scripts can be executed directly on Claude.ai, scenarios like wanting to test different language versions, testing in environments with specific libraries, or verifying that external library builds succeed would naturally benefit from offloading these tasks to more powerful resources. Thus, I created this application that combines a lightweight management interface with local docker run workers. Although it’s publicly released as OSS, it’s strictly for my personal use. Having the code publicly available means I get free CI services and easier deployment…

I’ll be off in October.

Everyone, please come to Kaigi on Rails 2026.

Translated by AI (and reviewed by me) from handwritten Japanese text. (日本語が後に続きます)

July and August Achievements

I skipped the monthly report for July because I was completely occupied with tasks like reviewing proposals for Kaigi on Rails 2026, working on Ferryman, and the preparatory work surrounding Kaigi on Rails that led to its creation.

As for what I’ve been working on, I’m continuing to implement a DNS full-service resolver. For name resolution within my home network (using the Tailscale network), it’s already at a stable, usable level with occasional name resolution failures that I’m addressing one by one through development (handled by Claude Code).

In addition to this, I’ve added DoH implementation alongside DoT to enable operation of our own TLS implementation. The screenshot above shows the results of a DoH query.

It’s been quite some time now since I’ve done any work on QUIC at all.

RubyKaigi 2026 follow up event

https://rhc.connpass.com/event/392503/

While I didn’t talk at RubyKaigi 2026, I’ll be speaking about 2026’s achievements at the follow-up event. This will essentially serve as a summary of this monthly report. As of when I’m writing this blog post, there are still some available spots for in-person attendees, so anyone interested in learning about the progress made by people since RubyKaigi 2026 is welcome to attend.

Translated by AI (and reviewed by me) from handwritten Japanese text. (日本語が後に続きます)

June’s progress

While I hinted at working on QUIC implementation in our monthly report last month, I haven’t actually made any progress on QUIC implementation this month. However, this was intentional - I’ve been working on something else instead.

There are three QUIC implementations that particularly interest me: Raiha, my own Pure Ruby implementation; ruby-quic, a binding for ngtcp2; and Samuel’s implementations of protocol-quic and protocol-http3. I’ve been considering how best to test these implementations - how they actually function, what API interfaces they provide, and how they perform over extended periods of operation. The perfect test environment turned out to be a DNS full-service resolver. By supporting both DoQ and DoH3, it could serve as comprehensive testing ground for both QUIC and HTTP/3.

https://github.com/unasuke/carbuncle

Since I know absolutely nothing about DNS resolver, I’ve been accepting Claude Code’s generated code without thoroughly reviewing it and proceeding with development. I started having Claude Code work on this mid-last month, and it’s currently running on a Raspberry Pi at home, functioning perfectly for my daily personal name resolution needs and serving as my home’s DNS full-service resolver. The screenshot at the beginning shows the results of enabling telemetry output. Currently, DoQ support isn’t implemented yet¹, and I’m focusing on developing the basic resolver functionality. While I’ve made the code publicly available, I don’t intend to promote widespread adoption at this time.

Translated by AI (and reviewed by me) from handwritten Japanese text. (日本語が後に続きます)

May’s progress

As mentioned in the April monthly report, I’ve been developing with significant AI assistance. While I didn’t push any changes in April, I recently committed my local modifications.

Although I haven’t completed full interop testing with quic-interop-runner, I have passed interop tests with both quic-go and quiche, reaching a stage where QUIC and HTTP/3 communication is now possible. I’ve also prepared sample scripts under /examples. We can already establish connections with several known HTTP/3 endpoints, including cloudflare-quic.com. I need to set aside dedicated time to thoroughly review the entire codebase at some point. Now, regarding the Pure Ruby QUIC implementation discussed above - in practical use cases, no one would deliberately choose to use a potentially slower implementation when there are established, proven solutions available. Both in terms of interoperability and security, relying on such established implementations is superior.

With this in mind, I’ve also created a binding implementation for ngtcp2 and been advancing the development process (with AI assistance). Since I was able to acquire the exact namespace I wanted¹, I feel a significant responsibility to build on this foundation. I’ll continue enhancing the implementation’s quality to serve as a viable option for those looking to perform QUIC communication in Ruby.

• https://github.com/unasuke/quic-ruby
• https://rubygems.org/gems/quic

This initiative began when I received encouragement from kazuho at RubyKaigi 2026 (or at least that’s how I interpreted it?).

protocol-quic, yet another QUIC implementation for Ruby

By the way, Mr. Samuel Williams as known as ioquatix is also working on making QUIC and HTTP/3 available from Ruby. He focuses on enriching the asynchronous I/O ecosystem and has released several projects under https://github.com/socketry, including falcon and protocol-http2.

Inside these repositories, you’ll find https://github.com/socketry/protocol-quic, a gem that uses ngtcp2 as its backend also. After encountering build issues in my environment during RubyKaigi 2026’s post-event gathering at SmartHR, I consulted with them about these problems, and through various circumstances, I was added to the Maintainers Team for the Socketry organization.

Just a few days later, https://github.com/socketry/protocol-http3—which uses nghttp3 as its backend—was also released. Around this time, I collaborated with them at a coffee shop just before RubyKaigi 2026’s post-event gathering at Pixiv, and we successfully incorporated some patches into the project.

Neat, it works. pic.twitter.com/gdY9eoAIGh

— Samuel Williams (@ioquatix) May 25, 2026

I was able to discuss various things with Samuel regarding future Socketry-related projects, so I’ll be actively working on them to the best of my ability.