DEV Community: Tabrez Ahmed

Publishing My First Rust npm Package (@seucra/matrix-sdk-bridge)

Tabrez Ahmed — Fri, 14 Aug 2026 14:20:36 +0000

Introduction

Publishing a package to npm is a common milestone for JavaScript developers. However, publishing an npm package written in Rust and compiled to WebAssembly introduces a completely different set of tooling, cross-compilation target considerations, and TypeScript definition generation.

Recently, I published @seucra/matrix-sdk-bridge—the extracted WebAssembly wrapper around matrix-sdk used by Vigilant.

This post documents the exact workflow, build scripts, pitfalls, and lessons learned during the publishing process.

Tooling Stack

To build and package Rust code for WebAssembly, I used:

wasm-pack: The official CLI tool for building and packaging Rust-generated WebAssembly for npm.
wasm-bindgen: The core library facilitating high-level interactions between Rust and JavaScript.
TypeScript: Auto-generated .d.ts definition files ensuring strong typing for JS consumers.

┌──────────────┐     wasm-pack build     ┌────────────────────────┐
│  Rust Source │ ───────────────────────►│  WebAssembly Binary    │
│  (src/lib.rs)│   --target web          │  (.wasm + .js + .d.ts) │
└──────────────┘                         └───────────┬────────────┘
                                                     │
                                                     │ npm publish
                                                     ▼
                                         ┌────────────────────────┐
                                         │ npm Registry Package   │
                                         │ @seucra/matrix-sdk-b.. │
                                         └────────────────────────┘

Step-by-Step Publishing Workflow

1. Configuring `Cargo.toml`

The Rust crate must be configured as a dynamic system library (cdylib):

[package]
name = "matrix-sdk-bridge"
version = "0.1.0"
edition = "2021"

[lib]
crate-type = ["cdylib", "rlib"]

[dependencies]
wasm-bindgen = "0.2"
wasm-bindgen-futures = "0.4"
matrix-sdk = { version = "0.7", default-features = false, features = ["e2e-encryption"] }
serde = { version = "1.0", features = ["derive"] }
serde-wasm-bindgen = "0.6"

2. Building for Web Targets

Building the compiled WASM artifacts for browser environments:

wasm-pack build --target web --scope seucra

This generates a pkg/ folder containing:

matrix_sdk_bridge_bg.wasm: The compiled WebAssembly bytecode.
matrix_sdk_bridge.js: The JS glue code initializing and exposing WASM functions.
matrix_sdk_bridge.d.ts: TypeScript typings for all #[wasm_bindgen] functions.
package.json: Configured package manifest under scope @seucra.

3. Publishing to npm

After logging in with npm login, publishing the scoped package:

cd pkg
npm publish --access public

Lessons & Gotchas

Target Selection (--target web vs --target bundler): --target web generates ES module outputs using native fetch() to load .wasm files. This avoids complex Webpack/Vite loader configurations for consumers.
TypeScript Generation is Automatic: wasm-bindgen automatically generates TypeScript .d.ts files for annotated Rust structs and functions. Ensuring Rust doc comments are clean means your published npm package gets instant IntelliSense documentation!
Automate Builds with Scripts: Always script your build and test flow to prevent publishing stale WASM binaries.

Conclusion

Publishing @seucra/matrix-sdk-bridge was a major milestone in my Rust learning journey. It proved that Rust and WebAssembly can bridge the gap between low-level systems programming and modern browser applications seamlessly.

Extracting Matrix SDK into a Rust WASM Library

Tabrez Ahmed — Fri, 14 Aug 2026 14:19:55 +0000

The Monolith Problem in Early Prototypes

When building an ambitious application, it is tempting to put all code into a single repository. In early iterations of Vigilant, the Rust Matrix SDK integration was tightly coupled with application-specific state handlers and UI glue code.

As the project grew, this coupling created several friction points:

