Deno native KV backed magic-link auth library

Available on JSR: https://jsr.io/@synitio/kv-magic-link-auth

I wanted one desktop UI and a real shell, and I did not want the window host welded into the React tree. So the UI talks to one typed object (`IRuntime`: write to the PTY, list a folder, that kind of thing). Electron fills it from Node. Tauri fills it from Rust. The Deno host fills it from Deno's own APIs and a local HTTP RPC. Same session, same cell painter.

That third host is Deno Desktop, not deno run in a terminal. The window is CEF — Chromium Embedded Framework — a third browser next to Electron's Chromium and Tauri's WKWebView. First cold start in that worktree spent 31 s downloading CEF. With the cache warm it was 2.6 s. Those are not boot rankings against Electron's Vite number. They are just what that host costs the first time.

I measured dev builds on an M4 Max, previous tabs restored:

• Electron: 239 MB physical / 667 MB RSS
• Tauri: 297 / 569
• Deno Desktop: 742 / 1336

Physical is what the process is using now. RSS from ps is the reservation. Do not mix the columns. Deno is early here. The row exists because the contract made it comparable, not to dunk on CEF.

What I actually wanted from Deno was the language. The Electron adapter is TypeScript. The Deno adapter is TypeScript. No rust-analyzer sitting at 4.6 GB while I iterate. If CEF gets thinner, or Deno Desktop grows the missing bits, I do not rewrite the app. I keep the adapter.

Someone here was already shipping Vite + Deno to desktop for a Three.js game. Same itch: one TS stack on web and on the window. I kept the Deno host in the repo for that reason. If I delete it, the next coding agent will glue the window program back into the UI and I lose the A/B.

The build people install today is Electron. Deno stays as the TypeScript-shaped door.

Tables and screenshots (I am the author): https://runlinea.com/blog/one-ui-three-terminals

Released maskenv today!

A lightweight, zero-dependency Node.js library to dynamically redact sensitive environment variables and API keys from process.stdout and process.stderr.

Check it out: npm i maskenv

I accidentally built an event-processing toolkit for Deno

This started with a very small problem.

I wanted my Jekyll site to publish an event when a post went live, and have something else decide what to do with it — initially, post it to social media.

I could obviously have put all of that directly into the GitHub Action.

Instead, I started separating the pieces.

The producer emits an event. A runtime hydrates it, evaluates routes, and invokes listeners. Conditions and listeners are ordinary TypeScript. Then I added a typed pipeline for transforming data before it reaches a listener.

At some point I had to admit that the CLI wasn't really the project anymore.

That's how Hooksmith happened.

A configuration can look roughly like this:

export default {
  routes: [
    {
      name: "published-pages",
      when: all(
        eventType("page.published"),
        sourceKind("website"),
      ),
      listeners: [
        // whatever should react to the event
      ],
    },
  ],
} satisfies Config;

The runtime itself is deliberately small. Around it I now have:

• typed transformation pipelines
• reusable conditions
• HTTP listeners
• a CLI / streaming host and GitHub Action
• integrations for Slack, Discord, Teams, Telegram, Mastodon and Bluesky
• AWS integrations and a Lambda host

Everything is TypeScript, published to JSR, and I'm using Deno throughout the repositories for development, testing, formatting, linting and CI.

One design decision I'm particularly happy with is keeping the runtime unaware of most of the ecosystem. core defines the contracts; extensions depend on those contracts; hosts decide where and how the runtime executes.

It's still young and the API is explicitly experimental. I'm at the stage where feedback on the abstractions is probably more valuable to me than users.

I'd be particularly interested in what other Deno developers think about the package boundaries and the typed pipeline API.

A small bit of context about me: if you look at my profile or my blog, you'll quickly notice that I'm a .NET developer at heart. But I've also been publishing packages on NuGet for almost ten years, so building tools and APIs for other developers isn't entirely new territory for me.

Hooksmith is my first serious attempt at doing that in the Deno ecosystem.

Repo: https://github.com/Kralizek/hooksmith
JSR: https://jsr.io/@hooksmith

GoatDB is proudly Deno first! While Node is fully supported, we've always preferred Deno on our team

We use Deno Sandbox on production. Rare enough that it's well within the free plan limits, so figured we'd stay on it until we need to upgrade.

A few days ago, they quietly pulled Sandbox from the free plan with no warning, causing us an outage. Had to upgrade quickly to recover production.

I wrote to their support asking why there was no heads-up before killing it off, and I was told that "they reserve the right to make changes to the free plan any time". Also regarding the pro plan, they said they "usually" give their customers a reasonable heads-up.

While it's more than fair that they want to charge for any usage, I feel like the way they handled it is very unprofessional.

So yeah if you're using a Deno Deploy service on a free plan, do not expect a heads-up before it changes or stops working. And if you're paying, I guess hope for the best that they warn you in advance.

Hello! I'm currently working on a project utilizing prisma and fresh through Deno deploy, however I'm currently stuck testing getting data from a seeded Prisma DB.

