DEV Community: Ali Raza

I built a file transfer tool that can’t spy on you even if it wanted to

Ali Raza — Thu, 26 Mar 2026 10:50:55 +0000

I got tired of explaining privacy policies to people.

Every time I needed to send a file to someone, I had to pick a service and implicitly trust it. Trust that it wasn’t reading my files. Trust that it wasn’t training a model on my documents. Trust that when it said “we don’t look at your stuff” it actually meant it.

I couldn’t verify any of that. Neither could you.
So I built phntm.sh. And I want to be honest about what it is, what it isn’t, and where it’s still rough.

The core idea

Zero-knowledge means the server genuinely cannot read your files. Not “won’t.” Cannot.

Here’s how it works. When you drop a file into phntm, your browser generates a 256-bit AES key. The file gets encrypted client-side with AES-256-GCM before a single byte leaves your machine. Only the ciphertext goes to the server. The decryption key gets embedded in the URL fragment, the part after the #.

Here’s the important bit. Browsers never include the fragment in HTTP requests. It’s in the spec. RFC 3986. When you share a phntm link, the recipient’s browser downloads the ciphertext and decrypts it locally using the key from the fragment. My server never sees the key. Ever.

I store noise. Without the key, the ciphertext is mathematically useless.

Why open source

Because “trust us” is not an architecture.

I open-sourced both the web app and the CLI so you can verify the claims yourself. Don’t take my word for it. Read the crypto layer. Check that the key never gets sent anywhere. That’s the only honest thing to do when you’re making security claims.

The rough edges, and I mean it

I’m being honest here because this is build in public, not a product launch.

The encryption buffers the whole file in memory. For large files that’s a problem. I know. It’s on the list.

The CLI flag parsing is basic. I rolled it myself instead of using a library, which was a good learning exercise but means it’s not as robust as it should be.

I had Vercel Analytics on the page. A commenter flagged it and they were right to. The RFC holds. browsers don't send fragments in HTTP requests. But Vercel Analytics reads location.href client-side, which includes the hash, and POSTs it to their endpoint. That's a problem when the hash is your decryption key.

Fixed with a beforeSend hook that strips the fragment before the event fires. Lesson learned: audit every third party script when you're making security claims, including the ones you added without thinking.

What it’s good for right now

Sending a file to someone who doesn’t have any tools installed. They get a link, they click it, it decrypts in their browser, it downloads. No account. No app. No signup.

The file self-destructs when the timer expires. Nothing to breach after that.

What I learned building this

I built the CLI in Go as my first real Go project. Not a tutorial project. Something I’d actually use.

The thing that made Go’s I/O model click for me was wrapping io.Reader to build a progress bar. The HTTP client does io.Copy and the bar updates itself as bytes flow through. Small thing but it changed how I think about composability.

The whole CLI is stdlib-only. No external deps. That was a deliberate choice and also a good constraint for learning.

Where it lives
https://phntm.sh
https://github.com/aliirz/phntm.sh
https://github.com/aliirz/phntm-cli

Feedback welcome. Especially on the crypto layer.

The Weekend Warrior Epidemic

Ali Raza — Wed, 23 Oct 2024 15:02:01 +0000

The weekend warrior – a mythical creature feared by startups everywhere. You know them: the founders who insist on releasing software updates, shipping new features, or pushing out big announcements on a Saturday afternoon.

It may seem like a harmless habit to some, but trust me, it's a recipe for disaster. I don't think you should release it on a weekend. Here is why:

The Anatomy of a Weekend Release

So, what makes a weekend release? Is it:

Releasing new features or software updates?
Announcing big news or partnerships?
Shipping out a critical patch to fix a major bug?
Something else entirely?

Whatever it is, it's usually happening on a Saturday afternoon – when everyone's supposed to be relaxing and having fun (not you, the founder).

The Risks of Weekend Releases

Founders who release on weekends are often sacrificing precious time with their loved ones for the sake of work. Burnout is real, people! Don't make your team suffer for your ambition.
With reduced testing windows, bugs and issues can slip through the cracks, leaving a bad taste in customers' mouths.
Who wants to test out new features on a Saturday? Nobody! Make sure your users are comfortable and supported before launching something new.
Weekend releases bring increased support requests from frustrated users. You didn't think you'd be getting 200 emails at 3 a.m., did you?
When the founder is always "on," it can create an unhealthy work-life balance for your team members. They'll start to feel like they're working overtime without a break.

The Consequences of Weekend Warrior Syndrome

Delayed releases: Don't push out if something's not ready. It's better to be late than to risk hurting your users.
Lost momentum: Regular weekend releases can create an expectation that you're always "on" and available. This can make it difficult to plan for future milestones or take breaks when needed.

Breaking the Weekend Warrior Cycle

So, how do you break free from this toxic cycle? Here are a few tips:

Communicate with your team: Let them know what's coming up and when.
Schedule release windows: Plan ahead and choose the best days for everyone (not just weekends).
Test early and often: Reduce the likelihood of releasing bugs or issues by testing throughout the week.
Take breaks and prioritize self-care: Remember, you're human too! Take time to relax and recharge.

Conclusion

While the urge to release can sometimes be overwhelming, remember that your team's well-being is as important as your company's success. Don't let the weekend warrior epidemic sabotage your startup – take control of your schedule and prioritize what matters most: your users and your team.

So, plan a Sunday Funday (minus the coding). Your company – and your sanity – will thank you.

Up and running with TimescaleDB

Ali Raza — Tue, 07 Apr 2020 19:28:43 +0000

I've been getting into time-series databases over the past few months. I got into playing with TimescaleDB and was super impressed with its capabilities. One of the important things to understand is that TimescaleDB is just Postgres at its core which means technically TimescaleDB is an extension. Following is my usual MO to quickly run an instance of TimescaleDB.

Getting a docker container up:

docker run -d --name timescaledb -p 5434:5434 -e POSTGRES_PASSWORD=password timescale/timescaledb:latest-pg11

Connecting to said docker container:

docker exec -it timescaledb psql -U postgres

Creating your database:

CREATE database tstutorial;

Connecting to your new database:

\c tstutorial

Adding the TimescaleDB extension:

CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;

That's it! Now you have a dockerized TimescaleDB instance up and running.