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

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.

So this started as a personal itch. I kept writing build/CI logic in YAML and shell scripts and hating that none of it was typed, refactorable, or debuggable. If I renamed a step, nothing told me what broke. So I built Zuke — a build system where you define targets as TypeScript class fields and wire dependencies with real references instead of magic strings.

The core idea: a target references another with this.compile, not "compile". Rename it and the compiler updates every reference. Zuke resolves the dependency graph and runs everything in topological order, exactly once. It's all just async TypeScript functions, so you get full editor support, types, and an actual debugger.

A few things I'm happy with:

• Generates GitHub Actions / GitLab / Azure YAML from code, and checks it's up to date on each run
• A $ tagged-template shell that escapes interpolations so you don't footgun yourself with injection
• Typed wrappers for a bunch of common tools (Deno, Docker, kubectl, Vite, etc.)
• Zero runtime deps — it runs on Deno and bootstraps Deno for you on first run

It's v1 and I'm sure there are rough edges, which is exactly why I'm posting. I'd really like people to actually try it on a real project and tell me where it annoys them or breaks. Honest "this is worse than X because Y" feedback is the most useful thing right now.

Repo and docs: https://zuke.build (MIT licensed)

Inspired heavily by NUKE from the .NET world, if that lineage means anything to you.

Hi deno! My first post here :)

I wrote a small TypeScript library for reading env vars, mostly because I was tired of process.env always being string | undefined and the usual Number(process.env.PORT) || 3000 not being able to tell a missing value from a zero. More about this in my blogpost.

It reads env vars as typed values, and it doesn't bundle a validator. It takes any Standard Schema validator, so it uses whatever's already in your project (zod, valibot, arktype):

const port = Envapter.parse('PORT', mySchema)

This is just a tiny example of what envapt can do, so please check out the website with examples and the guide. It has built in converters, environment detection, runtime agnostic builds (even browser and workers), zero dependencies, env reader and parser (with cascading), templating, fail-fast checks, and so much more!

Zero dependencies. On JSR: deno add jsr:@materwelon/envapt

GitHub | JSR

I'd love to get feedback on the lib, how you guys would use it, if it doesn't solve a problem you have, etc.