DEV Community: Msr Abubakr

Building a package manager that does not depend on npm or pip

Msr Abubakr — Tue, 03 Nov 2026 07:53:47 +0000

Every new language eventually needs a package manager. Ours is no different - but we made one unusual choice: total independence from npm, pip, crates.io and friends.

It is called MsrfPM, and it ships packages for our programming language across backend, frontend, OS, robotics and IoT targets.

Why not just use npm?

Our language compiles to web (WASM), native executables (ELF64/PE32+) and embedded boards. A JavaScript-based registry cannot express "this package has a native ARM build and a WASM build and a checksum per target". We needed:

Per-target metadata - one package, many compiled artifacts
SHA-256 integrity on every artifact - verified at install time, not just download time
Zero runtime dependencies - MsrfPM itself is a standalone binary; no Node, no Python required to bootstrap your toolchain

How publishing works

Build your package (the compiler emits per-target artifacts)
msrfpm publish - hashes every artifact, uploads, updates the registry index
Consumers run msrfpm install <pkg> - integrity is verified before anything touches disk

The honest trade-off

Independence means starting an ecosystem from zero. npm has 2 million packages; we have a handful. The bet: for edge and IoT targets where npm cannot follow, a registry that speaks per-target artifacts natively is worth more than a million JavaScript packages.

Part of a free single-sign-on developer platform - registry and tools live at https://msrfteam.com/msrfpm

If you have built registry infrastructure before - what would you do differently? We are one year in and still learning in public.

Why we built our own email service instead of renting one (and what we learned about SMTP reputation)

Msr Abubakr — Tue, 03 Nov 2026 07:47:06 +0000

Every developer project eventually hits the same wall: transactional email. Password resets, verification codes, notifications. And every provider wants: a business entity, a verified domain, and credit card details - none of which a small international team has on day one.\n\nSo our platform (a single-account identity ecosystem) ships with its own email service, MMail: every account gets a permanent @msrfteam.com mailbox tied to their identity across all our tools.\n\n## The architecture problem nobody warns you about\n\nSending email is easy. Delivering email is the hard part:\n\n- Host egress is blocked everywhere - most cloud platforms silently block port 25/587 to prevent spam abuse\n- Reputation is per-IP and per-domain - one spammy burst from a datacenter IP and you are on blocklists for months\n- DMARC/SPF/DKIM - misconfigure any of the three and Gmail silently quarantines you\n\nOur solution: app servers never talk to the internet directly. Everything routes through one relay with locked-down DNS records (SPF, DKIM, DMARC aligned), and per-sender quotas so one bad actor cannot burn the domain reputation for everyone.\n\n## What MMail gives users\n\n- A permanent mailbox that works across the whole platform (one identity, one inbox)\n- AI-assisted features on top of the inbox\n- Verification and password-reset flows that just work inside the ecosystem\n\nIt is live at https://mail.msrfteam.com - part of a free single-sign-on identity (one account unlocks all our developer services).\n\nWould we recommend every startup build their own email? No. If you have two weeks and a registered business - use a provider. But if you are building an identity platform, email is part of the identity, and owning the pipeline teaches you things no provider ever will.\n\nQuestions about the SMTP architecture? Happy to go deeper in the comments.

One OpenAI-compatible key for 100+ AI models - how and why we built Mervex

Msr Abubakr — Tue, 03 Nov 2026 07:46:56 +0000

We are a tiny bootstrapped team (zero funding, working from home). We kept paying for - and juggling - separate AI API keys for every model we needed: one for Llama, one for Qwen, one for embeddings. So we built our own gateway: Mervex.\n\n## What it does\n\n- One OpenAI-compatible key -> 100+ models (Gemma, Llama, Qwen, GLM, Kimi, DeepSeek and more)\n- Drop-in for your tools: Open WebUI, LibreChat, Chatbox, Cursor - you literally change the base URL and swap the key\n- Auto-Decision API - a weird little extra we love: millisecond probabilistic decisions (yes/no, option picking, scoring, even image checks) with 10k free lifetime calls\n- Live public monitoring per model - success rate, latency, 14-day history. If a source dies, requests fail over automatically\n\n## Free tier (no credit card)\n\n- 100 requests daily\n- Bonuses: connect Discord / Google / GitHub for extra daily quota\n- One-time +400 welcome bonus\n\n## Why build this instead of using a big provider?\n\nHonest answer: learning + independence. Big gateways are great until a model disappears, pricing changes overnight, or your region gets restricted. A gateway YOU control can fail over between sources and keep serving. We wrote about that philosophy more on our blog.\n\n## Links\n\n- Site: https://mervex.cc.cd\n- Docs (Postman): https://documenter.getpostman.com/view/59154340/2sBYHUSzJ2\n- OpenAPI: https://api.mervex.cc.cd/api/openapi.json\n- GitHub: https://github.com/Msrfteam/Mervex\n\nIf you try it - roast it. What model should we add next? What did we get wrong?

