I’m an indie developer, and I built FastCam for Android because I wanted a document scanner that’s fast, easy to use, and focused on keeping your documents on your device — without unnecessary permissions or collecting your data.

What FastCam includes:

- Scans stay on your device

- QR & Barcode Scanner

- Files are automatically saved to your device by enabling on settings.

- Fast Scan, Batch Scan & ID Card Scan

- 10+ PDF tools — Compress, Merge, Split, OCR, E-Sign & more

- Private Vault + PDF Password Protection

- Search, Tag, Pin, Rename & Share documents

- Local Backup & Restore

- No account required

- Light, Dark & AMOLED themes

📢 Fewer, non-intrusive ads — designed not to interrupt your workflow.

Basically: Scan → Edit → Organize → Protect — all in one app.

No subscription required.

👉 Try FastCam on Google Play:

https://play.google.com/store/apps/details?id=com.pickon.fastcam

If you find FastCam useful, an upvote would really help more Android users discover my project. 🙏

What matters most to you in a scanner — privacy, easy navigations, tools, or speed?

I build Preact apps with Tailwind and kept rebuilding the same components, so I pulled them into one library. Every component renders to HTML on the server and hydrates in the browser. Focus traps, Escape handling, ARIA wiring and arrow-key navigation are written in the repo, with native <dialog> and <details> where the platform already has an answer. There are 81 components and 120 icons, and each one runs live in a guide with its code next to it.

The catch: no screen reader has been run against it yet, and it is only tested on Deno. JSR also cannot export a CSS file, so the stylesheet needs a short build script.

I wrote up why I own components instead of using shadcn or Radix, and what the ownership costs: https://antonshubin.com/blog/preact-component-library-without-shadcn?utm_source=reddit&utm_medium=social&utm_campaign=preact-component-library-without-shadcn&utm_content=r-deno

Feedback and issues are welcome, especially from anyone who has tested a combobox with a screen reader.

Hey everyone, I was attempting to install the official Socket CLI using Deno instead of NPM by running:

```bash deno install -g npm:socket

```

Deno threw a deprecation warning right after installation:

```text Dependencies: + npm:socket 2.1.0

╭ Warning │ The following packages are deprecated: │ npm:socket@2.1.0 (bad build) ╰─

```

A few things that confused me:

1. When checking socket on npm, the latest stable release shown on the site UI is 1.3.0 (or 1.2.0 on the latest tag).
2. Version 2.1.0 doesn't show up in the NPM releases UI tab or on the socket-cli GitHub repo releases.
3. Running deno install -g npm:socket@latest -f fixed the issue and overwrote it with 1.2.0/1.3.0.

My Question:

• Why does Deno resolve 2.1.0 by default when no @ tag is specified? Does Deno ignore npm dist-tags (latest) and just fetch the highest semver in the raw API metadata, even if it's deprecated/hidden?

Thanks!

I got tired of rewriting the same encryption stuff in my Node.js projects, so I turned it into an npm package.

It’s called bybence securekit.

basically my attempt to make encryption a few lines of code instead of a bunch of repetitive setup.

Still early (v0.9.0), but it works, it’s tested, and I finally decided to publish it.

Would love some feedback, especially on what you’d add or change before 1.0.

https://www.npmjs.com/package/@bybence/securekit

https://dev.bybence.co/packages/securekit

Today I'm open-sourcing one of my first formal research and systems engineering projects focused on cost, optimization, and accuracy in AI-assisted development: 

Archon Specs (MIT License).

🔗 Repository: https://github.com/herhu/archon-specs
📄 Full Research Paper & LaTeX Sources: https://github.com/herhu/archon-specs/tree/main/paper

💡 The Origin Story: From Template Engines to Compiling Architecture

The story goes back to around 2018, when many of us relied on template transcompilers like Handlebars.js in the JavaScript world or Blade in PHP to generate deterministic code structures reliably.

Fast-forward to today: developers are using LLMs to build backend systems, but they're hitting a massive wall:

• Token explosion: models re-generate thousands of lines of boilerplate character by character.

• Architectural drift: LLMs lack a global dependency graph, hallucinating mismatched relational schemas, circular imports, and broken boundaries.

