Rama 0.3.0-alpha.1 - widening the protocol base
Rama 0.2 was a checkpoint. This first 0.3 alpha is the next step after that checkpoint: make the protocol base wider, without making the framework feel heavier.
The full technical source is the 0.3.0-alpha.1 release discussion. This post is the shorter story of why this release exists.
For a network framework such as Rama, protocol support is not a checklist item. It changes what people can build. A proxy that understands only HTTP has a very different shape from one that can route by peeking at early bytes, speak SOCKS5, handle WebSocket traffic, expose useful traces, and still allow the user to compose the actual business logic themselves.
That is the intent of this alpha.
What changed
The biggest visible addition is WebSocket support through the new rama-ws crate. Rama can now act as a WebSocket client and server, handle HTTP/1.1 and HTTP/2 upgrades, run against Autobahn conformance tests, and expose a rama ws CLI tool with an interactive TUI mode.
SOCKS5 support also landed, including CONNECT, BIND, UDP ASSOCIATE, username/password authentication and socks5h style hostname proxying. This matters because SOCKS is still one of those simple-looking protocols that shows up everywhere once you build real proxy systems.
Observability took a meaningful step as well. This release adds first-class OpenTelemetry support, an OTLP-compatible HTTP client layer, better root span handling, and automatic trace and span IDs in spans. Infrastructure that cannot be observed properly is difficult to trust. Rama should help you see what it is doing.
There is also native Datastar support, with SSE compatibility, examples and tests. TLS and fingerprinting gained support for ALPS, draft GOST cipher suites, PeetPrint fingerprinting and better BoringSSL integration. Protocol peeking was expanded across HAProxy, TLS, HTTP and SOCKS5, making it possible to route traffic before fully committing to one protocol path.
Finally, this release starts rama-unix for Unix Domain Socket support and adds several examples, including a multi-protocol proxy, a WebSocket MITM proxy and peek-based proxy routing.
Why this matters
This release is about making Rama more useful for the messy middle of networking.
Real systems do not always arrive nicely labeled. Sometimes the first bytes decide where traffic should go. Sometimes the same infrastructure needs to serve HTTP, tunnel WebSocket traffic, talk through SOCKS5, export traces and still leave room for company-specific logic.
Rama should make those systems possible without forcing users into one rigid architecture. That is the craft we are aiming for: useful pieces, small enough to understand, composable enough to become something larger.
Looking ahead
This is still an alpha. There will be more breaking changes in the 0.3 cycle, and that is intentional. The point is to release often enough that feedback arrives while the design can still improve.
The foundation is already used in production, but the API is still allowed to mature. If you are building on Rama, now is a good time to test the new protocol pieces and tell us where the shape is awkward.
Community and support
Rama grows through use. Issues, examples, bug reports and partner feedback all make a difference.
You can help by trying the release, opening issues, contributing improvements, or telling us what kind of proxy or client you are building. You can also sponsor the project or contact us at partner@ramaproxy.org for integration help, support contracts or custom feature development.
Thank you for building with Rama.