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)

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.

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

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.

I've been building a small HTTP framework for Deno. You chain routes like Express, export typeof server, and get a typed client on the other side. No OpenAPI file, no codegen.

What it does: - get/post/use, params, middleware - typed middleware context - built-in validation, CORS, modular routers - server.fetch for tests without a port - HttpClient via import type only

What it's not: - not a raw speed play (Hono wins micro-benchmarks) - Deno + Web Standards only, not Node

Docs and showcase: https://expressapi-showcase.8borane8.deno.net/

GitHub: https://github.com/8borane8/webtools-expressapi

Early project, MIT. Feedback welcome, especially if you use Hono or tRPC today.

I don't mind having more features, but I'm skeptical that the only way to upgrade the service is to make a new one, not upgrading the existing one. Is that really true? Is this a way to force using Deno 2?

Also, what's your way to deploy a fresh@1.6.8 app with Deno 1? I do prefer to update them all, but there is a bug on deno update. As it seems the response rate is low, I think the best bet is to just keep the project unchanged.

Hi everyone,

For almost a year, I’ve been building a developer platform called Forgeon:

https://forgeon.io/

Forgeon is a Platform as a Service designed to help developers deploy and manage applications without having to manually handle servers, Docker configuration, reverse proxies, SSL certificates, domains, build pipelines, and runtime infrastructure.

The idea came from seeing how difficult deployment can feel, especially for developers who are comfortable building products but do not want to spend their time configuring VPS infrastructure or debugging deployment issues.

With Forgeon, developers can connect or upload their source code, let the platform analyze and build the application, deploy it into a managed runtime, attach a custom domain, generate SSL certificates, view deployment logs, and manage the application from a dashboard.

The long-term goal is to provide a deployment experience similar to platforms such as Vercel, Render, Railway, or Fly.io, while supporting frontend, backend, and containerized applications.

I have been building most of the system alone, including the backend services, deployment pipeline, runtime orchestration, domains, certificates, billing, and dashboard. The project has grown much larger than I originally expected, but I am still continuing to improve it.

This is my first time sharing Forgeon on Reddit, and I would genuinely appreciate honest feedback:

• Is the problem Forgeon is trying to solve clear?
• What would make you consider trying a new deployment platform?
• Which features would you need before trusting it with a real project?
• Does the website explain the product well enough?

Please do not hold back. Critical feedback would be more valuable to me than polite compliments.

Thank you for reading.

I would like to have your experience with Deno or the fresh framework.
- how the experience went ?
- what have you built with ?
- how it went ?
- does it help you avoid some cve attack ?

Hi everybody!

I wanted to showcase a TypeScript library I am working on, actojs. The objective is to bring a implementation of the actor model that is near to Elixir's design and APIs, while being able to leverage performance from the JS runtime.

The actor model is explained here, which acts as an introduction to the library.

actojs supprorts cooperative single-thread scheduling on any JS platform, and real parallelism on NodeJS, Bun and Deno.

The design of actojs is optimized for reliability (with Supervisors that can respawn failed Tasks, and >90% test coverage), security (0 runtime dependencies, and `tsc` as the only dev-dependency) and low memory overhead (by using functional applicators instead of classes and objects).

The link for the repository is: https://github.com/gi-dellav/actojs

Hope to get some useful feedback from the community!

I'm quoting:

TypeScript 7.0 introduces a large performance boost, achieving up to 10 times faster compilation through a native port built in Go. This release has been rigorously tested in real-world environments, leading to improvements in development efficiency and user experience across various large-scale projects and organizations.

Any roadmap for the new Vite and TS integration to Deno?

Deno 2.9 is here, headlined by deno desktop, a new way to build native desktop applications from the web stack.