Testing the Matrix SDK integration independently from application UI state was difficult.
Changes to the frontend interface required touching deep backend Matrix sync loops.
Reusing the Matrix integration in another web client or tool was impossible without copy-pasting code.

I realized that Matrix client integration is fundamentally an independent concern. That realization led to extracting the Rust integration code into a standalone, reusable library: matrix-sdk-bridge.

Why WebAssembly for Matrix Client Logic?

The Matrix client ecosystem has robust native implementations, with matrix-sdk in Rust being one of the most active and feature-complete SDKs available.

By compiling Rust to WebAssembly target wasm32-unknown-unknown via wasm-bindgen, we get several advantages:

Memory Safety & Correctness: Rust's type system ensures data race safety, strict lifetime checks, and zero-cost abstractions inside the browser environment.
Upstream Alignment: We leverage official, audited Matrix Rust SDK crates directly rather than reimplementing protocol handling in JavaScript.
Clean Architectural Boundary: WebAssembly exposes a clear ABI (Application Binary Interface). JavaScript handles UI rendering while WebAssembly handles protocol state, cryptographic sessions, and timeline synchronization.

Designing the WASM Bridge Interface

Bridging Rust async types (Future, Stream, tokio/wasm-bindgen-futures) to JavaScript promises requires careful API design.

Here is a simplified architectural view of how data flows across the WASM boundary:

┌───────────────────────────────────────┐
│     JavaScript Application / UI       │
└───────────────────┬───────────────────┘
                    │  call async WASM methods (e.g. client.login())
                    ▼
┌───────────────────────────────────────┐
│     wasm-bindgen Export Layer         │
│  - JsValue serialization              │
│  - Future -> Promise conversion       │
└───────────────────┬───────────────────┘
                    │  Rust async calls
                    ▼
┌───────────────────────────────────────┐
│       matrix-sdk (Rust Crates)        │
│  - Room handling                      │
│  - Sync loops                         │
│  - Session state                      │
└───────────────────────────────────────┘

Key Design Principles:

Hide Upstream Complexity: Upstream matrix-sdk exposes dozens of types (Client, Room, Timeline, SyncResponse). The bridge packages these into high-level, serializable JS structures.
Explicit Event Passing: Matrix live sync updates are passed across the WASM boundary using JS callbacks or event dispatchers.
Graceful Error Handling: Rust Result<T, E> types are converted to structured JavaScript errors rather than panicking inside the WebAssembly module.

Lessons Learned

Decoupling Accelerates Iteration: Once matrix-sdk-bridge was extracted, developing the frontend became significantly cleaner. The frontend team can mock or consume WASM methods without needing to touch Rust code.
WASM Memory Management Matters: Passing large byte arrays or string structures continuously across the JS/WASM boundary can introduce garbage collection overhead. Using lightweight JSON or typed array structures minimizes serialization overhead.
Treat Internal Tooling as Open Source: Even if a library starts as part of an internal project, structuring it like an open-source package forces cleaner abstractions, better documentation, and higher code quality.

In the next post, I will share the process of packaging this Rust WebAssembly bridge and publishing it to npm as @seucra/matrix-sdk-bridge.

Building Vigilant — Cycle 1 Complete

Tabrez Ahmed — Fri, 07 Aug 2026 15:09:06 +0000

Reflections on finishing Cycle 1 of Vigilant's backend, adopting Matrix Synapse, and choosing architectural focus over protocol reinvention.
_

Introduction

Building a modern secure communication application is one of the most effective ways to understand backend systems. However, it is also a project where it is easy to get lost in the wrong problem.

When I first conceived CipherLink—the project that eventually evolved into Vigilant—my goal was simple: write a complete messaging application from scratch, including the protocol, authentication, server storage, and encryption.