Verifying Humans by Replaying Their Input: a Different Take on CAPTCHA

Msr Abubakr — Tue, 03 Nov 2026 07:39:35 +0000

How we built a bot-protection system that doesn't check what you clicked — it checks how you moved.

Every CAPTCHA you've ever solved had the same weakness: the answer is static. Pick the traffic lights. Type the distorted word. Click every image containing a bus. Whatever the answer is, a script (and lately, a cheap vision model) can compute it too.

We're a small bootstrapped team, and when our own forms got hammered by bots we decided to build protection the way we wished it existed. This post is a technical breakdown of the approach we landed on: server-side trajectory replay.

The core idea

The challenge is not a fixed asset — it's generated:

The server creates a random seed for each challenge
The client deterministically builds the layout from that seed (same RNG, same layout, every time)
You solve it — dragging a disc through a maze, tapping a bouncing ball, straightening a tilted photo
Your input events (timestamps + coordinates) are sent back
The server re-simulates your exact path through the same layout and verifies the solve

The answer is not "which squares contain a bus". The answer is how you moved: your timing, your speed curve, your micro-corrections. That can't be pre-computed, because the layout didn't exist until the server generated it, and the trajectory is measured against physical plausibility.

What we check on replay

Teleport detection — a human finger can't jump 200px in one 40ms frame. |Δx| > k·Δt + c → rejected
Speed caps — per-step velocity above a generous human ceiling → rejected
Scripted cadence — screen-acting AI agents move the pointer in metronomic, perfectly-timed steps. Humans produce irregular intervals (OS scheduling + muscle jitter). We flag near-perfectly regular input sequences
Per-challenge replay — puzzle solves, rotation angles, final positions — all recomputed server-side from the same seed

What we deliberately DON'T check

We keep the checks one-directional — flag perfection, pass imperfection:

Shaky hands? Trackpad? Tremors? Your input has high variance — the opposite of scripted. It passes
Short traces and slow movements are fail-open. We'd rather let a borderline human through than block one
No behavioral tracking across sites, no advertising profiles, no personal data

Why this matters now

Two things changed in the last year:

1. Vision models got free. A local multimodal model solves image puzzles at zero marginal cost. Any challenge with a fixed, publicly-visible answer format will fall.

2. Computer-use agents arrived. GPT-class models now take screenshots and act — moving the mouse, clicking buttons, filling forms, exactly like a person. The old defenses don't even see them as bots.

The only durable lever left is cost per solve. Puzzles cost a bot nothing. Motion-physical verification costs real engineering: an agent must generate trajectories that pass teleport, speed, and cadence analysis while also solving the challenge correctly. That raises the price of abuse from ~free to real money — which is the only currency spammers understand.

The honest open problems

Accessibility: any motion-based check risks flagging motor-impaired users. Our checks are deliberately one-directional (flag perfection, pass imperfection), and sites can serve proof-of-work to everyone, escalating to interactive only for suspicious traffic — but a proper accessibility fallback (audio / alternative challenge) is still on our drawing board
The arms race is real: an agent that adds realistic jitter to its movements is coming. Every signal we add, someone will model it. We think replay verification raises the bar further than puzzles did, but we're not claiming immunity
Friction: interactive challenges take 3–5 seconds. That's fine for signup and password reset, too much for search bars — which is why risk-based selection (one-click for trusted IPs, interactive for suspicious ones) matters more than any single challenge type

Try it

All 35 challenges run live in the browser, no signup: msrfteam.com/captcha

Every card on that page plays a real challenge preview, and every solve is verified the way this post describes.

We're a tiny team (zero funding, working from home) building an ecosystem of developer tools — a captcha platform, a package manager, an AI gateway. If you've built or evaluated bot protection, we'd genuinely love to compare notes: what signals would you add to replay verification?