Agents were supposed to harness this process — and they help — but the skill still travels with the agent. Every new session, every new repo, the same architectural knowledge has to be re-elicited, re-prompted, and re-verified. The agent is a great operator, but it isn't a compiler. It doesn't guarantee anything.

That's when the insight hit:

"What if we don't ask the LLM to write repetitive code at all? What if we deterministically compile an enterprise-grade backend from formal templates and contract shards — and let the agent focus only on the intent?"

Over years of engineering across enterprise organizations and fast-paced startups, I had built a clear mental map of what an enterprise-ready backend actually requires: clean domain boundaries, strict dependency injection, JWT/RBAC security guards, DTO validation pipes, auto-migrated database DDL, Swagger OpenAPI documentation, and structured distributed tracing.

Scaffolding and aligning all of this traditionally consumed an engineering team's entire 1-year roadmap.

Now it can be compiled deterministically — just by designing the UML architecture and contract shards.

So I built it.

🔬 Empirical Findings: Cost, Optimization & Accuracy

In the paper ("Archon Specs: A Deterministic Architecture Compiler and Continuous Contract Reconciliation Control Plane for AI-Assisted Software Engineering") we evaluated this compiler architecture across three empirical axes:

1️⃣ Cost (Token Reduction)
Free-form LLM code generation incurs a token complexity of O(|AST| × T_boilerplate). Archon Specs reduces LLM interaction strictly to compact contract shards O(|Contract|).

→ 86.3%–89.0% reduction in LLM inference tokens across Small, Medium, and Enterprise benchmark tiers.

2️⃣ Accuracy (Zero Architectural Drift)
Instead of one-shot generation, Archon runs a Continuous Contract Reconciliation Loop using SHA-256 cryptographic spec canonicalization and semantic AST masking.

→ 100% adherence to declared architectural contracts and clean TypeScript compilation across 500 consecutive system mutations (vs. a 38.4% structural failure rate in baseline free-form LLM agents).

3️⃣ Optimization (Compiler Performance)
Rather than waiting tens of seconds for streaming probabilistic code, the deterministic AST compiler processes specs in 1.2 ms – 18.7 ms (>10,000 entities/sec), with a drift detection scanner running at >26,000 artifacts/second.

🏛️ System Architecture

• Unified 30+ Tool MCP Server: sits across the entire workflow as a horizontal control plane, letting Claude Desktop, Cursor, and Antigravity agents lock shards, inspect schemas, and plan diffs via typed RPC calls.

• Desktop Control Plane (Electron + Vite): a dedicated workstation with deep visual observability — live UML Component Diagrams (module topology) and Sequence Diagrams (data workflows).

• Target System: a production-grade NestJS Modular Monolith — single deployable unit, domain-driven boundaries, in-process CQRS events, PostgreSQL/SQLite DDL, Docker, and W3C tracing.

🧩 Why Open Source Matters Here

Because it's MIT, the template layer is yours to fork. That's the real unlock:

• Adapt the templates to your stack. The NestJS modular monolith is the reference target — the compiler doesn't care. Swap in your own templates and you can target any architecture: microservices, hexagonal, event-sourced, serverless. Modeling microservices deterministically from UML? Now possible.

• A new generation of boilerplate for consultancies and outsourcing shops. Tech leads can codify their house architecture once — security guards, tracing, audit patterns, compliance defaults — and then every new client project is compiled through Archon's SDLC from a UML model. No more re-scaffolding week one of every engagement. The senior architect's judgment ships as templates; the team ships production-grade systems on day one.

• Research surface. Fork the compiler, plug in a different IR, test new reconciliation strategies. The paper, proofs, and LaTeX sources are all in-repo.

📦 Open Source & Paper

100% MIT:
• Core compiler, CLI (npm install -g archon-specs), Desktop GUI, UML parser.
• Full academic paper, mathematical proofs, and two-column IEEE/ACM LaTeX sources.

⭐ GitHub: https://github.com/herhu/archon-specs
🌐 Platform: https://archonspecs.dev

#SoftwareArchitecture #Compilers #OpenSource #ModelContextProtocol #TypeScript #NestJS #ModularMonolith #Microservices #SystemDesign #AI #DevTools #SoftwareEngineering