It did not take long to realize that building a custom protocol from scratch is a massive undertaking. Designing key management, device synchronization, offline message delivery, and federation requires years of protocol engineering and security auditing. Attempting to build all of that alone meant spending 90% of my time reinventing established cryptography and messaging infrastructure, leaving almost no time for application architecture, backend robustness, or client integration.

Near the end of B.Tech Semester 4, I made a major architectural pivot: adopt the open Matrix protocol, build on top of Matrix Synapse, and implement the application logic in Rust compiled to WebAssembly.

With Cycle 1 of Vigilant’s backend now complete, this post reflects on what was accomplished, why this architecture was chosen, and what I learned along the way.

What is Vigilant?

Vigilant is a secure communication platform built on top of the Matrix ecosystem.

Rather than treating Matrix as just a third-party API, Vigilant uses a self-hosted Matrix stack (Synapse, PostgreSQL, MinIO, Nginx) as its underlying persistence and synchronization engine, while relying on a custom Rust backend and WebAssembly bridge for client state, authentication, room management, and timeline handling.

┌────────────────────────────────────────────────────────┐
│                   Vigilant Frontend                    │
└───────────────────────────┬────────────────────────────┘
                            │ (TypeScript / JS)
                            ▼
┌────────────────────────────────────────────────────────┐
│            @seucra/matrix-sdk-bridge (WASM)            │
└───────────────────────────┬────────────────────────────┘
                            │ (Rust matrix-sdk)
                            ▼
┌────────────────────────────────────────────────────────┐
│                 Matrix Synapse Engine                  │
│       ┌──────────────┐          ┌──────────────┐       │
│       │  PostgreSQL  │          │    MinIO     │       │
│       └──────────────┘          └──────────────┘       │
└────────────────────────────────────────────────────────┘

Cycle 1 Accomplishments

During Cycle 1, the primary objective was establishing a rock-solid backend foundation that could reliably interact with Matrix Synapse.

Key backend milestones completed in Cycle 1:

Authentication & Session Persistence: Implementing login, registration, homeserver discovery, and secure token storage across page reloads.
Room Management & Discovery: Joining public rooms, creating direct message channels, and mapping Matrix room states to application views.
Timeline Loading & Message History: Fetching room timelines, listening to live sync events, and handling message pagination tokens.
WASM Bridge Extraction: Separating the Rust integration logic into a standalone library published as @seucra/matrix-sdk-bridge on npm.

Key Lessons & Architectural Trade-offs

1. Build on Proven Standards

Choosing Matrix over a custom protocol was the single best decision in this project. It shifted my effort from reinventing the wheel to learning how real distributed communication engines work. Matrix Synapse handles event graph ordering, federation, and persistence, allowing me to focus on Rust async state management and client integration.

2. Rust for Client Integration

Writing the core logic in Rust using matrix-sdk provided strong memory safety guarantees and compile-time correctness. Upstream Matrix SDK updates can be integrated directly, and compiling to WebAssembly (wasm32-unknown-unknown) ensures high performance in the browser.

3. Read Upstream Source Code

Documentation for emerging SDKs is often sparse. I frequently had to dive directly into the Rust matrix-sdk source code to understand event handlers, sync loops, and sliding sync behaviors. Reading primary source code is a muscle every backend engineer must develop.

What’s Next for Cycle 2

Now that Cycle 1 backend milestones are solid, the focus shifts toward:

Refining frontend integration with my project collaborator.
Hardening timeline pagination and offline event caching.
Expanding documentation and integration tests for @seucra/matrix-sdk-bridge.

Building Vigilant has proven that engineering depth comes from understanding system boundaries, making deliberate trade-offs, and shipping defensible work.

Concurrency in Python: Solving the Dining Philosophers Problem

Tabrez Ahmed — Sun, 19 Apr 2026 17:26:11 +0000

If you are writing multithreaded applications, you are going to run into deadlocks. There’s no avoiding it. To understand how to fix them, you need to understand the Dining Philosophers problem.

