Infrarust V2 wouldn't exist in its current form without the open source projects listed here. Some of them I studied for weeks. Some I cloned locally and went through them at 2am trying to understand a design decision. All of them taught me something.
This is my way of saying thanks.
The projects that defined how a Minecraft proxy should work

The single biggest influence on Infrarust's plugin architecture. The ResultedEvent pattern, EventBus with priorities, the separation between api/ and proxy internals. I borrowed all of it. It also shaped how I think about a proxy's relationship with the Minecraft protocol.

Proved that a proxy can hold players in virtual worlds for authentication, queuing, or anti-bot checks. The key lesson was actually what not to do, building virtual worlds as a plugin that hacks into proxy internals is fragile. In V2, the Limbo is a first-class concept.

A Rust limbo server covering 1.7.2 through 1.21.1 with only 44 packets across 49+ protocol versions. The biggest help was understanding the join and registry sequence from 1.20.2 onward. The config phase is poorly documented and version-sensitive.

Showed how to structure a Minecraft project in Rust. The crate layering, protocol organization by connection state, chunk encoding. The build.rs approach of generating Rust code from JSON assets was the answer to my registry data problem.

The best packet serialization design in the Rust MC space. Encode/Decode traits writing to impl Write, the Bounded<T, MAX> type to cap allocations on decode. I wrote my own protocol crate, but the trait design came straight from here.
Where the proxy pipeline design came from

Cloudflare's proxy framework gave me the connection lifecycle model. The ProxyHttp trait with ~32 optional callback methods maps almost perfectly onto a Minecraft proxy's flow. Also confirmed the workspace structure. If Cloudflare runs 20 crates at scale, my 8-crate split is fine.

The Service trait is the foundation of Infrarust's middleware pipeline. A Layer wrapping a Service into another Service gave composable, testable middleware for the connection handshake phase. The split between tower-service and tower mirrors infrarust-api vs infrarust-core.

The proxy framework closest to the use case. Built on Tower's Service/Layer pattern but operates at the TCP level. Seeing the Tower model work for raw TCP connections confirmed the pipeline design was the right call.
Where the plugin API ideas came from

Bevy's Plugin trait, build(&self, app: &mut App), is the most ergonomic plugin registration pattern I found in Rust. One required method, sensible defaults, chainable builder. Infrarust's plugin trait follows the same idea.

Proved that WASM plugins work for network proxies in production. The VM-per-plugin model, shared VM option, documented trade-offs between isolation and performance. Helped me design the PluginLoader and future WASM implementation.
Every one of these solved a problem I didn't need to solve anymore
tokioAsync runtime
fastnbtNBT serialization for Minecraft registry data
libdeflaterBuffer-based compression/decompression
flate2Streaming compression fallback
zlib-rsPure Rust zlib implementation
papayaConcurrent HashMap for the player registry
arc-swapLock-free config hot-reload
mimallocAllocator on musl builds
Without these, there's no protocol implementation
Every project here gave something away for free so that others could build with it. Infrarust is one of those others.
Thank's for everything,