@logtape/lint adds lint rules for ESLint v8/v9 (flat config), Oxlint, and Deno Lint that catch common logging mistakes before they reach production: template literal interpolation in message arguments, eager property evaluation where lazy is needed, unawaited async log callbacks, and missing meta sink configuration.
@logtape/testing gives you createLogRecorder() and domain-aware assertion helpers, replacing the hand-rolled array-sink boilerplate that every project ends up writing.
Other highlights:
context: true on Express/Hono/Koa/Elysia middleware handles request ID generation, x-request-id header propagation, and implicit context. One option instead of several moving parts.
Seven performance optimizations on the enabled-logging hot path
@logtape/lint adds lint rules for ESLint v8/v9 (flat config), Oxlint, and Deno Lint that catch common logging mistakes before they reach production: template literal interpolation in message arguments, eager property evaluation where lazy is needed, unawaited async log callbacks, and missing meta sink configuration.
@logtape/testing gives you createLogRecorder() and domain-aware assertion helpers, replacing the hand-rolled array-sink boilerplate that every project ends up writing.
Other highlights:
context: true on Express/Hono/Koa/Elysia middleware handles request ID generation, x-request-id header propagation, and implicit context. One option instead of several moving parts.
Seven performance optimizations on the enabled-logging hot path
@logtape/lint adds lint rules for ESLint v8/v9 (flat config), Oxlint, and Deno Lint that catch common logging mistakes before they reach production: template literal interpolation in message arguments, eager property evaluation where lazy is needed, unawaited async log callbacks, and missing meta sink configuration.
@logtape/testing gives you createLogRecorder() and domain-aware assertion helpers, replacing the hand-rolled array-sink boilerplate that every project ends up writing.
Other highlights:
context: true on Express/Hono/Koa/Elysia middleware handles request ID generation, x-request-id header propagation, and implicit context. One option instead of several moving parts.
Seven performance optimizations on the enabled-logging hot path
@logtape/lint adds lint rules for ESLint v8/v9 (flat config), Oxlint, and Deno Lint that catch common logging mistakes before they reach production: template literal interpolation in message arguments, eager property evaluation where lazy is needed, unawaited async log callbacks, and missing meta sink configuration.
@logtape/testing gives you createLogRecorder() and domain-aware assertion helpers, replacing the hand-rolled array-sink boilerplate that every project ends up writing.
Other highlights:
context: true on Express/Hono/Koa/Elysia middleware handles request ID generation, x-request-id header propagation, and implicit context. One option instead of several moving parts.
Seven performance optimizations on the enabled-logging hot path
Deno 2.8.0 is out. The compatibility work is real: the #Node.js test suite pass rate jumped from 42% to 76.4%, deno install is now a drop-in for npm install, lib.node is included by default, and setTimeout() now returns a NodeJS.Timeout instead of a number. None of that is irrational on its own. Put it together, though, and #Deno starts looking less like an alternative to Node.js and more like a cleaner way to run Node.js-shaped code.
It reminds me of OS/2's Win32 compatibility layer. IBM offered it so developers wouldn't have to choose, but the effect was the opposite: people kept writing Windows apps, and OS/2-native software never got a reason to exist. The closer Deno gets to Node.js, the less reason anyone has to think about whether their code is Deno-aware. Maybe that helps adoption. I just don't see how a Deno-native package culture survives if the winning path is “pretend it's npm.”
Deno 2.8.0 is out. The compatibility work is real: the #Node.js test suite pass rate jumped from 42% to 76.4%, deno install is now a drop-in for npm install, lib.node is included by default, and setTimeout() now returns a NodeJS.Timeout instead of a number. None of that is irrational on its own. Put it together, though, and #Deno starts looking less like an alternative to Node.js and more like a cleaner way to run Node.js-shaped code.
It reminds me of OS/2's Win32 compatibility layer. IBM offered it so developers wouldn't have to choose, but the effect was the opposite: people kept writing Windows apps, and OS/2-native software never got a reason to exist. The closer Deno gets to Node.js, the less reason anyone has to think about whether their code is Deno-aware. Maybe that helps adoption. I just don't see how a Deno-native package culture survives if the winning path is “pretend it's npm.”
Deno 2.8.0 is out. The compatibility work is real: the #Node.js test suite pass rate jumped from 42% to 76.4%, deno install is now a drop-in for npm install, lib.node is included by default, and setTimeout() now returns a NodeJS.Timeout instead of a number. None of that is irrational on its own. Put it together, though, and #Deno starts looking less like an alternative to Node.js and more like a cleaner way to run Node.js-shaped code.
It reminds me of OS/2's Win32 compatibility layer. IBM offered it so developers wouldn't have to choose, but the effect was the opposite: people kept writing Windows apps, and OS/2-native software never got a reason to exist. The closer Deno gets to Node.js, the less reason anyone has to think about whether their code is Deno-aware. Maybe that helps adoption. I just don't see how a Deno-native package culture survives if the winning path is “pretend it's npm.”
Fedify is an #ActivityPub server framework in #TypeScript & #JavaScript. It aims to eliminate the complexity and redundant boilerplate code when building a federated server app, so that you can focus on your business logic and user experience.
The key features it provides currently are:
Type-safe objects for Activity Vocabulary (including some vendor-specific extensions)
I started it because I wanted a TypeScript CLI parser that felt more like optparse-applicative than the usual builder-style APIs. You build up small typed parsers, compose them, and TypeScript infers the result. It handles subcommands, option dependencies, shell completion, and man pages, and it runs on #Deno, #Node.js, and #Bun.
For 1.0 I added @optique/env, so env vars can fill in missing flags, and @optique/inquirer, so missing values can fall back to Inquirer.js prompts. I also cleaned up a lot of awkward API edges and fixed a long backlog of completion bugs across five shells.
I started it because I wanted a TypeScript CLI parser that felt more like optparse-applicative than the usual builder-style APIs. You build up small typed parsers, compose them, and TypeScript infers the result. It handles subcommands, option dependencies, shell completion, and man pages, and it runs on #Deno, #Node.js, and #Bun.
For 1.0 I added @optique/env, so env vars can fill in missing flags, and @optique/inquirer, so missing values can fall back to Inquirer.js prompts. I also cleaned up a lot of awkward API edges and fixed a long backlog of completion bugs across five shells.
I started it because I wanted a TypeScript CLI parser that felt more like optparse-applicative than the usual builder-style APIs. You build up small typed parsers, compose them, and TypeScript infers the result. It handles subcommands, option dependencies, shell completion, and man pages, and it runs on #Deno, #Node.js, and #Bun.
For 1.0 I added @optique/env, so env vars can fill in missing flags, and @optique/inquirer, so missing values can fall back to Inquirer.js prompts. I also cleaned up a lot of awkward API edges and fixed a long backlog of completion bugs across five shells.
We're excited to announce the release of BotKit 0.3.0! This release marks a significant milestone as #BotKit now supports #Node.js alongside #Deno, making it accessible to a wider audience. The minimum required Node.js version is 22.0.0. This dual-runtime support means you can now choose your preferred #JavaScript runtime while building #ActivityPub#bots with the same powerful BotKit APIs.
One of the most requested features has landed: poll support! You can now create interactive polls in your #bot messages, allowing followers to vote on questions with single or multiple-choice options. Polls are represented as ActivityPub Question objects with proper expiration times, and your bot can react to votes through the new onVote event handler. This feature enhances engagement possibilities and brings BotKit to feature parity with major #fediverse platforms like Mastodon and Misskey.
The web frontend has been enhanced with a new followers page, thanks to the contribution from Hyeonseo Kim (@gaebalgom)! The /followers route now displays a paginated list of your bot's followers, and the follower count on the main profile page is now clickable, providing better visibility into your bot's audience. This improvement makes the web interface more complete and user-friendly.
For developers looking for alternative storage backends, we've introduced the SqliteRepository through the new @fedify/botkit-sqlite package. This provides a production-ready SQLite-based storage solution with ACID compliance, write-ahead logging (WAL) for optimal performance, and proper indexing. Additionally, the new @fedify/botkit/repository module offers MemoryCachedRepository for adding an in-memory cache layer on top of any repository implementation, improving read performance for frequently accessed data.
This release also includes an important security update: we've upgraded to #Fedify 1.8.8, ensuring your bots stay secure and compatible with the latest ActivityPub standards. The repository pattern has been expanded with new interfaces and types like RepositoryGetMessagesOptions, RepositoryGetFollowersOptions, and proper support for polls storage through the KvStoreRepositoryPrefixes.polls option, providing more flexibility for custom implementations.
Fedify is an #ActivityPub server framework in #TypeScript & #JavaScript. It aims to eliminate the complexity and redundant boilerplate code when building a federated server app, so that you can focus on your business logic and user experience.
The key features it provides currently are:
Type-safe objects for Activity Vocabulary (including some vendor-specific extensions)
Fedify is an #ActivityPub server framework in #TypeScript & #JavaScript. It aims to eliminate the complexity and redundant boilerplate code when building a federated server app, so that you can focus on your business logic and user experience.
The key features it provides currently are:
Type-safe objects for Activity Vocabulary (including some vendor-specific extensions)
Fedify is an #ActivityPub server framework in #TypeScript & #JavaScript. It aims to eliminate the complexity and redundant boilerplate code when building a federated server app, so that you can focus on your business logic and user experience.
The key features it provides currently are:
Type-safe objects for Activity Vocabulary (including some vendor-specific extensions)
Fedify is an #ActivityPub server framework in #TypeScript & #JavaScript. It aims to eliminate the complexity and redundant boilerplate code when building a federated server app, so that you can focus on your business logic and user experience.
The key features it provides currently are:
Type-safe objects for Activity Vocabulary (including some vendor-specific extensions)
#BotKit is a #TypeScript framework for building #ActivityPub bots. The difference from typical Mastodon/Misskey bots? Your bot runs as its own independent server—no platform account needed.
This means no character limits, no rate limiting headaches, no API restrictions.
#BotKit is a #TypeScript framework for building #ActivityPub bots. The difference from typical Mastodon/Misskey bots? Your bot runs as its own independent server—no platform account needed.
This means no character limits, no rate limiting headaches, no API restrictions.
#BotKit is a #TypeScript framework for building #ActivityPub bots. The difference from typical Mastodon/Misskey bots? Your bot runs as its own independent server—no platform account needed.
This means no character limits, no rate limiting headaches, no API restrictions.
#BotKit is a #TypeScript framework for building #ActivityPub bots. The difference from typical Mastodon/Misskey bots? Your bot runs as its own independent server—no platform account needed.
This means no character limits, no rate limiting headaches, no API restrictions.
#BotKit is a #TypeScript framework for building #ActivityPub bots. The difference from typical Mastodon/Misskey bots? Your bot runs as its own independent server—no platform account needed.
This means no character limits, no rate limiting headaches, no API restrictions.
#BotKit is a #TypeScript framework for building #ActivityPub bots. The difference from typical Mastodon/Misskey bots? Your bot runs as its own independent server—no platform account needed.
This means no character limits, no rate limiting headaches, no API restrictions.
#BotKit is a #TypeScript framework for building #ActivityPub bots. The difference from typical Mastodon/Misskey bots? Your bot runs as its own independent server—no platform account needed.
This means no character limits, no rate limiting headaches, no API restrictions.
#BotKit is a #TypeScript framework for building #ActivityPub bots. The difference from typical Mastodon/Misskey bots? Your bot runs as its own independent server—no platform account needed.
This means no character limits, no rate limiting headaches, no API restrictions.
#BotKit is a #TypeScript framework for building #ActivityPub bots. The difference from typical Mastodon/Misskey bots? Your bot runs as its own independent server—no platform account needed.
This means no character limits, no rate limiting headaches, no API restrictions.
#BotKit is a #TypeScript framework for building #ActivityPub bots. The difference from typical Mastodon/Misskey bots? Your bot runs as its own independent server—no platform account needed.
This means no character limits, no rate limiting headaches, no API restrictions.
#BotKit is a #TypeScript framework for building #ActivityPub bots. The difference from typical Mastodon/Misskey bots? Your bot runs as its own independent server—no platform account needed.
This means no character limits, no rate limiting headaches, no API restrictions.
#BotKit is a #TypeScript framework for building #ActivityPub bots. The difference from typical Mastodon/Misskey bots? Your bot runs as its own independent server—no platform account needed.
This means no character limits, no rate limiting headaches, no API restrictions.
#BotKit is a #TypeScript framework for building #ActivityPub bots. The difference from typical Mastodon/Misskey bots? Your bot runs as its own independent server—no platform account needed.
This means no character limits, no rate limiting headaches, no API restrictions.
Fedify is an #ActivityPub server framework in #TypeScript & #JavaScript. It aims to eliminate the complexity and redundant boilerplate code when building a federated server app, so that you can focus on your business logic and user experience.
The key features it provides currently are:
Type-safe objects for Activity Vocabulary (including some vendor-specific extensions)
Exciting news for #Fedify developers! We've just landed a major milestone for Fedify 2.0—the #CLI now runs natively on #Node.js and #Bun, not just #Deno (#456). If you install @fedify/cli@2.0.0-dev.1761 from npm, you'll get actual JavaScript that executes directly in your runtime, no more pre-compiled binaries from deno compile. This is part of our broader transition to Optique, a new cross-runtime CLI framework we've developed specifically for Fedify's needs (#374).
This change means a more natural development experience regardless of your #JavaScript runtime preference. Node.js developers can now run the CLI tools directly through their familiar ecosystem, and the same goes for Bun users. While Fedify 2.0 isn't released yet, we're excited to share this progress with the community—feel free to try out the dev version and let us know how it works for you!
Exciting news for #Fedify developers! We've just landed a major milestone for Fedify 2.0—the #CLI now runs natively on #Node.js and #Bun, not just #Deno (#456). If you install @fedify/cli@2.0.0-dev.1761 from npm, you'll get actual JavaScript that executes directly in your runtime, no more pre-compiled binaries from deno compile. This is part of our broader transition to Optique, a new cross-runtime CLI framework we've developed specifically for Fedify's needs (#374).
This change means a more natural development experience regardless of your #JavaScript runtime preference. Node.js developers can now run the CLI tools directly through their familiar ecosystem, and the same goes for Bun users. While Fedify 2.0 isn't released yet, we're excited to share this progress with the community—feel free to try out the dev version and let us know how it works for you!
Exciting news for #Fedify developers! We've just landed a major milestone for Fedify 2.0—the #CLI now runs natively on #Node.js and #Bun, not just #Deno (#456). If you install @fedify/cli@2.0.0-dev.1761 from npm, you'll get actual JavaScript that executes directly in your runtime, no more pre-compiled binaries from deno compile. This is part of our broader transition to Optique, a new cross-runtime CLI framework we've developed specifically for Fedify's needs (#374).
This change means a more natural development experience regardless of your #JavaScript runtime preference. Node.js developers can now run the CLI tools directly through their familiar ecosystem, and the same goes for Bun users. While Fedify 2.0 isn't released yet, we're excited to share this progress with the community—feel free to try out the dev version and let us know how it works for you!
Exciting news for #Fedify developers! We've just landed a major milestone for Fedify 2.0—the #CLI now runs natively on #Node.js and #Bun, not just #Deno (#456). If you install @fedify/cli@2.0.0-dev.1761 from npm, you'll get actual JavaScript that executes directly in your runtime, no more pre-compiled binaries from deno compile. This is part of our broader transition to Optique, a new cross-runtime CLI framework we've developed specifically for Fedify's needs (#374).
This change means a more natural development experience regardless of your #JavaScript runtime preference. Node.js developers can now run the CLI tools directly through their familiar ecosystem, and the same goes for Bun users. While Fedify 2.0 isn't released yet, we're excited to share this progress with the community—feel free to try out the dev version and let us know how it works for you!
Exciting news for #Fedify developers! We've just landed a major milestone for Fedify 2.0—the #CLI now runs natively on #Node.js and #Bun, not just #Deno (#456). If you install @fedify/cli@2.0.0-dev.1761 from npm, you'll get actual JavaScript that executes directly in your runtime, no more pre-compiled binaries from deno compile. This is part of our broader transition to Optique, a new cross-runtime CLI framework we've developed specifically for Fedify's needs (#374).
This change means a more natural development experience regardless of your #JavaScript runtime preference. Node.js developers can now run the CLI tools directly through their familiar ecosystem, and the same goes for Bun users. While Fedify 2.0 isn't released yet, we're excited to share this progress with the community—feel free to try out the dev version and let us know how it works for you!
Exciting news for #Fedify developers! We've just landed a major milestone for Fedify 2.0—the #CLI now runs natively on #Node.js and #Bun, not just #Deno (#456). If you install @fedify/cli@2.0.0-dev.1761 from npm, you'll get actual JavaScript that executes directly in your runtime, no more pre-compiled binaries from deno compile. This is part of our broader transition to Optique, a new cross-runtime CLI framework we've developed specifically for Fedify's needs (#374).
This change means a more natural development experience regardless of your #JavaScript runtime preference. Node.js developers can now run the CLI tools directly through their familiar ecosystem, and the same goes for Bun users. While Fedify 2.0 isn't released yet, we're excited to share this progress with the community—feel free to try out the dev version and let us know how it works for you!
Exciting news for #Fedify developers! We've just landed a major milestone for Fedify 2.0—the #CLI now runs natively on #Node.js and #Bun, not just #Deno (#456). If you install @fedify/cli@2.0.0-dev.1761 from npm, you'll get actual JavaScript that executes directly in your runtime, no more pre-compiled binaries from deno compile. This is part of our broader transition to Optique, a new cross-runtime CLI framework we've developed specifically for Fedify's needs (#374).
This change means a more natural development experience regardless of your #JavaScript runtime preference. Node.js developers can now run the CLI tools directly through their familiar ecosystem, and the same goes for Bun users. While Fedify 2.0 isn't released yet, we're excited to share this progress with the community—feel free to try out the dev version and let us know how it works for you!
Exciting news for #Fedify developers! We've just landed a major milestone for Fedify 2.0—the #CLI now runs natively on #Node.js and #Bun, not just #Deno (#456). If you install @fedify/cli@2.0.0-dev.1761 from npm, you'll get actual JavaScript that executes directly in your runtime, no more pre-compiled binaries from deno compile. This is part of our broader transition to Optique, a new cross-runtime CLI framework we've developed specifically for Fedify's needs (#374).
This change means a more natural development experience regardless of your #JavaScript runtime preference. Node.js developers can now run the CLI tools directly through their familiar ecosystem, and the same goes for Bun users. While Fedify 2.0 isn't released yet, we're excited to share this progress with the community—feel free to try out the dev version and let us know how it works for you!
Exciting news for #Fedify developers! We've just landed a major milestone for Fedify 2.0—the #CLI now runs natively on #Node.js and #Bun, not just #Deno (#456). If you install @fedify/cli@2.0.0-dev.1761 from npm, you'll get actual JavaScript that executes directly in your runtime, no more pre-compiled binaries from deno compile. This is part of our broader transition to Optique, a new cross-runtime CLI framework we've developed specifically for Fedify's needs (#374).
This change means a more natural development experience regardless of your #JavaScript runtime preference. Node.js developers can now run the CLI tools directly through their familiar ecosystem, and the same goes for Bun users. While Fedify 2.0 isn't released yet, we're excited to share this progress with the community—feel free to try out the dev version and let us know how it works for you!
Exciting news for #Fedify developers! We've just landed a major milestone for Fedify 2.0—the #CLI now runs natively on #Node.js and #Bun, not just #Deno (#456). If you install @fedify/cli@2.0.0-dev.1761 from npm, you'll get actual JavaScript that executes directly in your runtime, no more pre-compiled binaries from deno compile. This is part of our broader transition to Optique, a new cross-runtime CLI framework we've developed specifically for Fedify's needs (#374).
This change means a more natural development experience regardless of your #JavaScript runtime preference. Node.js developers can now run the CLI tools directly through their familiar ecosystem, and the same goes for Bun users. While Fedify 2.0 isn't released yet, we're excited to share this progress with the community—feel free to try out the dev version and let us know how it works for you!
Exciting news for #Fedify developers! We've just landed a major milestone for Fedify 2.0—the #CLI now runs natively on #Node.js and #Bun, not just #Deno (#456). If you install @fedify/cli@2.0.0-dev.1761 from npm, you'll get actual JavaScript that executes directly in your runtime, no more pre-compiled binaries from deno compile. This is part of our broader transition to Optique, a new cross-runtime CLI framework we've developed specifically for Fedify's needs (#374).
This change means a more natural development experience regardless of your #JavaScript runtime preference. Node.js developers can now run the CLI tools directly through their familiar ecosystem, and the same goes for Bun users. While Fedify 2.0 isn't released yet, we're excited to share this progress with the community—feel free to try out the dev version and let us know how it works for you!
Exciting news for #Fedify developers! We've just landed a major milestone for Fedify 2.0—the #CLI now runs natively on #Node.js and #Bun, not just #Deno (#456). If you install @fedify/cli@2.0.0-dev.1761 from npm, you'll get actual JavaScript that executes directly in your runtime, no more pre-compiled binaries from deno compile. This is part of our broader transition to Optique, a new cross-runtime CLI framework we've developed specifically for Fedify's needs (#374).
This change means a more natural development experience regardless of your #JavaScript runtime preference. Node.js developers can now run the CLI tools directly through their familiar ecosystem, and the same goes for Bun users. While Fedify 2.0 isn't released yet, we're excited to share this progress with the community—feel free to try out the dev version and let us know how it works for you!
Ω🪬Ω #FediAlgo (the customizable timeline algorithm / filtering system for your Mastodon feed) v1.2.2 is deployed now. Has a switch that makes sure any #hashtags / users / etc. that you follow are displayed as filter options even if they don't meet the minimum number of recent toots threshold.
Ω🪬Ω #FediAlgo (the customizable timeline algorithm / filtering system for your Mastodon feed) v1.2.2 is deployed now. Has a switch that makes sure any #hashtags / users / etc. that you follow are displayed as filter options even if they don't meet the minimum number of recent toots threshold.
Ω🪬Ω #FediAlgo (the customizable timeline algorithm / filtering system for your Mastodon feed) v1.2.2 is deployed now. Has a switch that makes sure any #hashtags / users / etc. that you follow are displayed as filter options even if they don't meet the minimum number of recent toots threshold.
Ω🪬Ω #FediAlgo (the customizable timeline algorithm / filtering system for your Mastodon feed) v1.2.2 is deployed now. Has a switch that makes sure any #hashtags / users / etc. that you follow are displayed as filter options even if they don't meet the minimum number of recent toots threshold.
A grumpy ItSec guy walks through the office when he overhears an exchange of words.
devops0: Two containers went rogue last night and starved the whole host. devops1: What are we supposed to do?
ItSec (walking by): Set limits. It's not rocket science. Docker exposes cgroup controls for CPU, memory, I/O and PIDs. Use them.
The point is: availability is part of security too. Linux control groups allow you to cap, isolate and observe resource usage, which is exactly how Docker enforces container limits for CPU, memory, block I/O and process counts [1]. Let's make it tangible with a small lab. We'll spin a container, install stress-ng, and watch limits in action.
# On the Docker host docker run -itd --name ubuntu-limits ubuntu:22.04 docker exec -it ubuntu-limits bash
# For my host nproc returns 4 stress-ng --cpu 4 --cpu-load 100 --timeout 30s
In another terminal, watch usage from the host.
docker stats
Now clamp CPU for the running container and see the throttle take effect.
docker update ubuntu-limits --cpus=1 docker stats
The --cpus flag is a wrapper over the Linux CFS period/quota; --cpus=1 caps the container at roughly one core worth of time on a multi‑core host.
Memory limits are similar. First tighten RAM and swap, then try to over‑allocate in the container.
# On the host docker update ubuntu-limits --memory=128m --memory-swap=256m docker stats
# Inside the container: stays under the cap stress-ng --vm 1 --vm-bytes 100M --timeout 30s --vm-keep
# Inside the container: tries to exceed; you may see reclaim/pressure instead of success stress-ng --vm 1 --vm-bytes 300M --timeout 30s --vm-keep
A few memory details matter. --memory is the hard ceiling; --memory-swap controls total RAM+swap available. Setting swap equal to memory disables swap for that container; leaving it unset often allows swap equal to the memory limit; setting -1 allows unlimited swap up to what the host provides.
For plain docker compose (non‑Swarm), set service‑level attributes. The Compose Services reference explicitly supports cpus, mem_limit, memswap_limit and pids_limit on services [2].
services: api: image: ubuntu:22.04 command: ["sleep","infinity"] cpus: "1" # 50% of one CPU equivalent mem_limit: "256m" # hard RAM limit memswap_limit: "256m" # RAM+swap; equal to mem_limit disables swap pids_limit: 50 # max processes inside the container
A grumpy ItSec guy walks through the office when he overhears an exchange of words.
devops0: Two containers went rogue last night and starved the whole host. devops1: What are we supposed to do?
ItSec (walking by): Set limits. It's not rocket science. Docker exposes cgroup controls for CPU, memory, I/O and PIDs. Use them.
The point is: availability is part of security too. Linux control groups allow you to cap, isolate and observe resource usage, which is exactly how Docker enforces container limits for CPU, memory, block I/O and process counts [1]. Let's make it tangible with a small lab. We'll spin a container, install stress-ng, and watch limits in action.
# On the Docker host docker run -itd --name ubuntu-limits ubuntu:22.04 docker exec -it ubuntu-limits bash
# For my host nproc returns 4 stress-ng --cpu 4 --cpu-load 100 --timeout 30s
In another terminal, watch usage from the host.
docker stats
Now clamp CPU for the running container and see the throttle take effect.
docker update ubuntu-limits --cpus=1 docker stats
The --cpus flag is a wrapper over the Linux CFS period/quota; --cpus=1 caps the container at roughly one core worth of time on a multi‑core host.
Memory limits are similar. First tighten RAM and swap, then try to over‑allocate in the container.
# On the host docker update ubuntu-limits --memory=128m --memory-swap=256m docker stats
# Inside the container: stays under the cap stress-ng --vm 1 --vm-bytes 100M --timeout 30s --vm-keep
# Inside the container: tries to exceed; you may see reclaim/pressure instead of success stress-ng --vm 1 --vm-bytes 300M --timeout 30s --vm-keep
A few memory details matter. --memory is the hard ceiling; --memory-swap controls total RAM+swap available. Setting swap equal to memory disables swap for that container; leaving it unset often allows swap equal to the memory limit; setting -1 allows unlimited swap up to what the host provides.
For plain docker compose (non‑Swarm), set service‑level attributes. The Compose Services reference explicitly supports cpus, mem_limit, memswap_limit and pids_limit on services [2].
services: api: image: ubuntu:22.04 command: ["sleep","infinity"] cpus: "1" # 50% of one CPU equivalent mem_limit: "256m" # hard RAM limit memswap_limit: "256m" # RAM+swap; equal to mem_limit disables swap pids_limit: 50 # max processes inside the container
#NPM from #Node.js ended up in the hands of Microsoft.
#RubyGems from #Ruby ended up in the hands of a nazi libertarian.
It feels like #OSS and #FOSS are being attacked on a daily basis.
Do anyone have information regarding #PyPi from #Python, is it also compromised? As far as I know, PyPi stopped working with pip search ("Use the browser") and the website needs JS to function (because it uses some PoW browser checking), so using Lynx or elinks as a sysadmin on a terminal-only machine in order to search for Python packages have been a no-no. Wonder how much it's due to similar phenomenon going on with Ruby and Node.js ecosystems.
We're excited to announce Optique 0.4.0, which brings significant improvements
to help text organization, enhanced documentation capabilities, and introduces
comprehensive Temporal API support.
Optique is a type-safe combinatorial CLI parser for TypeScript that makes
building command-line interfaces intuitive and maintainable. This release
focuses on making your CLI applications more user-friendly and maintainable.
Better help text organization
One of the most visible improvements in Optique 0.4.0 is the enhanced help text
organization. You can now label and group your options more effectively, making
complex CLIs much more approachable for users.
Labeled merge groups
The merge() combinator now accepts an optional label parameter, solving
a common pain point where developers had to choose between clean code structure
and organized help output:
// Before: unlabeled merged options appeared scatteredconst config = merge(connectionOptions, performanceOptions);// Now: group related options under a clear sectionconst config = merge( "Server Configuration", // New label parameter connectionOptions, performanceOptions);
This simple addition makes a huge difference in help text readability,
especially for CLIs with many options spread across multiple reusable modules.
The resulting help output clearly organizes options under
the Server Configuration section:
Demo app showcasing labeled merge groupsUsage: demo-merge.ts --host STRING --port INTEGER --timeout INTEGER --retries INTEGERServer Configuration: --host STRING Server hostname or IP address --port INTEGER Port number for the connection --timeout INTEGER Connection timeout in seconds --retries INTEGER Number of retry attempts
The new group() combinator
For cases where merge() doesn't apply, the new group()
combinator lets you wrap any parser with a documentation label:
// Group mutually exclusive options under a clear sectionconst outputFormat = group( "Output Format", or( map(flag("--json"), () => "json"), map(flag("--yaml"), () => "yaml"), map(flag("--xml"), () => "xml"), ));
This is particularly useful for organizing mutually exclusive flags, multiple
inputs, or any parser that doesn't natively support labeling. The resulting
help text becomes much more scannable and user-friendly.
Here's how the grouped output format options appear in the help text:
Demo app showcasing group combinatorUsage: demo-group.ts --json demo-group.ts --yaml demo-group.ts --xmlOutput Format: --json Output in JSON format --yaml Output in YAML format --xml Output in XML format
Rich documentation support
Optique 0.4.0 introduces comprehensive documentation fields that can be added
directly through the run() function, eliminating the need to modify parser
definitions for documentation purposes.
Brief descriptions, detailed explanations, and footers
Both @optique/core/facade and @optique/run now support brief,
description, and footer options through the run() function:
import { run } from "@optique/run";import { message } from "@optique/core/message";const result = run(parser, { brief: message`A powerful data processing tool`, description: message`This tool provides comprehensive data processing capabilities with support for multiple formats and transformations. It can handle JSON, YAML, and CSV files with automatic format detection.`, footer: message`Examples: myapp process data.json --format yaml myapp validate config.toml --strictFor more information, visit https://example.com/docs`, help: "option"});
These documentation fields appear in both help output and error messages
(when configured), providing consistent context throughout your CLI's user
experience.
The complete help output demonstrates the rich documentation features with brief
description, detailed explanation, option descriptions, default values,
and footer information:
A powerful data processing toolUsage: demo-rich-docs.ts [--port INTEGER] [--format STRING] --verbose STRINGThis tool provides comprehensive data processing capabilities with support formultiple formats and transformations. It can handle JSON, YAML, and CSV fileswith automatic format detection. --port INTEGER Server port number [3000] --format STRING Output format [json] --verbose STRING Verbosity levelExamples: myapp process data.json --format yaml myapp validate config.toml --strictFor more information, visit https://example.com/docs
These documentation fields appear in both help output and error messages
(when configured), providing consistent context throughout your CLI's user
experience.
Display default values
A frequently requested feature is now available: showing default values
directly in help text. Enable this with the new showDefault option when
using withDefault():
Default values are automatically dimmed when colors are enabled, making them
visually distinct while remaining readable.
The help output shows default values clearly marked next to each option:
Usage: demo-defaults.ts [--port INTEGER] [--format STRING] --port INTEGER Server port number [3000] --format STRING Output format [json]
Temporal API support
Optique 0.4.0 introduces a new package, @optique/temporal, providing
comprehensive support for the modern Temporal API. This brings type-safe
parsing for dates, times, durations, and time zones:
import { instant, duration, zonedDateTime } from "@optique/temporal";import { option } from "@optique/core/parser";const parser = object({ // Parse ISO 8601 timestamps timestamp: option("--at", instant()), // Parse durations like "PT30M" or "P1DT2H" timeout: option("--timeout", duration()), // Parse zoned datetime with timezone info meeting: option("--meeting", zonedDateTime()),});
The temporal parsers return native Temporal objects with full functionality:
The merge() combinator now supports up to 10 parsers (previously 5), and
the tuple() parser has improved type inference using TypeScript's const
type parameter. These enhancements enable more complex CLI structures while
maintaining perfect type safety.
Breaking changes
While we've maintained backward compatibility for most APIs, there are a few
changes to be aware of:
The Parser.getDocFragments() method now uses DocState<TState> instead
of direct state values (only affects custom parser implementations)
The merge() combinator now enforces stricter type
constraints at compile time, rejecting non-object-producing parsers
Learn more
For a complete list of changes, bug fixes, and improvements, see the
full changelog.
We hope these improvements make building CLI applications with Optique even
more enjoyable. As always, we welcome your feedback and contributions on
GitHub.
We're excited to announce Optique 0.4.0, which brings significant improvements
to help text organization, enhanced documentation capabilities, and introduces
comprehensive Temporal API support.
Optique is a type-safe combinatorial CLI parser for TypeScript that makes
building command-line interfaces intuitive and maintainable. This release
focuses on making your CLI applications more user-friendly and maintainable.
Better help text organization
One of the most visible improvements in Optique 0.4.0 is the enhanced help text
organization. You can now label and group your options more effectively, making
complex CLIs much more approachable for users.
Labeled merge groups
The merge() combinator now accepts an optional label parameter, solving
a common pain point where developers had to choose between clean code structure
and organized help output:
// Before: unlabeled merged options appeared scatteredconst config = merge(connectionOptions, performanceOptions);// Now: group related options under a clear sectionconst config = merge( "Server Configuration", // New label parameter connectionOptions, performanceOptions);
This simple addition makes a huge difference in help text readability,
especially for CLIs with many options spread across multiple reusable modules.
The resulting help output clearly organizes options under
the Server Configuration section:
Demo app showcasing labeled merge groupsUsage: demo-merge.ts --host STRING --port INTEGER --timeout INTEGER --retries INTEGERServer Configuration: --host STRING Server hostname or IP address --port INTEGER Port number for the connection --timeout INTEGER Connection timeout in seconds --retries INTEGER Number of retry attempts
The new group() combinator
For cases where merge() doesn't apply, the new group()
combinator lets you wrap any parser with a documentation label:
// Group mutually exclusive options under a clear sectionconst outputFormat = group( "Output Format", or( map(flag("--json"), () => "json"), map(flag("--yaml"), () => "yaml"), map(flag("--xml"), () => "xml"), ));
This is particularly useful for organizing mutually exclusive flags, multiple
inputs, or any parser that doesn't natively support labeling. The resulting
help text becomes much more scannable and user-friendly.
Here's how the grouped output format options appear in the help text:
Demo app showcasing group combinatorUsage: demo-group.ts --json demo-group.ts --yaml demo-group.ts --xmlOutput Format: --json Output in JSON format --yaml Output in YAML format --xml Output in XML format
Rich documentation support
Optique 0.4.0 introduces comprehensive documentation fields that can be added
directly through the run() function, eliminating the need to modify parser
definitions for documentation purposes.
Brief descriptions, detailed explanations, and footers
Both @optique/core/facade and @optique/run now support brief,
description, and footer options through the run() function:
import { run } from "@optique/run";import { message } from "@optique/core/message";const result = run(parser, { brief: message`A powerful data processing tool`, description: message`This tool provides comprehensive data processing capabilities with support for multiple formats and transformations. It can handle JSON, YAML, and CSV files with automatic format detection.`, footer: message`Examples: myapp process data.json --format yaml myapp validate config.toml --strictFor more information, visit https://example.com/docs`, help: "option"});
These documentation fields appear in both help output and error messages
(when configured), providing consistent context throughout your CLI's user
experience.
The complete help output demonstrates the rich documentation features with brief
description, detailed explanation, option descriptions, default values,
and footer information:
A powerful data processing toolUsage: demo-rich-docs.ts [--port INTEGER] [--format STRING] --verbose STRINGThis tool provides comprehensive data processing capabilities with support formultiple formats and transformations. It can handle JSON, YAML, and CSV fileswith automatic format detection. --port INTEGER Server port number [3000] --format STRING Output format [json] --verbose STRING Verbosity levelExamples: myapp process data.json --format yaml myapp validate config.toml --strictFor more information, visit https://example.com/docs
These documentation fields appear in both help output and error messages
(when configured), providing consistent context throughout your CLI's user
experience.
Display default values
A frequently requested feature is now available: showing default values
directly in help text. Enable this with the new showDefault option when
using withDefault():
Default values are automatically dimmed when colors are enabled, making them
visually distinct while remaining readable.
The help output shows default values clearly marked next to each option:
Usage: demo-defaults.ts [--port INTEGER] [--format STRING] --port INTEGER Server port number [3000] --format STRING Output format [json]
Temporal API support
Optique 0.4.0 introduces a new package, @optique/temporal, providing
comprehensive support for the modern Temporal API. This brings type-safe
parsing for dates, times, durations, and time zones:
import { instant, duration, zonedDateTime } from "@optique/temporal";import { option } from "@optique/core/parser";const parser = object({ // Parse ISO 8601 timestamps timestamp: option("--at", instant()), // Parse durations like "PT30M" or "P1DT2H" timeout: option("--timeout", duration()), // Parse zoned datetime with timezone info meeting: option("--meeting", zonedDateTime()),});
The temporal parsers return native Temporal objects with full functionality:
The merge() combinator now supports up to 10 parsers (previously 5), and
the tuple() parser has improved type inference using TypeScript's const
type parameter. These enhancements enable more complex CLI structures while
maintaining perfect type safety.
Breaking changes
While we've maintained backward compatibility for most APIs, there are a few
changes to be aware of:
The Parser.getDocFragments() method now uses DocState<TState> instead
of direct state values (only affects custom parser implementations)
The merge() combinator now enforces stricter type
constraints at compile time, rejecting non-object-producing parsers
Learn more
For a complete list of changes, bug fixes, and improvements, see the
full changelog.
We hope these improvements make building CLI applications with Optique even
more enjoyable. As always, we welcome your feedback and contributions on
GitHub.
We're excited to announce Optique 0.4.0, which brings significant improvements
to help text organization, enhanced documentation capabilities, and introduces
comprehensive Temporal API support.
Optique is a type-safe combinatorial CLI parser for TypeScript that makes
building command-line interfaces intuitive and maintainable. This release
focuses on making your CLI applications more user-friendly and maintainable.
Better help text organization
One of the most visible improvements in Optique 0.4.0 is the enhanced help text
organization. You can now label and group your options more effectively, making
complex CLIs much more approachable for users.
Labeled merge groups
The merge() combinator now accepts an optional label parameter, solving
a common pain point where developers had to choose between clean code structure
and organized help output:
// Before: unlabeled merged options appeared scatteredconst config = merge(connectionOptions, performanceOptions);// Now: group related options under a clear sectionconst config = merge( "Server Configuration", // New label parameter connectionOptions, performanceOptions);
This simple addition makes a huge difference in help text readability,
especially for CLIs with many options spread across multiple reusable modules.
The resulting help output clearly organizes options under
the Server Configuration section:
Demo app showcasing labeled merge groupsUsage: demo-merge.ts --host STRING --port INTEGER --timeout INTEGER --retries INTEGERServer Configuration: --host STRING Server hostname or IP address --port INTEGER Port number for the connection --timeout INTEGER Connection timeout in seconds --retries INTEGER Number of retry attempts
The new group() combinator
For cases where merge() doesn't apply, the new group()
combinator lets you wrap any parser with a documentation label:
// Group mutually exclusive options under a clear sectionconst outputFormat = group( "Output Format", or( map(flag("--json"), () => "json"), map(flag("--yaml"), () => "yaml"), map(flag("--xml"), () => "xml"), ));
This is particularly useful for organizing mutually exclusive flags, multiple
inputs, or any parser that doesn't natively support labeling. The resulting
help text becomes much more scannable and user-friendly.
Here's how the grouped output format options appear in the help text:
Demo app showcasing group combinatorUsage: demo-group.ts --json demo-group.ts --yaml demo-group.ts --xmlOutput Format: --json Output in JSON format --yaml Output in YAML format --xml Output in XML format
Rich documentation support
Optique 0.4.0 introduces comprehensive documentation fields that can be added
directly through the run() function, eliminating the need to modify parser
definitions for documentation purposes.
Brief descriptions, detailed explanations, and footers
Both @optique/core/facade and @optique/run now support brief,
description, and footer options through the run() function:
import { run } from "@optique/run";import { message } from "@optique/core/message";const result = run(parser, { brief: message`A powerful data processing tool`, description: message`This tool provides comprehensive data processing capabilities with support for multiple formats and transformations. It can handle JSON, YAML, and CSV files with automatic format detection.`, footer: message`Examples: myapp process data.json --format yaml myapp validate config.toml --strictFor more information, visit https://example.com/docs`, help: "option"});
These documentation fields appear in both help output and error messages
(when configured), providing consistent context throughout your CLI's user
experience.
The complete help output demonstrates the rich documentation features with brief
description, detailed explanation, option descriptions, default values,
and footer information:
A powerful data processing toolUsage: demo-rich-docs.ts [--port INTEGER] [--format STRING] --verbose STRINGThis tool provides comprehensive data processing capabilities with support formultiple formats and transformations. It can handle JSON, YAML, and CSV fileswith automatic format detection. --port INTEGER Server port number [3000] --format STRING Output format [json] --verbose STRING Verbosity levelExamples: myapp process data.json --format yaml myapp validate config.toml --strictFor more information, visit https://example.com/docs
These documentation fields appear in both help output and error messages
(when configured), providing consistent context throughout your CLI's user
experience.
Display default values
A frequently requested feature is now available: showing default values
directly in help text. Enable this with the new showDefault option when
using withDefault():
Default values are automatically dimmed when colors are enabled, making them
visually distinct while remaining readable.
The help output shows default values clearly marked next to each option:
Usage: demo-defaults.ts [--port INTEGER] [--format STRING] --port INTEGER Server port number [3000] --format STRING Output format [json]
Temporal API support
Optique 0.4.0 introduces a new package, @optique/temporal, providing
comprehensive support for the modern Temporal API. This brings type-safe
parsing for dates, times, durations, and time zones:
import { instant, duration, zonedDateTime } from "@optique/temporal";import { option } from "@optique/core/parser";const parser = object({ // Parse ISO 8601 timestamps timestamp: option("--at", instant()), // Parse durations like "PT30M" or "P1DT2H" timeout: option("--timeout", duration()), // Parse zoned datetime with timezone info meeting: option("--meeting", zonedDateTime()),});
The temporal parsers return native Temporal objects with full functionality:
The merge() combinator now supports up to 10 parsers (previously 5), and
the tuple() parser has improved type inference using TypeScript's const
type parameter. These enhancements enable more complex CLI structures while
maintaining perfect type safety.
Breaking changes
While we've maintained backward compatibility for most APIs, there are a few
changes to be aware of:
The Parser.getDocFragments() method now uses DocState<TState> instead
of direct state values (only affects custom parser implementations)
The merge() combinator now enforces stricter type
constraints at compile time, rejecting non-object-producing parsers
Learn more
For a complete list of changes, bug fixes, and improvements, see the
full changelog.
We hope these improvements make building CLI applications with Optique even
more enjoyable. As always, we welcome your feedback and contributions on
GitHub.
We're excited to announce the release of BotKit 0.3.0! This release marks a significant milestone as #BotKit now supports #Node.js alongside #Deno, making it accessible to a wider audience. The minimum required Node.js version is 22.0.0. This dual-runtime support means you can now choose your preferred #JavaScript runtime while building #ActivityPub#bots with the same powerful BotKit APIs.
One of the most requested features has landed: poll support! You can now create interactive polls in your #bot messages, allowing followers to vote on questions with single or multiple-choice options. Polls are represented as ActivityPub Question objects with proper expiration times, and your bot can react to votes through the new onVote event handler. This feature enhances engagement possibilities and brings BotKit to feature parity with major #fediverse platforms like Mastodon and Misskey.
The web frontend has been enhanced with a new followers page, thanks to the contribution from Hyeonseo Kim (@gaebalgom)! The /followers route now displays a paginated list of your bot's followers, and the follower count on the main profile page is now clickable, providing better visibility into your bot's audience. This improvement makes the web interface more complete and user-friendly.
For developers looking for alternative storage backends, we've introduced the SqliteRepository through the new @fedify/botkit-sqlite package. This provides a production-ready SQLite-based storage solution with ACID compliance, write-ahead logging (WAL) for optimal performance, and proper indexing. Additionally, the new @fedify/botkit/repository module offers MemoryCachedRepository for adding an in-memory cache layer on top of any repository implementation, improving read performance for frequently accessed data.
This release also includes an important security update: we've upgraded to #Fedify 1.8.8, ensuring your bots stay secure and compatible with the latest ActivityPub standards. The repository pattern has been expanded with new interfaces and types like RepositoryGetMessagesOptions, RepositoryGetFollowersOptions, and proper support for polls storage through the KvStoreRepositoryPrefixes.polls option, providing more flexibility for custom implementations.
We're excited to announce the release of BotKit 0.3.0! This release marks a significant milestone as #BotKit now supports #Node.js alongside #Deno, making it accessible to a wider audience. The minimum required Node.js version is 22.0.0. This dual-runtime support means you can now choose your preferred #JavaScript runtime while building #ActivityPub#bots with the same powerful BotKit APIs.
One of the most requested features has landed: poll support! You can now create interactive polls in your #bot messages, allowing followers to vote on questions with single or multiple-choice options. Polls are represented as ActivityPub Question objects with proper expiration times, and your bot can react to votes through the new onVote event handler. This feature enhances engagement possibilities and brings BotKit to feature parity with major #fediverse platforms like Mastodon and Misskey.
The web frontend has been enhanced with a new followers page, thanks to the contribution from Hyeonseo Kim (@gaebalgom)! The /followers route now displays a paginated list of your bot's followers, and the follower count on the main profile page is now clickable, providing better visibility into your bot's audience. This improvement makes the web interface more complete and user-friendly.
For developers looking for alternative storage backends, we've introduced the SqliteRepository through the new @fedify/botkit-sqlite package. This provides a production-ready SQLite-based storage solution with ACID compliance, write-ahead logging (WAL) for optimal performance, and proper indexing. Additionally, the new @fedify/botkit/repository module offers MemoryCachedRepository for adding an in-memory cache layer on top of any repository implementation, improving read performance for frequently accessed data.
This release also includes an important security update: we've upgraded to #Fedify 1.8.8, ensuring your bots stay secure and compatible with the latest ActivityPub standards. The repository pattern has been expanded with new interfaces and types like RepositoryGetMessagesOptions, RepositoryGetFollowersOptions, and proper support for polls storage through the KvStoreRepositoryPrefixes.polls option, providing more flexibility for custom implementations.
We're excited to announce the release of BotKit 0.3.0! This release marks a significant milestone as #BotKit now supports #Node.js alongside #Deno, making it accessible to a wider audience. The minimum required Node.js version is 22.0.0. This dual-runtime support means you can now choose your preferred #JavaScript runtime while building #ActivityPub#bots with the same powerful BotKit APIs.
One of the most requested features has landed: poll support! You can now create interactive polls in your #bot messages, allowing followers to vote on questions with single or multiple-choice options. Polls are represented as ActivityPub Question objects with proper expiration times, and your bot can react to votes through the new onVote event handler. This feature enhances engagement possibilities and brings BotKit to feature parity with major #fediverse platforms like Mastodon and Misskey.
The web frontend has been enhanced with a new followers page, thanks to the contribution from Hyeonseo Kim (@gaebalgom)! The /followers route now displays a paginated list of your bot's followers, and the follower count on the main profile page is now clickable, providing better visibility into your bot's audience. This improvement makes the web interface more complete and user-friendly.
For developers looking for alternative storage backends, we've introduced the SqliteRepository through the new @fedify/botkit-sqlite package. This provides a production-ready SQLite-based storage solution with ACID compliance, write-ahead logging (WAL) for optimal performance, and proper indexing. Additionally, the new @fedify/botkit/repository module offers MemoryCachedRepository for adding an in-memory cache layer on top of any repository implementation, improving read performance for frequently accessed data.
This release also includes an important security update: we've upgraded to #Fedify 1.8.8, ensuring your bots stay secure and compatible with the latest ActivityPub standards. The repository pattern has been expanded with new interfaces and types like RepositoryGetMessagesOptions, RepositoryGetFollowersOptions, and proper support for polls storage through the KvStoreRepositoryPrefixes.polls option, providing more flexibility for custom implementations.
We're excited to announce the release of BotKit 0.3.0! This release marks a significant milestone as #BotKit now supports #Node.js alongside #Deno, making it accessible to a wider audience. The minimum required Node.js version is 22.0.0. This dual-runtime support means you can now choose your preferred #JavaScript runtime while building #ActivityPub#bots with the same powerful BotKit APIs.
One of the most requested features has landed: poll support! You can now create interactive polls in your #bot messages, allowing followers to vote on questions with single or multiple-choice options. Polls are represented as ActivityPub Question objects with proper expiration times, and your bot can react to votes through the new onVote event handler. This feature enhances engagement possibilities and brings BotKit to feature parity with major #fediverse platforms like Mastodon and Misskey.
The web frontend has been enhanced with a new followers page, thanks to the contribution from Hyeonseo Kim (@gaebalgom)! The /followers route now displays a paginated list of your bot's followers, and the follower count on the main profile page is now clickable, providing better visibility into your bot's audience. This improvement makes the web interface more complete and user-friendly.
For developers looking for alternative storage backends, we've introduced the SqliteRepository through the new @fedify/botkit-sqlite package. This provides a production-ready SQLite-based storage solution with ACID compliance, write-ahead logging (WAL) for optimal performance, and proper indexing. Additionally, the new @fedify/botkit/repository module offers MemoryCachedRepository for adding an in-memory cache layer on top of any repository implementation, improving read performance for frequently accessed data.
This release also includes an important security update: we've upgraded to #Fedify 1.8.8, ensuring your bots stay secure and compatible with the latest ActivityPub standards. The repository pattern has been expanded with new interfaces and types like RepositoryGetMessagesOptions, RepositoryGetFollowersOptions, and proper support for polls storage through the KvStoreRepositoryPrefixes.polls option, providing more flexibility for custom implementations.
We're excited to announce the release of BotKit 0.3.0! This release marks a significant milestone as #BotKit now supports #Node.js alongside #Deno, making it accessible to a wider audience. The minimum required Node.js version is 22.0.0. This dual-runtime support means you can now choose your preferred #JavaScript runtime while building #ActivityPub#bots with the same powerful BotKit APIs.
One of the most requested features has landed: poll support! You can now create interactive polls in your #bot messages, allowing followers to vote on questions with single or multiple-choice options. Polls are represented as ActivityPub Question objects with proper expiration times, and your bot can react to votes through the new onVote event handler. This feature enhances engagement possibilities and brings BotKit to feature parity with major #fediverse platforms like Mastodon and Misskey.
The web frontend has been enhanced with a new followers page, thanks to the contribution from Hyeonseo Kim (@gaebalgom)! The /followers route now displays a paginated list of your bot's followers, and the follower count on the main profile page is now clickable, providing better visibility into your bot's audience. This improvement makes the web interface more complete and user-friendly.
For developers looking for alternative storage backends, we've introduced the SqliteRepository through the new @fedify/botkit-sqlite package. This provides a production-ready SQLite-based storage solution with ACID compliance, write-ahead logging (WAL) for optimal performance, and proper indexing. Additionally, the new @fedify/botkit/repository module offers MemoryCachedRepository for adding an in-memory cache layer on top of any repository implementation, improving read performance for frequently accessed data.
This release also includes an important security update: we've upgraded to #Fedify 1.8.8, ensuring your bots stay secure and compatible with the latest ActivityPub standards. The repository pattern has been expanded with new interfaces and types like RepositoryGetMessagesOptions, RepositoryGetFollowersOptions, and proper support for polls storage through the KvStoreRepositoryPrefixes.polls option, providing more flexibility for custom implementations.
We're excited to announce the release of BotKit 0.3.0! This release marks a significant milestone as #BotKit now supports #Node.js alongside #Deno, making it accessible to a wider audience. The minimum required Node.js version is 22.0.0. This dual-runtime support means you can now choose your preferred #JavaScript runtime while building #ActivityPub#bots with the same powerful BotKit APIs.
One of the most requested features has landed: poll support! You can now create interactive polls in your #bot messages, allowing followers to vote on questions with single or multiple-choice options. Polls are represented as ActivityPub Question objects with proper expiration times, and your bot can react to votes through the new onVote event handler. This feature enhances engagement possibilities and brings BotKit to feature parity with major #fediverse platforms like Mastodon and Misskey.
The web frontend has been enhanced with a new followers page, thanks to the contribution from Hyeonseo Kim (@gaebalgom)! The /followers route now displays a paginated list of your bot's followers, and the follower count on the main profile page is now clickable, providing better visibility into your bot's audience. This improvement makes the web interface more complete and user-friendly.
For developers looking for alternative storage backends, we've introduced the SqliteRepository through the new @fedify/botkit-sqlite package. This provides a production-ready SQLite-based storage solution with ACID compliance, write-ahead logging (WAL) for optimal performance, and proper indexing. Additionally, the new @fedify/botkit/repository module offers MemoryCachedRepository for adding an in-memory cache layer on top of any repository implementation, improving read performance for frequently accessed data.
This release also includes an important security update: we've upgraded to #Fedify 1.8.8, ensuring your bots stay secure and compatible with the latest ActivityPub standards. The repository pattern has been expanded with new interfaces and types like RepositoryGetMessagesOptions, RepositoryGetFollowersOptions, and proper support for polls storage through the KvStoreRepositoryPrefixes.polls option, providing more flexibility for custom implementations.
We're excited to announce the release of BotKit 0.3.0! This release marks a significant milestone as #BotKit now supports #Node.js alongside #Deno, making it accessible to a wider audience. The minimum required Node.js version is 22.0.0. This dual-runtime support means you can now choose your preferred #JavaScript runtime while building #ActivityPub#bots with the same powerful BotKit APIs.
One of the most requested features has landed: poll support! You can now create interactive polls in your #bot messages, allowing followers to vote on questions with single or multiple-choice options. Polls are represented as ActivityPub Question objects with proper expiration times, and your bot can react to votes through the new onVote event handler. This feature enhances engagement possibilities and brings BotKit to feature parity with major #fediverse platforms like Mastodon and Misskey.
The web frontend has been enhanced with a new followers page, thanks to the contribution from Hyeonseo Kim (@gaebalgom)! The /followers route now displays a paginated list of your bot's followers, and the follower count on the main profile page is now clickable, providing better visibility into your bot's audience. This improvement makes the web interface more complete and user-friendly.
For developers looking for alternative storage backends, we've introduced the SqliteRepository through the new @fedify/botkit-sqlite package. This provides a production-ready SQLite-based storage solution with ACID compliance, write-ahead logging (WAL) for optimal performance, and proper indexing. Additionally, the new @fedify/botkit/repository module offers MemoryCachedRepository for adding an in-memory cache layer on top of any repository implementation, improving read performance for frequently accessed data.
This release also includes an important security update: we've upgraded to #Fedify 1.8.8, ensuring your bots stay secure and compatible with the latest ActivityPub standards. The repository pattern has been expanded with new interfaces and types like RepositoryGetMessagesOptions, RepositoryGetFollowersOptions, and proper support for polls storage through the KvStoreRepositoryPrefixes.polls option, providing more flexibility for custom implementations.
We're excited to announce the release of BotKit 0.3.0! This release marks a significant milestone as #BotKit now supports #Node.js alongside #Deno, making it accessible to a wider audience. The minimum required Node.js version is 22.0.0. This dual-runtime support means you can now choose your preferred #JavaScript runtime while building #ActivityPub#bots with the same powerful BotKit APIs.
One of the most requested features has landed: poll support! You can now create interactive polls in your #bot messages, allowing followers to vote on questions with single or multiple-choice options. Polls are represented as ActivityPub Question objects with proper expiration times, and your bot can react to votes through the new onVote event handler. This feature enhances engagement possibilities and brings BotKit to feature parity with major #fediverse platforms like Mastodon and Misskey.
The web frontend has been enhanced with a new followers page, thanks to the contribution from Hyeonseo Kim (@gaebalgom)! The /followers route now displays a paginated list of your bot's followers, and the follower count on the main profile page is now clickable, providing better visibility into your bot's audience. This improvement makes the web interface more complete and user-friendly.
For developers looking for alternative storage backends, we've introduced the SqliteRepository through the new @fedify/botkit-sqlite package. This provides a production-ready SQLite-based storage solution with ACID compliance, write-ahead logging (WAL) for optimal performance, and proper indexing. Additionally, the new @fedify/botkit/repository module offers MemoryCachedRepository for adding an in-memory cache layer on top of any repository implementation, improving read performance for frequently accessed data.
This release also includes an important security update: we've upgraded to #Fedify 1.8.8, ensuring your bots stay secure and compatible with the latest ActivityPub standards. The repository pattern has been expanded with new interfaces and types like RepositoryGetMessagesOptions, RepositoryGetFollowersOptions, and proper support for polls storage through the KvStoreRepositoryPrefixes.polls option, providing more flexibility for custom implementations.
Fedify is an #ActivityPub server framework in #TypeScript & #JavaScript. It aims to eliminate the complexity and redundant boilerplate code when building a federated server app, so that you can focus on your business logic and user experience.
The key features it provides currently are:
Type-safe objects for Activity Vocabulary (including some vendor-specific extensions)
A simple, cross-runtime email library that works seamlessly on #Deno, #Node.js, #Bun, and edge functions. Zero dependencies, unified API, and excellent testability with built-in mock transport.
A simple, cross-runtime email library that works seamlessly on #Deno, #Node.js, #Bun, and edge functions. Zero dependencies, unified API, and excellent testability with built-in mock transport.
A simple, cross-runtime email library that works seamlessly on #Deno, #Node.js, #Bun, and edge functions. Zero dependencies, unified API, and excellent testability with built-in mock transport.
A simple, cross-runtime email library that works seamlessly on #Deno, #Node.js, #Bun, and edge functions. Zero dependencies, unified API, and excellent testability with built-in mock transport.
A simple, cross-runtime email library that works seamlessly on #Deno, #Node.js, #Bun, and edge functions. Zero dependencies, unified API, and excellent testability with built-in mock transport.
A simple, cross-runtime email library that works seamlessly on #Deno, #Node.js, #Bun, and edge functions. Zero dependencies, unified API, and excellent testability with built-in mock transport.
A simple, cross-runtime email library that works seamlessly on #Deno, #Node.js, #Bun, and edge functions. Zero dependencies, unified API, and excellent testability with built-in mock transport.
A simple, cross-runtime email library that works seamlessly on #Deno, #Node.js, #Bun, and edge functions. Zero dependencies, unified API, and excellent testability with built-in mock transport.
A simple, cross-runtime email library that works seamlessly on #Deno, #Node.js, #Bun, and edge functions. Zero dependencies, unified API, and excellent testability with built-in mock transport.
A simple, cross-runtime email library that works seamlessly on #Deno, #Node.js, #Bun, and edge functions. Zero dependencies, unified API, and excellent testability with built-in mock transport.
A simple, cross-runtime email library that works seamlessly on #Deno, #Node.js, #Bun, and edge functions. Zero dependencies, unified API, and excellent testability with built-in mock transport.
A simple, cross-runtime email library that works seamlessly on #Deno, #Node.js, #Bun, and edge functions. Zero dependencies, unified API, and excellent testability with built-in mock transport.
Ω🪬Ω new release of #Fedialgo, the customizable timeline algorithm / filtering system for your Mastodon feed, counts the number of times each hashtag appears in your timeline even if people don't use a "#" character to give you a better sense of what people are talking about in the Fediverse.
there's a little bit of art vs. science here because some strings are disqualified from this kind of counting (e.g. a word like "the" should not be counted even if some maniac decided to make it a hashtag) so let me know if you see any weirdly high counts.
Ω🪬Ω new release of #Fedialgo, the customizable timeline algorithm / filtering system for your Mastodon feed, counts the number of times each hashtag appears in your timeline even if people don't use a "#" character to give you a better sense of what people are talking about in the Fediverse.
there's a little bit of art vs. science here because some strings are disqualified from this kind of counting (e.g. a word like "the" should not be counted even if some maniac decided to make it a hashtag) so let me know if you see any weirdly high counts.
Ω🪬Ω new release of #Fedialgo, the customizable timeline algorithm / filtering system for your Mastodon feed, counts the number of times each hashtag appears in your timeline even if people don't use a "#" character to give you a better sense of what people are talking about in the Fediverse.
there's a little bit of art vs. science here because some strings are disqualified from this kind of counting (e.g. a word like "the" should not be counted even if some maniac decided to make it a hashtag) so let me know if you see any weirdly high counts.
The fine @michael has deployed the #FediAlgo demo app to a place where you can test out the customizable algorithm + filtering system for your home timeline with nothing more than a web browser. You can find it here:
The fine @michael has deployed the #FediAlgo demo app to a place where you can test out the customizable algorithm + filtering system for your home timeline with nothing more than a web browser. You can find it here:
The fine @michael has deployed the #FediAlgo demo app to a place where you can test out the customizable algorithm + filtering system for your home timeline with nothing more than a web browser. You can find it here:
The fine @michael has deployed the #FediAlgo demo app to a place where you can test out the customizable algorithm + filtering system for your home timeline with nothing more than a web browser. You can find it here:
The FediAlgo hashtag filter section now highlights any hashtags you've posted about recently.
Interestingly the most I've used the app the more I've found feed filtering gets a ton of mileage for me. It's a huge change of pace to be able to instantly flip between whatever people are talking about on the Fediverse. Not really something you can do on any other social media platform I'm aware of.
The FediAlgo hashtag filter section now highlights any hashtags you've posted about recently.
Interestingly the most I've used the app the more I've found feed filtering gets a ton of mileage for me. It's a huge change of pace to be able to instantly flip between whatever people are talking about on the Fediverse. Not really something you can do on any other social media platform I'm aware of.
Ω🪬Ω New release of #FediAlgo (customizable #algorithm for your #Mastodon timeline) has a couple of cool features:
1. Configuration presets (so you can easily put discussions or trending toots at the top of your #timeline without fiddling with the individual settings)
2. A "What's Trending" section that will show you the top trending hashtags, links, and posts scraped from 30 or so of the most popular Mastodon servers
All the old features like filtering for particular languages / hashtags / users or a minimum number of replies / boosts / etc. are still there.
Ω🪬Ω New release of #FediAlgo (customizable #algorithm for your #Mastodon timeline) has a couple of cool features:
1. Configuration presets (so you can easily put discussions or trending toots at the top of your #timeline without fiddling with the individual settings)
2. A "What's Trending" section that will show you the top trending hashtags, links, and posts scraped from 30 or so of the most popular Mastodon servers
All the old features like filtering for particular languages / hashtags / users or a minimum number of replies / boosts / etc. are still there.
Ω🪬Ω New release of #FediAlgo (customizable #algorithm for your #Mastodon timeline) has a couple of cool features:
1. Configuration presets (so you can easily put discussions or trending toots at the top of your #timeline without fiddling with the individual settings)
2. A "What's Trending" section that will show you the top trending hashtags, links, and posts scraped from 30 or so of the most popular Mastodon servers
All the old features like filtering for particular languages / hashtags / users or a minimum number of replies / boosts / etc. are still there.
Ω🪬Ω New release of #FediAlgo (customizable #algorithm for your #Mastodon timeline) has a couple of cool features:
1. Configuration presets (so you can easily put discussions or trending toots at the top of your #timeline without fiddling with the individual settings)
2. A "What's Trending" section that will show you the top trending hashtags, links, and posts scraped from 30 or so of the most popular Mastodon servers
All the old features like filtering for particular languages / hashtags / users or a minimum number of replies / boosts / etc. are still there.
Another library frustration: is there a standard Make-like task runner tool for #Node? 10 years ago Grunt and Gulp were standard for this, but they're horribly out of date now and not compatible with ES6 imports. There are tools in other languages, like go-task, but I can't find anything similar in JS.
Fedify is an #ActivityPub server framework in #TypeScript & #JavaScript. It aims to eliminate the complexity and redundant boilerplate code when building a federated server app, so that you can focus on your business logic and user experience.
The key features it provides currently are:
Type-safe objects for Activity Vocabulary (including some vendor-specific extensions)
I've worked with dates and times in several programming languages, and I have to say that the best is easily PHP (since the big refactor in, what was it, 5.6?).
I've worked with dates and times in several programming languages, and I have to say that the best is easily PHP (since the big refactor in, what was it, 5.6?).
@adingbatponder@fosstodon.org · Reply to Shadow Heart
@Sh4d0w_H34rt@bunbloc Oh, sorry, was not clear. I was thinking of a #mastodon instance solely over #reticulum using #LXMF and not via any other protocol, to make it a bit special and to provide superb chat rooms or group chats and fill that current gap. #reticulum allows for images of course. Would work very well indeed perhaps. Was wondering how much code would need changing to #mastodon to port it to a #reticulum#node#nomad server ...
Fedify is an #ActivityPub server framework in #TypeScript & #JavaScript. It aims to eliminate the complexity and redundant boilerplate code when building a federated server app, so that you can focus on your business logic and user experience.
The key features it provides currently are:
Type-safe objects for Activity Vocabulary (including some vendor-specific extensions)
Fedify is an #ActivityPub server framework in #TypeScript & #JavaScript. It aims to eliminate the complexity and redundant boilerplate code when building a federated server app, so that you can focus on your business logic and user experience.
The key features it provides currently are:
Type-safe objects for Activity Vocabulary (including some vendor-specific extensions)
- Correct handling of compilerOptions.types - Better handling of npm package types - Improvements to node:fs FileHandle - Make deno outdated more robust Run `deno upgrade` to get it
- Correct handling of compilerOptions.types - Better handling of npm package types - Improvements to node:fs FileHandle - Make deno outdated more robust Run `deno upgrade` to get it
- Correct handling of compilerOptions.types - Better handling of npm package types - Improvements to node:fs FileHandle - Make deno outdated more robust Run `deno upgrade` to get it
- Correct handling of compilerOptions.types - Better handling of npm package types - Improvements to node:fs FileHandle - Make deno outdated more robust Run `deno upgrade` to get it
Deno is committed to web standards - that's why we co-founded WinterCG two years ago. Today marks the next step in that journey: WinterCG moves to Ecma International as technical comittee 55 (TC55).
Deno is committed to web standards - that's why we co-founded WinterCG two years ago. Today marks the next step in that journey: WinterCG moves to Ecma International as technical comittee 55 (TC55).
Deno is committed to web standards - that's why we co-founded WinterCG two years ago. Today marks the next step in that journey: WinterCG moves to Ecma International as technical comittee 55 (TC55).
Deno is committed to web standards - that's why we co-founded WinterCG two years ago. Today marks the next step in that journey: WinterCG moves to Ecma International as technical comittee 55 (TC55).
I'm troubleshooting a mysterious TypeError: fetch failed exception when using #Node.js's built-in fetch() function. When I make the same request in #Deno or #Bun, it responds fine. Anyone know why this only happens in Node.js?
Welcome to Bun v1.1.42
Type ".help" for more information.
[!] Please note that the REPL implementation is still experimental!
Don't consider it to be representative of the stability or behavior of Bun overall.
> await fetch("https://social.zarchbox.fr/notes/a2dn3k8kt5hm3gci");
Response {}
>
ALT text
Welcome to Node.js v23.5.0.
Type ".help" for more information.
> await fetch("https://social.zarchbox.fr/notes/a2dn3k8kt5hm3gci");
Uncaught TypeError: fetch failed
at node:internal/deps/undici/undici:13484:13
at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
at async REPL1:1:33 {
[cause]: AggregateError [ETIMEDOUT]:
at internalConnectMultiple (node:net:1139:18)
at internalConnectMultiple (node:net:1215:5)
at Timeout.internalConnectMultipleTimeout (node:net:1739:5)
at listOnTimeout (node:internal/timers:616:11)
at process.processTimers (node:internal/timers:549:7) {
code: 'ETIMEDOUT',
[errors]: [ [Error], [Error] ]
}
}
>
Okay, testing #Hollo with #Node.js is cruising along. It's consuming up to 3 GB of memory at peak times, but that's a huge improvement over Hollo with #Bun, which was consuming over 8 GB of memory at peak times.
So, yes, starting with Hollo 0.4.0, we'll use Node.js instead of Bun!
ALT text
Memory usage chart for the hollo.social server. You can see that before December 18th, the point at which we switched to Node.js, the memory usage fluctuated between 1 GB and 8 GB, but since then, it's been mostly stable around 1 GB. It did spike to 3 GB at peak times, but only briefly during the entire test period.
#Hollo is currently testing #Node.js instead of #Bun. (In fact, the hollo.social server is already running on Node.js!) If this test is successful, starting with the next release, Hollo will be powered by Node.js instead of Bun.
The main reason for switching to Node.js is to optimize memory usage. As you can see in the graph image below, Node.js uses significantly less memory than Bun. With this switch, Hollo is expected to be even more lightweight than before!
We’ve submitted a formal petition to cancel the JavaScript trademark: it is generic, Oracle has abandoned it, and Oracle committed fraud on the USPTO during the last trademark renewal.
Oracle has until January 4th to respond, or the case will go into default, which will result in the trademark being canceled.
Ω⚠️🐘⚠️Ω I did some hacking at @pkreissel's implementation of a customizable algorithm for your Mastodon feed. I fixed some bugs and added a few features but maybe most importantly I streamlined the process of installing and running the demo app so you can experience the magic of his invention reshaping your Mastodon timeline for yourself with ease.
Seriously everything about having an algorithm adjust my feed to make sure I see stuff I might otherwise have missed has made my Mastodon experience like 1,000x better. The fact that it's (extremely) granularly customizable is the icing on the cake.
Setup should be trivial for anyone vaguely familiar with the command line. Even if you're scared of the command line you should be able to copy/paste the 3 commands listed in the installation instructions, all of which are in the GitHub repo:
According to the docs in the Sentry SDK, OpenTelemetry integration is out of the box and doesn't require any configuration, but Spans instrumented using the OpenTelemetry API are ignored. Spans made with the Sentry API are working fine.
If you've been avoiding #JavaScript & #TypeScript due to the complexity of the #Node.js ecosystem, give #Deno a try. Everything is simplified and you can start coding right away without having to set up a development environment.
‣ Add `process` global variable, remove `window` ‣ Improve dep management ‣ Permission system updates ‣ Many stabilizations ‣ Better CommonJS support ‣ Test documentation with `deno test --doc`
#Fedify started out exclusively for #Deno, but now also supports #Node.js and #Bun. However, the #logo we created in the early days still features the character from Deno. Should Fedify change its logo now?
#Fedify is built in #Deno for ease of development, but it also supports #Node.js and #Bun using #dnt. Deno's DX is so good that I don't regret this decision, and I'm looking forward to Deno 2.0 as well.
Version 0.5.0 of #LogTape, the zero-dependency #logging library for #Deno, #Node.js, #Bun, edge functions, and browsers, has been released! The main additions include:
• Contexts • ANSI color formatter • Comprehensive docs • A few API conveniences
Hosting on Deno Deploy just got more performant with beta Web Cache API support: 🚀 sub-millisecond read latency 🚅 multi Gbps write throughput 💾 unbounded storage
Deno 1.46 is not only the last 1.x release, but also one of the biggest: - Simpler CLI - Multi-threaded web servers - HTML, CSS, YAML support in `deno fmt` - Better Node/npm compat (support for playwright, google-cloud, etc.) and much more 👇️
#LogTape is a logging library for #JavaScript and #TypeScript. It provides a simple and flexible logging system that is easy to use and easy to extend. The highlights of LogTape are:
• Zero dependencies • Designed to be used in libraries as well as apps • Supports virtually every runtime: #Node.js, #Deno, #Bun, edge functions, and browsers • Structured logging • Logger categories (names) are hierarchical • Dead simple sink (destination) interface
I'm unsure whether to adopt an emerging JavaScript runtime like #Bun or #Deno for #Fedify's tutorial, or stick with traditional #Node.js. 🤔
If I choose Bun/Deno, it comes with built-in #TypeScript support, hot reloading, and a fetch-style HTTP server, so I don't have to explain much about it, but I need to deal with installing Bun/Deno itself.
On the other hand, Node.js can be assumed to be already installed on the reader's system, but they will need to set up TypeScript, hot reloading, etc.
#Deno and #Bun people are putting an incredible amount of work modernizing server side js.
The energy is reminding me of early day #Python - so many new tools made with proper care behind rather than most of NodeJS ecosystem which is just glued together with band-aids and staples :blobcatgrimacing:
That being said, after working with Deno for the past week it still feels a bit too bleeding edge though it does work with #jupyter!
I find myself in that uncomfortable situation like many others who work in tech lately, and will be looking at a layoff in the next few months. If anyone is aware of cool jobs in Germany, probably remote-first, working with #Go (or even #rustlang#python#node ) please reach out. I have ~9 years of backend experience and consider myself someone who gets shit done. #fedihire
I'm a backend #node developer in #vancouver, I've been running #vrchat 's backend (badly) since about 2016 (when it was just me). Now it's loads more people!
#LogTape is a logging library for #JavaScript and #TypeScript. It provides a simple and flexible logging system that is easy to use and easy to extend. The highlights of LogTape are:
• Zero dependencies • Designed to be used in libraries as well as apps • Supports virtually every runtime: #Node.js, #Deno, #Bun, edge functions, and browsers • Structured logging • Logger categories (names) are hierarchical • Dead simple sink (destination) interface
Thanks to @kitsonk, #LogTape's bug where it failed to load under #Node.js when incorporated in a project from #JSR was fixed! The fix is now available at LogTape 0.4.1.
#Fedify is an #ActivityPub server framework in #TypeScript & #JavaScript. It aims to eliminate the complexity and redundant boilerplate code when building a federated server app, so that you can focus on your business logic and user experience.
The key features it provides currently are:
• Type-safe objects for Activity Vocabulary (including some vendor-specific extensions) • #WebFinger client and server • HTTP Signatures • Middleware for handling webhooks • #NodeInfo protocol • #Node.js, #Deno, and #Bun support • CLI toolchain for testing and debugging
If you're curious, take a look at the Fedify website! There's comprehensive docs, a demo, a tutorial, example code, and more:
#Fedify has supported optional queuing for outgoing activities, with two built-in message queue backends: InProcessMessageQueue, which is suitable for development, and DenoKvMessageQueue, which is only available in Deno.
Fedify has also had two built-in cache backends, MemoryKvStore, which is suitable for development, and DenoKvStore, which is only available in Deno.
Now, however, by installing the @fedify/redis package, you can use #Redis as both a message queue backend and a cache backend! Unlike DenoKvMessageQueue and DenoKvStore, it's also available for #Node.js and #Bun.
This feature was made possible with the support of @ghost.
Fedify is an #ActivityPub server framework in #TypeScript & #JavaScript. It aims to eliminate the complexity and redundant boilerplate code when building a federated server app, so that you can focus on your business logic and user experience.
The key features it provides currently are:
Type-safe objects for Activity Vocabulary (including some vendor-specific extensions)
![Welcome to Bun v1.1.42
Type ".help" for more information.
[!] Please note that the REPL implementation is still experimental!
Don't consider it to be representative of the stability or behavior of Bun overall.
> await fetch("https://social.zarchbox.fr/notes/a2dn3k8kt5hm3gci");
Response {}
>](https://media.social.fedify.dev/media/0194184f-62bb-7468-9bd6-213301cd830e/original.png)
![Welcome to Node.js v23.5.0.
Type ".help" for more information.
> await fetch("https://social.zarchbox.fr/notes/a2dn3k8kt5hm3gci");
Uncaught TypeError: fetch failed
at node:internal/deps/undici/undici:13484:13
at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
at async REPL1:1:33 {
[cause]: AggregateError [ETIMEDOUT]:
at internalConnectMultiple (node:net:1139:18)
at internalConnectMultiple (node:net:1215:5)
at Timeout.internalConnectMultipleTimeout (node:net:1739:5)
at listOnTimeout (node:internal/timers:616:11)
at process.processTimers (node:internal/timers:549:7) {
code: 'ETIMEDOUT',
[errors]: [ [Error], [Error] ]
}
}
>](https://media.social.fedify.dev/media/01941850-da6a-7e93-acc0-1a1b6f54dde0/original.png)