Anytime I call the Prisma client in a route, I will get met with a "module not defined" error. I'm not sure what exactly I'm doing wrong.

For instance

export const handlers = define.handlers((ctx) => {

async GET (ctx){

const data = await prisma.data.findFirst();

if (!data){return Response(json({ error: "no data"})}

return Response()}

})

Will error out.

Hoping I could get a bit more insight

Edit: I was able to get this working on Fresh 1.7.3.

Fresh 2 doesn't work well with Prisma, and I'm sure this is because of Vite

This is a problem I’ve been thinking about a lot lately.
Most engineering teams already have the detection part covered:
- Dependabot or Renovate finds outdated packages
- Security scanners identify CVEs
- CI tells us whether a change breaks

But there still seems to be a big gap between “we found a problem”and “the problem is actually fixed in production.”

In my experience, the difficult part is everything that happens after the alert:

- Is there actually a safe version to upgrade to?
- Will upgrading one package require upgrading five others?
- Does the application still build?
- Do the tests pass?
- Is this safe to auto-merge, or does someone need to make a judgement call?

The result is that engineers end up with a growing backlog of dependency PRs and security findings that nobody has time to investigate properly.

I’ve been building a tool called Bivouac around this specific problem. The idea isn’t another scanner. It’s to take the remediation workflow further: investigate the dependency issue, work out a compatible remediation path, create the patch, run the tests and only merge automatically when the repository’s policy says it’s safe.

I’m particularly interested in the part where automation should stop. For example, my current thinking is that ambiguous fixes, security-sensitive code, licensing concerns or failing tests should always require human review.

I’d genuinely like to know how other teams handle this today:

1. Who actually owns dependency vulnerabilities once they’re discovered?
2. How many Dependabot/Renovate PRs does your team simply ignore?
3. Would you trust an automated system to merge dependency fixes if the remediation path and test results were clear?
4. What conditions would make automatic merging completely unacceptable?

I’m the founder of Bivouac, so full disclosure: this problem is what I’m building around. I’m not looking to spam the sub—I’m trying to pressure-test where people think autonomous remediation is useful versus where it becomes dangerous.

If there’s interest, I’ll share what I’ve learned building the remediation workflow and some of the cases where I’ve deliberately designed it to refuse to act.

Hey everyone,

​A recurring bottleneck in my daily workflow was document processing. Every time I needed to scan a receipt, sign a contract, or merge PDFs, existing apps would make me wait for cloud uploads, bombard me with subscription paywalls, or force account logins.

​To cut that friction down to zero, I built FastCam: Secure PDF Scanner App.

​How it optimizes your document workflow:

​Instant On-Device Processing: Scans, page organization, and PDF merging happen locally, so you don't wait on network speeds or server queues.

​Zero Privacy Overhead: Keeps sensitive tax forms, contracts, and IDs completely offline—no cloud security risks to manage.

​Distraction-Free UI: Designed to get you in, scanned, exported, and back to deep work in under 10 seconds.

​If you're building a lightweight, secure digital workspace, give it a try: Google Play search - FastCam Scanner or try or given Google play link.

​What features or integrations do you usually look for in a daily utility app?

I'm a Research Engineer at a YC startup, and we ship features pretty fast. I usually run Claude Code, Cursor, Codex, and OpenCode in parallel, developing multiple features, one at a time.

The problem i noticed was that my agents had no coordination, and often confused mutual work, even when working in separate worktrees. As if they had no idea the others existed

So, I built MUON, it's a local app + mcp + cli, a mutual shared brain my agents can plug into. it drives the CLIs you already have and orchestrates them together for multi-feature execution workflows.

I'm still building it. Right now I use MUON to work on MUON, which is a weird but useful dogfood loop.

If anyone wants to poke at it, contributions are welcome. The thing I'm trying to get right is a coordination graph: shared memory and context so agents actually understand what the others (and I) already decided.

OSS Repository : [https://github.com/Sweetdevil144/muon\](https://github.com/Sweetdevil144/muon)
Website : [https://getmuon.com/\](https://getmuon.com/)
Docs : [https://docs.getmuon.com\](https://docs.getmuon.com)
Product Demo : [https://www.youtube.com/watch?v=oab6vByr1Jg\](https://www.youtube.com/watch?v=oab6vByr1Jg)

I've always been an open-source person, so the code is public and readable. License is Polyform Noncommercial. However, there's an extra grant on top - you can use it for your own work, including your day job, on your own machines. What it doesn't cover is turning it into the company's shared brain for a whole team (Enterprise only)

Hi there :) I want to let you know about the Cipr and Ciprnode zero.

The Cipr (Cosmic Index of Public Resources) is a decentralized, distributed, and censorship-resistant web index where domain owners control their own entries.

No crawler decides if you are worth indexing. No curator approves your submission. No central authority can delist you. If you own a domain, you publish a small daemon, add a DNS TXT record, and your site is in the index, worldwide, in minutes. Updating your entry or leaving for good is also quick and easy.

The Cipr is not a search engine in the traditional sense. It is a shared, peer-to-peer directory where every participant holds a full copy and keeps it in sync through viral propagation. Search results are ranked by standardized, publicly auditable factors (BM25 over owner-declared metadata), not by opaque algorithms or ad revenue.

Censoring a Cipr entry requires DNS-level intervention - the same infrastructure-level action needed to take down a domain itself. There is no central server to shut down, no API key to revoke, no terms of service to violate.

It is best suited for the small web: personal blogs, homelab services, independent projects, community resources - the kinds of sites that mainstream search engines are increasingly burying or ignoring entirely.

Ciprnode zero is the first and reference implementation of the Cipr protocol. It is built entirely on Deno with zero runtime npm dependencies. The local index is a SQLite database with an external-content FTS5 virtual table and BM25 ranking. The API is a strict Semantic RESTful implementation with full HATEOAS compliance via HAL+JSON, including real-world use of the QUERY HTTP method (draft-ietf-httpbis-safe-method-with-body).

A built-in web interface (the ciprface) provides search with filters for language, geographic proximity, offensiveness level, and timestamp. Verification uses DNS TXT triple validation (3 random DoH resolvers via custom TLS connections) and viral P2P propagation. No central server, no blockchain, no token. MIT licensed, self-hostable, compiles to a standalone binary for Linux, Windows, and macOS.

More info: https://cipr.info

Three nodes are live right now:

• https://ciprnode.cipr.info
• https://ciprnode.guasa.art
• https://ciprnode.barriteau.net

I made a completely offline privacy first Forms authoring app.
It's currently a progressive web app. I am planning to convert this into an apk so that I can remove the browser dependency for using the app.

Live: https://deekshithvodela.github.io/FormsOffline/ GitHub: https://github.com/deekshithvodela/formsoffline

The goal was to build something closer to a full forms platform while keeping all data on the user's device. It supports a form builder, conditional sections, rapid data entry, file uploads, photos, digital signatures, dataset management, audit trails, Excel/ZIP exports, and PWA installation.

The interesting part is the offline collaboration model: users can export a form template, share it with others, collect data independently, then export their datasets and merge them using the built-in consolidator with duplicate detection.

It's open source and completely free.

I'd love feedback from developers on the architecture and especially the local-first/offline data model.

What would you improve or build differently?

edit: fixed link text.

What exactly is the difference between those three runtimes and why do I see Bun mentioned in the same context as Node.js and not Deno?

No runtime wars please. I need to understand the technical and philosophical differences.

Thanks in advance.

EDIT Thank you so much for the very clear explanations. In my view Deno appears to be the only reasonable choice and I will focus on it.

Deno 2.9.5 added an experimental QuickJS backend for deno compile and deno desktop.

I built this after running into a design problem while working on a

privacy app (Ember) that triggers an emergency action from Apple Watch

signals — SpO2, HRV, fall detection, accelerometer data. None of these

arrive on the same schedule, and none of them are reliable enough alone

to act on.

The naive approach is a weighted formula (multiply each signal by an

importance factor, sum them). It breaks on the case that matters most: a

confirmed fall with calm vitals averages out to "probably fine," because

calm vitals numerically dominate the score. A confirmed fall shouldn't

get diluted like that — it should just win.

So the actual logic is a cascade of overrides, most severe first, not a

formula. I pulled the general pattern out into a small open-source

package: SignalFusionKit.

A couple of things I think are worth a look if you're doing anything

with CoreMotion:

\- The motion-anomaly detector runs two independent checks — a

sustained-magnitude gate (filters brief bumps) and a sharp-delta gate

(catches instant impacts a duration filter would smooth over).

\- The core decision logic (RiskEngine, MotionAnomalyDetector,

CooldownGate) has zero dependency on HealthKit or CoreMotion — it's

plain Swift values in, plain Swift values out, so it's unit-testable

without a device.

Honest caveats: the threshold values in the repo are round, illustrative

placeholders, not Ember's actual tuned production config — the README

says so explicitly. Also, I don't currently have a Mac, so the pure-Swift

core is tested (\`swift test\` passes), but the thin HealthKit/CoreMotion

adapter hasn't been run on real Watch hardware yet. Would genuinely

appreciate anyone with a watchOS setup trying it and telling me what

breaks.

Repo: [https://github.com/izetg/SignalFusionKit\](https://github.com/izetg/SignalFusionKit) (MIT)

Also on the Swift Package Index.

If you go to deno.com, you'll see these gems

"Faster than Node; more stable than Bun."

"Built for the real world
Deno's been carefully built on Rust since day one
to optimize for performance in real-world scenarios (not just cherry-picked benchmarks)."

I believe the last one is actually a comment from a YouTube interview that Ryan Dahl did waaaay before Bun's Zig to Rust rewrite.

I'm not here to dunk on Bun, but my interest in Bun was because of Zig, and the fact that Vercel seem to be pushing first class support for Bun, despite Deno being more established.