Five philosophers sit at a round table. There are five forks. To eat, a philosopher needs the fork on their left and the fork on their right. If everyone grabs their left fork at the exact same time, they all wait forever for the right fork. Deadlock.

In this series, my team and I will break down how we built a visual simulator for this problem in Python. For part one, we are looking at the core mechanics and Dijkstra’s Resource Hierarchy solution.
The Setup

We want raw execution without third-party bloat, so we rely entirely on Python's standard threading library. Each philosopher is a daemon thread, and each fork is a threading.Lock.
Python

import threading

NUM_PHILOSOPHERS = 5
forks = [threading.Lock() for _ in range(NUM_PHILOSOPHERS)]

If we just wrote forks[left].acquire() followed by forks[right].acquire(), the script would eventually freeze.
The Solution: Resource Hierarchy

To break the circular wait, we assign a hierarchy to the resources (forks). Instead of "grab left, then right," the rule becomes "grab the lower-numbered fork first, then the higher-numbered one."

Here is how that logic looks in our simulation loop:
Python

def _cycle_resource_hierarchy(self, idx: int):
    # Determine fork indices
    left  = (idx - 1) % NUM_PHILOSOPHERS
    right = idx

    # Establish hierarchy
    lo, hi = min(left, right), max(left, right)

    # Acquire in strict order
    self.forks[lo].acquire()
    self.forks[hi].acquire()

    # CRITICAL SECTION: Eating
    time.sleep(random.uniform(0.4, 1.5))

    # Release locks
    self.forks[hi].release()
    self.forks[lo].release()

Because the last philosopher (index 4) sits next to the first fork (index 0), they will try to grab fork 0 first, while philosopher 0 is also trying to grab fork 0 first. The cycle is broken. Someone gets blocked, allowing someone else to eat.

My First Week Learning Offensive Security (Before Hitting the Paywall)

Tabrez Ahmed — Sun, 05 Apr 2026 12:06:17 +0000

I started learning red team fundamentals on TryHackMe. Here's what I learned before running into premium content limitations.

Day 1: Red Team Basics

What offensive security actually means
Learned about dirb tool for directory brute-forcing
[Explain what dirb does and why it's useful]

Day 2: Blue Team Perspective

Defense in depth concept
SOC analyst role
What SIEM tools do

Day 3: Research Skills

How to find CVEs and exploits
Tools: Shodan, Censys, VirusTotal
GitHub for exploit code

Day 4: Linux Fundamentals

Commands I learned: ls, cd, cat, grep
Operators: &&, >, |

The Paywall Problem

TryHackMe's free tier is limited. Switching to OverTheWire (completely free) to continue learning.

Next Week

Starting OverTheWire Bandit challenges. Goal: Complete levels 0-10.

DEV Community: Tabrez Ahmed

Publishing My First Rust npm Package (@seucra/matrix-sdk-bridge)

Introduction

Tooling Stack

Step-by-Step Publishing Workflow

1. Configuring Cargo.toml

2. Building for Web Targets

3. Publishing to npm

Lessons & Gotchas

Conclusion

Extracting Matrix SDK into a Rust WASM Library

The Monolith Problem in Early Prototypes

Why WebAssembly for Matrix Client Logic?

Designing the WASM Bridge Interface

Key Design Principles:

Lessons Learned

Building Vigilant — Cycle 1 Complete

Introduction

What is Vigilant?

Cycle 1 Accomplishments

Key Lessons & Architectural Trade-offs

1. Build on Proven Standards

2. Rust for Client Integration

3. Read Upstream Source Code

What’s Next for Cycle 2

Links :

Concurrency in Python: Solving the Dining Philosophers Problem

My First Week Learning Offensive Security (Before Hitting the Paywall)

Day 1: Red Team Basics

Day 2: Blue Team Perspective

Day 3: Research Skills

Day 4: Linux Fundamentals

The Paywall Problem

Next Week

1. Configuring `Cargo.toml`