johnspurlock

"Over the past year, we’ve seen a shift in what Deno Deploy customers are building: platforms where users generate code with LLMs, and that code runs immediately without review. That code frequently calls LLMs itself, which means it needs API keys and network access.

This isn’t the traditional “run untrusted plugins” problem. It’s deeper: LLM-generated code, calling external APIs with real credentials, without human review. Sandboxing the compute isn’t enough. You need to control network egress and protect secrets from exfiltration.

Deno Sandbox provides both. And when the code is ready, you can deploy it directly to Deno Deploy without rebuilding."

It's freely available to anyone - the data (after securely hashing IPs) is provided as a service for everyone in the open podcast system.

There is a bit about the data api in the privacy policy [1]. Feel free to engage over on the github repo if you are blocked on anything or to chat about it [2].

[1] https://op3.dev/privacy [2] https://github.com/skymethod/op3/discussions

Yea that part got lost in translation.

The OP3 API is completely free to use: https://op3.dev/api/docs

Nothing

You stick this prefix in front the audio enclosure file urls inside your rss feed

From the homepage [1]

> We've been running smoothly since Sept 2022, now measuring over 15 million podcast downloads every month across more than 1600 shows

Knock wood, but OP3 podcast redirecting has never had an single outage since it launched in Sept 2022.

Turns out Cloudflare Workers do a great job at simple http redirecting via their hundreds of edge locations, even during extended outages of the other parts of their stack.

[1] https://op3.dev

Podcasting is open in many ways, but RSS-based podcast apps have no idea what shows are "hot in cleveland" or have related listener bases, etc outside of their own app.

When shows start using OP3, they open up these (listener privacy-preserving) stats to _any_ app, and set themselves up for future discovery / inbound opportunities on this basis.

> But what is the source? Who is typically hosting these? Audio is easier to distribute than video, but aren’t most podcasts hosted on a handful of large services?

Top Podcast Hosting Companies by Episode Share: https://livewire.io/podcast-hosts-by-episode-share/

Top Podcast CDNs by Episode Share: https://livewire.io/podcast-cdns-by-episode-share/

Denoflare now has experimental support (v0.6.0+) for deploying ESM-based Typescript workers (including Wasm) not only to Cloudflare Workers, but three other edge runtimes - without wrangler, deployctl, the supabase cli, or the aws sdk

In this case, they've also documented the remote connection protocol: "KV Connect" https://github.com/denoland/deno/tree/main/ext/kv#kv-connect

I kicked the tires on this with a pure TS implementation of the protocol called kv-connect-kit that gives you the KV client api in any Javascript runtime (including Cloudflare workers, which does not have anything Deno namespace related)

- github: https://github.com/skymethod/kv-connect-kit

- npm: https://www.npmjs.com/package/kv-connect-kit

- deno/x: https://deno.land/x/kv_connect_kit

- demo: https://keyspace.deno.dev/

protocol seems to works as described on the tin, and it would be pretty straightforward to write another backend

Yes.

firesky.tv dev here - do you have javascript enabled?

If so, you should see everything posted to Bluesky in one view, like a massive chatroom.

Use the filter button to monitor for keywords/accounts etc. To me, this is probably the more long-term useful and non-brain-destroying use of the site.

Very much inspired by Twitter in the early days

Agree regarding tooling.

So much so that I wrote Denoflare (https://denoflare.dev/) to make writing Cloudflare Workers using standard Deno a breeze: no wrangler, toml, webpack, npm etc required

Deno has a built-in repl

https://deno.land/manual/tools/repl

Correct - no affiliation, just a happy customer.

Cloudflare seems to be disciplined about releasing solid lower-level platform building blocks first (e.g. durable objects), and leaving the "developer go-to framework for their advanced Worker stuff" to be built on top later.

Seems like a smart approach to me, but I agree the space is moving fast and even though they release stuff at a pretty rapid pace, it never seems fast enough for early adopters

Hi there, denoflare is still in early development, thanks for trying it out - that issue you found should be fixed in the latest release 0.3.1

Correct - denoflare scripts are served in a permissionless Deno worker locally - even the Deno namespace is unavailable, just like on Cloudflare.

Developing the worker in Deno brings you the benefit of first-class support for typescript and ESM-modules in your worker, and no need for Node polyfills.

Once you deploy your worker, it runs like any other javascript worker on the magical Cloudflare V8 worker runtime.

Author here: yes this is exactly the goal of denoflare, I started it before miniflare existed, and Deno seemed much more aligned with the Cloudflare Worker model than Node, honestly.

With denoflare, you can serve your Cloudflare Worker script locally and deploy it to Cloudflare with a single tool, without the need for Wrangler, Node, NPM, or a separate bundler.

Also makes writing/deploying ESM-module-based workers trivial - can even deploy a CF Worker to your own account from a URL, e.g. [1]

[1] denoflare push --name webtail https://raw.githubusercontent.com/skymethod/denoflare/v0.3.0...