From Frontend to Low-Level Networking: My Journey Contributing to Open Source

Life, Family, and Open Source

It’s been a while since my last post. As always, life happens—and in the best way possible, as our family recently grew with the arrival of our second child! With a new baby, the dynamic shifts again. While family is always my number one priority, this change pushed me to improve how I organize my work and learning. I’ve had to become more efficient in time management to ensure I keep growing as a developer without sacrificing precious time with them.

Despite the adjustments, I kept my promise to myself to start contributing to open source this year. I’ve now contributed to several projects, ranging from tools I use daily to personal learning experiments. The most notable contribution was to Rama.

Coming from a background of more than 8 years as a Frontend developer, I recently started expanding into Backend development. Rama was the perfect challenge for this transition; it forced me to dive deep into the 'low-level stuff' and gave me a solid understanding of some of the networking knowledge.

Implementing a Stunnel-like Feature

One of my main contributions was implementing a stunnel-like feature directly into the Rama CLI. For those unfamiliar, Stunnel is (as the name implies) a secure tunnel. It’s essentially a way to turn any insecure protocol into a secure one by wrapping it in a protective tunnel.

To implement this in Rama, I needed to build two distinct components that work in tandem:

1. The Exit Node: Acts as the server side of the tunnel. It listens for encrypted traffic, decrypts it, and forwards the data to your actual destination (like a web server or echo server).

2. The Entry Node: Acts as the client side. It listens for local plain-text traffic, encrypts it, and forwards it to the Exit Node

How It Works in Practice

One of the coolest things about Rama is that it comes with a built-in "Echo Server" and client request capabilities which made testing this feature incredibly self-contained. I didn't need to spin up separate python local server or use other tools like netcat for testing, I could do it all within the Rama ecosystem.

Here is the workflow I designed to test the tunnel:

Step 1: The Destination (Echo Server)

First, I need a target service. Rama has a built-in echo server command that listens for traffic and simply repeats what it receives. I start this on port 8080. (The below command will spin up the echo server on port 8080 default btw)

bash
rama serve echo

Step 2: The Exit Node (TLS Termination)

Now, we start the "Exit" proxy. This node acts as the secure gatekeeper. It listens for TLS (encrypted) connections on port 8002. When it receives data, it decrypts it and forwards the plain text to our echo server at :8080.

bash
rama serve stunnel exit \
    --bind 127.0.0.1:8002 \
    --forward 127.0.0.1:8080 \
    --cert server-cert.pem \
    --key server-key.pem

Step 3: The Entry Node (TLS Initiation)

Next, we start the "Entry" proxy on port 8003. This is where the magic happens for the client. It listens for normal, plain-text traffic. When a client connects, the entry node initiates a TLS handshake, encrypts the traffic using the CA certificate, and tunnels it securely to the Exit node.

bash
rama serve stunnel entry \
    --bind 127.0.0.1:8003 \
    --connect 127.0.0.1:8002 \
    --cacert cacert.pem

Step 4: Verification

Finally, using Rama's built-in client, I hit the entry point. The request travels through the encrypted tunnel (hence stunnel), reaches the echo server, and the response travels all the way back. (The below command will send a client request to port 8003)

bash
rama :8003

Note for Testing

You can skip the manual certificate setup if you just want to try this out quickly. If you omit the certificate arguments and instead pass --insecure to the entry node (replacing --cacert), Rama will use its built-in auto-generated self-signed certificates.

Warning: This method is for local testing only—never use it in production.

Fun fact: When I first started this, I had this whole flow completely backwards in my head. Because I always spun up the Server first (to get the ports ready), I kept visualizing the flow from Right-to-Left (Server → Client). Important reminder that learning the fundamental is first before coding.

Under the Hood: Architecture & Rust

One of the reasons I was able to implement this feature smoothly was Rama’s architectural philosophy: "Services all the way down."

Rama is built on a modular design where almost everything is a service. This means you can compose complex behaviors by stacking simple layers on top of each other. You can read more about this design in the Rama Book.

For my implementation, I didn't have to write a monolithic script that mixes encryption logic with socket handling. Instead, I assembled three distinct building blocks.

Think of it like packing a box for shipping:

1. The Item (TCP): This is the raw object I want to move (the connection).

2. The Bubble Wrap (TLS): I wrap the item in a protective layer so it doesn't get damaged or spied on.

3. The Shipping Label (Forwarder): Finally, I slap a label on the outside that tells the system where to send it.

Here is the snippet for entry node:

rust
let tcp_service = Forwarder::new(connect_authority).with_connector(
  TlsConnectorLayer::secure()
    .with_connector_data(tls_connector_data)
    .into_layer(TcpConnector::new()),
  );

tcp_listener.serve_graceful(guard, tcp_service).await;

In the code, I’m just wrapping the layers: Label( Wrap( Item ) ). It turns a complex networking task into a simple packing list. Rama made all these simple to implement.

The Challenge: Bridging the Gap Between Code and Concepts

While the implementation was written in Rust—a language I’ve been enjoying and learning for about a year—the real challenge wasn't the syntax. I’m comfortable picking up new languages and navigating codebases, especially with the help of modern AI tools like Claude Code.

The hard part was the domain knowledge. Since I am still in the early stages of my backend and low-level networking journey, the concepts felt steep. but that was exactly the point. I wasn't just there to ship code; I was there to learn the concepts in depth.

At one point, the maintainer even reminded me to just 'have fun with it.' And he was right—why not? Despite the complexity, it was genuinely fun to learn while building something cool.

To build a secure tunnel, you can't just "import TLS." You have to understand how trust is established. I found myself hitting pause on the coding to deep-dive into:

• The Chain of Trust: Understanding why a self-signed certificate works differently than one signed by a Root CA.

• System Trust Stores: Learning how operating systems store trusted root certificates and how to tell my program to look at a specific file (my cacert.pem) instead of the default system store.

• The Handshake: Visualizing what actually happens on the wire when stunnel entry talks to stunnel exit.

The Power of Mentorship

Finally, I want to emphasize that this contribution wasn't a solo journey. I want to give a huge shoutout to Glen DC, the creator of Rama.

The code review process was one of the highlights of this experience. It wasn't just about spotting syntax errors; it was true mentorship. Glen took the time to review my implementation in depth, offering feedback that helped me refine not just the feature, but my approach to Rust programming in general. Having a maintainer who is willing to guide contributors makes all the difference in open source.

Wrapping Up

If you are on the fence about contributing to open source—especially if you are juggling a busy life or a growing family like I am—I highly encourage you to go for it. It’s not just about the commits on your GitHub profile; it’s about the fundamental knowledge you gain and the connections you build.

If you are interested in Rust, proxies, or networking, definitely check out Rama. It’s a powerful tool, and a great place to learn.