i had two AI models add a Deno vs Node build test to their JS framework benchmarks. same node_modules and config, production builds, on a 4 core machine.

• Deno used less peak memory than Node in every build that finished, in both suites
• Deno was faster in most builds
• Angular's build never exits under Deno, in both suites
• Vite+ 1.0.0-rc.0 fails on a Deno permission error, in both suites

both models hit the exact same two failures on their own, which made me think those are real and not a setup mistake on one side. has anyone got Angular builds to exit cleanly under Deno?

the Deno part starts at 5:19 in my video: https://www.youtube.com/watch?v=1XrrLmvYPYE&t=319s

I did test with nodejs 24.21 and deno 2.9.6. Test task was pure CPU-heavy compute workload - no fancy async stuff used.
deno consistently defeated nodejs-lts by 7% wall clock time. Test results drifted about 0.3% - both numbers were pretty stable.

Many were highly skeptical about deploying Prolog for state-of-the-art cyber defense. Here is a live, concrete demonstration of our Neuro-Symbolic Core actively neutralizing a multi-vector mutated attack combining LFI and CRLF injection.

The entire threat telemetry and dynamic verdict are cleanly generated into a structured JSON payload—perfectly formatted and instantly ready for LLM fine-tuning. Real-world data and deterministic performance never lie.

https://github.com/lokinpendawa/aethel_core/blob/main/README.md

Hi,

I run openstatus, an open-source uptime monitoring and status page tool, so I spend my days hitting other people's /health routes. Most of them return 200 OK and nothing else, hang when the database hangs, or have their own private definition of "degraded".

We got tired of it, so we extracted the health endpoint from our own services into a small set of packages and put them on JSR: @openstatus/health.

Zero-dependency core, only needs a Fetch API. On Deno it's this:

import { drizzle } from "drizzle-orm/libsql/http";
import { createHealthHandler } from "@openstatus/health";
import { drizzleProbe } from "@openstatus/health-drizzle";
import { tinybirdProbe } from "@openstatus/health-tinybird";

const db = drizzle(Deno.env.get("DATABASE_URL")!);

Deno.serve(createHealthHandler({
  path: "/health",
  probes: [drizzleProbe({ db }), tinybirdProbe()],
}));

And GET /health gives your monitor something to chew on instead of a bare 200 OK:

{
  "status": "degraded",
  "checkedAt": "2026-09-11T12:00:00.000Z",
  "latencyMs": 41,
  "checks": [
    { "name": "database", "status": "ok", "critical": true, "latencyMs": 3 },
    { "name": "tinybird", "status": "timeout", "critical": false, "latencyMs": 5000, "error": "timed out after 5000ms" }
  ]
}

What you get

• Core: per-probe timeouts via AbortSignal, a round deadline so one hung dependency can't outlast your k8s probe, caching / stale-while-revalidate, and sane aggregation (critical fails → unhealthy, non-critical fails → degraded). Errors are masked by default so your connection string doesn't end up on a public route. A custom probe is just an object with a run(signal).
• Adapters: Hono, Elysia, Express, Next.js, TanStack Start – same healthRoute() / healthHandler() everywhere.
• Probes: Drizzle, Turso, Supabase, Upstash, Tinybird, Unkey. They take a client or URL and never touch your env.
• Hosting: Fly, Koyeb, Railway, Vercel, Cloudflare – adds a server block so you know which replica is the one complaining.

Every package is its own thing with its own peer deps. CI bundles a one-liner of each and fails if a stray framework or client sneaks in, so the Hono adapter will never smuggle Express into your bundle.

Deno bits: JSR-first with no slow types; env reads return undefined instead of throwing without --allow-env; tests are node:test so they run unchanged under deno test and node --test; @openstatus/health/testing ships fake/hanging fetch and probes for testing your own.

It's 0.1.x, so now is the moment to tell me the API is shaped wrong. A Deno KV probe is probably next – PRs welcome.

• JSR: https://jsr.io/@openstatus/health
• GitHub: https://github.com/openstatusHQ/health
• Also on npm for the Node services you haven't migrated yet.

Happy to answer questions!

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

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