Bart Louwers
@bart@floss.social · Reply to Bart Louwers's post
Got a #Bun segfault.
Good to see that some things haven't changed.
@bart@floss.social · Reply to Bart Louwers's post
Got a #Bun segfault.
Good to see that some things haven't changed.
@chris@nutmeg.social
Bun was bought by Anthropic. For #web devs, it's now:
#Node - OpenJS (non-profit)
vs
#Deno - Deno Land Inc (for-profit)
vs
#Bun - Anthropic (for-profit valued at $350 billion)
https://www.anthropic.com/news/anthropic-acquires-bun-as-claude-code-reaches-usd1b-milestone

@hollo@hollo.social
Introducing #Hollo. Hollo is an #ActivityPub-enabled single-user microblogging software. Although it's for a single user, it also supports creating and running multiple accounts for different topics.
It's headless, meaning you can use existing #Mastodon client apps instead, with its Mastodon-compatible APIs. It has most feature parity with Mastodon. Two big differences with Mastodon is that you can use #Markdown in the content of your posts and you can quote another post.
Oh, and Hollo is built using #Bun and #Fedify.

@hollo@hollo.social
Introducing #Hollo. Hollo is an #ActivityPub-enabled single-user microblogging software. Although it's for a single user, it also supports creating and running multiple accounts for different topics.
It's headless, meaning you can use existing #Mastodon client apps instead, with its Mastodon-compatible APIs. It has most feature parity with Mastodon. Two big differences with Mastodon is that you can use #Markdown in the content of your posts and you can quote another post.
Oh, and Hollo is built using #Bun and #Fedify.
@fedify@hollo.social
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:
If you're curious, take a look at the #Fedify website! There's comprehensive docs, a demo, a tutorial, example code, and more:
@fedify@hollo.social
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!
@fedify@hollo.social
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!
@fedify@hollo.social
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!
@fedify@hollo.social
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!
@fedify@hollo.social
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!
@fedify@hollo.social
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!
@fedify@hollo.social
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!
@fedify@hollo.social
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!
@fedify@hollo.social
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!
@fedify@hollo.social
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!
@fedify@hollo.social
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!
@fedify@hollo.social
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!
@fedify@hollo.social
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!

@hongminhee@hollo.social
Big update for our type-safe combinatorial #CLI parser for #TypeScript:
showDefault: automatic default value displayThe help text has never looked this good!
@hongminhee@hackers.pub
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.
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.
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 scattered
const config = merge(connectionOptions, performanceOptions);
// Now: group related options under a clear section
const 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 groups
Usage: demo-merge.ts --host STRING --port INTEGER --timeout INTEGER --retries
INTEGER
Server 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
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 section
const 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 combinator
Usage: demo-group.ts --json
demo-group.ts --yaml
demo-group.ts --xml
Output Format:
--json Output in JSON format
--yaml Output in YAML format
--xml Output in XML format
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.
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 --strict
For 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 tool
Usage: demo-rich-docs.ts [--port INTEGER] [--format STRING] --verbose STRING
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.
--port INTEGER Server port number [3000]
--format STRING Output format [json]
--verbose STRING Verbosity level
Examples:
myapp process data.json --format yaml
myapp validate config.toml --strict
For 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.
A frequently requested feature is now available: showing default values
directly in help text. Enable this with the new showDefault option when
using withDefault():
const parser = object({
port: withDefault(
option("--port", integer(), { description: message`Server port number` }),
3000,
),
format: withDefault(
option("--format", string(), { description: message`Output format` }),
"json",
),
});
run(parser, { showDefault: true });
// Or with custom formatting:
run(parser, {
showDefault: {
prefix: " (default: ",
suffix: ")"
} // Shows: --port (default: 3000)
});
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]
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:
const result = parse(timestampArg, ["2023-12-25T10:30:00Z"]);
if (result.success) {
const instant = result.value;
console.log(`UTC: ${instant.toString()}`);
console.log(`Seoul: ${instant.toZonedDateTimeISO("Asia/Seoul")}`);
}
Install the new package with:
npm add @optique/temporal
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.
While we've maintained backward compatibility for most APIs, there are a few changes to be aware of:
Parser.getDocFragments() method now uses DocState<TState> instead
of direct state values (only affects custom parser implementations)merge() combinator now enforces stricter type
constraints at compile time, rejecting non-object-producing parsersFor a complete list of changes, bug fixes, and improvements, see the full changelog.
Check out the updated documentation:
merge() and group() usageUpgrade to Optique 0.4.0:
npm update @optique/core @optique/run
# or
deno add jsr:@optique/core@^0.4.0 jsr:@optique/run@^0.4.0
Add temporal support (optional):
npm add @optique/temporal
# or
deno add jsr:@optique/temporal
We hope these improvements make building CLI applications with Optique even more enjoyable. As always, we welcome your feedback and contributions on GitHub.

@hongminhee@hollo.social
Big update for our type-safe combinatorial #CLI parser for #TypeScript:
showDefault: automatic default value displayThe help text has never looked this good!
@hongminhee@hackers.pub
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.
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.
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 scattered
const config = merge(connectionOptions, performanceOptions);
// Now: group related options under a clear section
const 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 groups
Usage: demo-merge.ts --host STRING --port INTEGER --timeout INTEGER --retries
INTEGER
Server 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
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 section
const 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 combinator
Usage: demo-group.ts --json
demo-group.ts --yaml
demo-group.ts --xml
Output Format:
--json Output in JSON format
--yaml Output in YAML format
--xml Output in XML format
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.
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 --strict
For 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 tool
Usage: demo-rich-docs.ts [--port INTEGER] [--format STRING] --verbose STRING
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.
--port INTEGER Server port number [3000]
--format STRING Output format [json]
--verbose STRING Verbosity level
Examples:
myapp process data.json --format yaml
myapp validate config.toml --strict
For 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.
A frequently requested feature is now available: showing default values
directly in help text. Enable this with the new showDefault option when
using withDefault():
const parser = object({
port: withDefault(
option("--port", integer(), { description: message`Server port number` }),
3000,
),
format: withDefault(
option("--format", string(), { description: message`Output format` }),
"json",
),
});
run(parser, { showDefault: true });
// Or with custom formatting:
run(parser, {
showDefault: {
prefix: " (default: ",
suffix: ")"
} // Shows: --port (default: 3000)
});
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]
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:
const result = parse(timestampArg, ["2023-12-25T10:30:00Z"]);
if (result.success) {
const instant = result.value;
console.log(`UTC: ${instant.toString()}`);
console.log(`Seoul: ${instant.toZonedDateTimeISO("Asia/Seoul")}`);
}
Install the new package with:
npm add @optique/temporal
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.
While we've maintained backward compatibility for most APIs, there are a few changes to be aware of:
Parser.getDocFragments() method now uses DocState<TState> instead
of direct state values (only affects custom parser implementations)merge() combinator now enforces stricter type
constraints at compile time, rejecting non-object-producing parsersFor a complete list of changes, bug fixes, and improvements, see the full changelog.
Check out the updated documentation:
merge() and group() usageUpgrade to Optique 0.4.0:
npm update @optique/core @optique/run
# or
deno add jsr:@optique/core@^0.4.0 jsr:@optique/run@^0.4.0
Add temporal support (optional):
npm add @optique/temporal
# or
deno add jsr:@optique/temporal
We hope these improvements make building CLI applications with Optique even more enjoyable. As always, we welcome your feedback and contributions on GitHub.

@hongminhee@hollo.social
Big update for our type-safe combinatorial #CLI parser for #TypeScript:
showDefault: automatic default value displayThe help text has never looked this good!
@hongminhee@hackers.pub
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.
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.
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 scattered
const config = merge(connectionOptions, performanceOptions);
// Now: group related options under a clear section
const 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 groups
Usage: demo-merge.ts --host STRING --port INTEGER --timeout INTEGER --retries
INTEGER
Server 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
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 section
const 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 combinator
Usage: demo-group.ts --json
demo-group.ts --yaml
demo-group.ts --xml
Output Format:
--json Output in JSON format
--yaml Output in YAML format
--xml Output in XML format
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.
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 --strict
For 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 tool
Usage: demo-rich-docs.ts [--port INTEGER] [--format STRING] --verbose STRING
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.
--port INTEGER Server port number [3000]
--format STRING Output format [json]
--verbose STRING Verbosity level
Examples:
myapp process data.json --format yaml
myapp validate config.toml --strict
For 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.
A frequently requested feature is now available: showing default values
directly in help text. Enable this with the new showDefault option when
using withDefault():
const parser = object({
port: withDefault(
option("--port", integer(), { description: message`Server port number` }),
3000,
),
format: withDefault(
option("--format", string(), { description: message`Output format` }),
"json",
),
});
run(parser, { showDefault: true });
// Or with custom formatting:
run(parser, {
showDefault: {
prefix: " (default: ",
suffix: ")"
} // Shows: --port (default: 3000)
});
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]
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:
const result = parse(timestampArg, ["2023-12-25T10:30:00Z"]);
if (result.success) {
const instant = result.value;
console.log(`UTC: ${instant.toString()}`);
console.log(`Seoul: ${instant.toZonedDateTimeISO("Asia/Seoul")}`);
}
Install the new package with:
npm add @optique/temporal
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.
While we've maintained backward compatibility for most APIs, there are a few changes to be aware of:
Parser.getDocFragments() method now uses DocState<TState> instead
of direct state values (only affects custom parser implementations)merge() combinator now enforces stricter type
constraints at compile time, rejecting non-object-producing parsersFor a complete list of changes, bug fixes, and improvements, see the full changelog.
Check out the updated documentation:
merge() and group() usageUpgrade to Optique 0.4.0:
npm update @optique/core @optique/run
# or
deno add jsr:@optique/core@^0.4.0 jsr:@optique/run@^0.4.0
Add temporal support (optional):
npm add @optique/temporal
# or
deno add jsr:@optique/temporal
We hope these improvements make building CLI applications with Optique even more enjoyable. As always, we welcome your feedback and contributions on GitHub.

@hollo@hollo.social
Introducing #Hollo. Hollo is an #ActivityPub-enabled single-user microblogging software. Although it's for a single user, it also supports creating and running multiple accounts for different topics.
It's headless, meaning you can use existing #Mastodon client apps instead, with its Mastodon-compatible APIs. It has most feature parity with Mastodon. Two big differences with Mastodon is that you can use #Markdown in the content of your posts and you can quote another post.
Oh, and Hollo is built using #Bun and #Fedify.
@fedify@hollo.social
We'd like to recognize some excellent contributions from our #OSSCA (Open Source Contribution Academy) participants who have been working on #Fedify.
@gaebalgom contributed PR #339, which introduces the @fedify/elysia package to provide Elysia integration for Fedify. This work addresses issue #286 by creating a plugin that enables developers using #Bun and #Elysia to integrate Fedify's #ActivityPub capabilities into their applications. The contribution includes the core integration module, documentation, examples, and proper monorepo configuration, making Fedify accessible to the Elysia community.
@r4bb1t submitted PR #315, implementing comprehensive AbortSignal support across multiple APIs to resolve issue #51. This contribution adds request cancellation capabilities not only to lookupWebFinger() but also to lookupObject(), DocumentLoader, and the HTTP signature authentication flow (doubleKnock()), allowing developers to properly handle timeouts and abort ongoing requests throughout the entire request chain. The implementation includes extensive test coverage for cancellation scenarios across all affected components and lays the groundwork for adding --timeout options to various CLI commands like fedify lookup, fedify webfinger, and fedify nodeinfo, making federated applications more robust and responsive.
@ooheunda addressed a testing infrastructure issue with PR #350, fixing a race condition in PostgreSQL message queue tests that was causing intermittent failures (issue #346). By adding explicit initialization before concurrent message queue listeners, this fix prevents table creation conflicts that were affecting test reliability, ensuring more consistent PR testing for all contributors.
@songbirds provided two test stability improvements with PR #344 and PR #347. The first PR adds skip guards to RedisKvStore tests as a workaround for a known Bun runtime issue, keeping the test suite functional while awaiting an upstream fix. The second PR resolves a race condition in the code generation process by randomizing output filenames, preventing conflicts during parallel test execution. These contributions help maintain a stable testing environment for the project.
Thank you all for your contributions to Fedify. Your work helps make federated social networking more accessible to developers.
@fedify@hollo.social
We'd like to recognize some excellent contributions from our #OSSCA (Open Source Contribution Academy) participants who have been working on #Fedify.
@gaebalgom contributed PR #339, which introduces the @fedify/elysia package to provide Elysia integration for Fedify. This work addresses issue #286 by creating a plugin that enables developers using #Bun and #Elysia to integrate Fedify's #ActivityPub capabilities into their applications. The contribution includes the core integration module, documentation, examples, and proper monorepo configuration, making Fedify accessible to the Elysia community.
@r4bb1t submitted PR #315, implementing comprehensive AbortSignal support across multiple APIs to resolve issue #51. This contribution adds request cancellation capabilities not only to lookupWebFinger() but also to lookupObject(), DocumentLoader, and the HTTP signature authentication flow (doubleKnock()), allowing developers to properly handle timeouts and abort ongoing requests throughout the entire request chain. The implementation includes extensive test coverage for cancellation scenarios across all affected components and lays the groundwork for adding --timeout options to various CLI commands like fedify lookup, fedify webfinger, and fedify nodeinfo, making federated applications more robust and responsive.
@ooheunda addressed a testing infrastructure issue with PR #350, fixing a race condition in PostgreSQL message queue tests that was causing intermittent failures (issue #346). By adding explicit initialization before concurrent message queue listeners, this fix prevents table creation conflicts that were affecting test reliability, ensuring more consistent PR testing for all contributors.
@songbirds provided two test stability improvements with PR #344 and PR #347. The first PR adds skip guards to RedisKvStore tests as a workaround for a known Bun runtime issue, keeping the test suite functional while awaiting an upstream fix. The second PR resolves a race condition in the code generation process by randomizing output filenames, preventing conflicts during parallel test execution. These contributions help maintain a stable testing environment for the project.
Thank you all for your contributions to Fedify. Your work helps make federated social networking more accessible to developers.
@fedify@hollo.social
We'd like to recognize some excellent contributions from our #OSSCA (Open Source Contribution Academy) participants who have been working on #Fedify.
@gaebalgom contributed PR #339, which introduces the @fedify/elysia package to provide Elysia integration for Fedify. This work addresses issue #286 by creating a plugin that enables developers using #Bun and #Elysia to integrate Fedify's #ActivityPub capabilities into their applications. The contribution includes the core integration module, documentation, examples, and proper monorepo configuration, making Fedify accessible to the Elysia community.
@r4bb1t submitted PR #315, implementing comprehensive AbortSignal support across multiple APIs to resolve issue #51. This contribution adds request cancellation capabilities not only to lookupWebFinger() but also to lookupObject(), DocumentLoader, and the HTTP signature authentication flow (doubleKnock()), allowing developers to properly handle timeouts and abort ongoing requests throughout the entire request chain. The implementation includes extensive test coverage for cancellation scenarios across all affected components and lays the groundwork for adding --timeout options to various CLI commands like fedify lookup, fedify webfinger, and fedify nodeinfo, making federated applications more robust and responsive.
@ooheunda addressed a testing infrastructure issue with PR #350, fixing a race condition in PostgreSQL message queue tests that was causing intermittent failures (issue #346). By adding explicit initialization before concurrent message queue listeners, this fix prevents table creation conflicts that were affecting test reliability, ensuring more consistent PR testing for all contributors.
@songbirds provided two test stability improvements with PR #344 and PR #347. The first PR adds skip guards to RedisKvStore tests as a workaround for a known Bun runtime issue, keeping the test suite functional while awaiting an upstream fix. The second PR resolves a race condition in the code generation process by randomizing output filenames, preventing conflicts during parallel test execution. These contributions help maintain a stable testing environment for the project.
Thank you all for your contributions to Fedify. Your work helps make federated social networking more accessible to developers.
@fedify@hollo.social
We'd like to recognize some excellent contributions from our #OSSCA (Open Source Contribution Academy) participants who have been working on #Fedify.
@gaebalgom contributed PR #339, which introduces the @fedify/elysia package to provide Elysia integration for Fedify. This work addresses issue #286 by creating a plugin that enables developers using #Bun and #Elysia to integrate Fedify's #ActivityPub capabilities into their applications. The contribution includes the core integration module, documentation, examples, and proper monorepo configuration, making Fedify accessible to the Elysia community.
@r4bb1t submitted PR #315, implementing comprehensive AbortSignal support across multiple APIs to resolve issue #51. This contribution adds request cancellation capabilities not only to lookupWebFinger() but also to lookupObject(), DocumentLoader, and the HTTP signature authentication flow (doubleKnock()), allowing developers to properly handle timeouts and abort ongoing requests throughout the entire request chain. The implementation includes extensive test coverage for cancellation scenarios across all affected components and lays the groundwork for adding --timeout options to various CLI commands like fedify lookup, fedify webfinger, and fedify nodeinfo, making federated applications more robust and responsive.
@ooheunda addressed a testing infrastructure issue with PR #350, fixing a race condition in PostgreSQL message queue tests that was causing intermittent failures (issue #346). By adding explicit initialization before concurrent message queue listeners, this fix prevents table creation conflicts that were affecting test reliability, ensuring more consistent PR testing for all contributors.
@songbirds provided two test stability improvements with PR #344 and PR #347. The first PR adds skip guards to RedisKvStore tests as a workaround for a known Bun runtime issue, keeping the test suite functional while awaiting an upstream fix. The second PR resolves a race condition in the code generation process by randomizing output filenames, preventing conflicts during parallel test execution. These contributions help maintain a stable testing environment for the project.
Thank you all for your contributions to Fedify. Your work helps make federated social networking more accessible to developers.
@fedify@hollo.social
We'd like to recognize some excellent contributions from our #OSSCA (Open Source Contribution Academy) participants who have been working on #Fedify.
@gaebalgom contributed PR #339, which introduces the @fedify/elysia package to provide Elysia integration for Fedify. This work addresses issue #286 by creating a plugin that enables developers using #Bun and #Elysia to integrate Fedify's #ActivityPub capabilities into their applications. The contribution includes the core integration module, documentation, examples, and proper monorepo configuration, making Fedify accessible to the Elysia community.
@r4bb1t submitted PR #315, implementing comprehensive AbortSignal support across multiple APIs to resolve issue #51. This contribution adds request cancellation capabilities not only to lookupWebFinger() but also to lookupObject(), DocumentLoader, and the HTTP signature authentication flow (doubleKnock()), allowing developers to properly handle timeouts and abort ongoing requests throughout the entire request chain. The implementation includes extensive test coverage for cancellation scenarios across all affected components and lays the groundwork for adding --timeout options to various CLI commands like fedify lookup, fedify webfinger, and fedify nodeinfo, making federated applications more robust and responsive.
@ooheunda addressed a testing infrastructure issue with PR #350, fixing a race condition in PostgreSQL message queue tests that was causing intermittent failures (issue #346). By adding explicit initialization before concurrent message queue listeners, this fix prevents table creation conflicts that were affecting test reliability, ensuring more consistent PR testing for all contributors.
@songbirds provided two test stability improvements with PR #344 and PR #347. The first PR adds skip guards to RedisKvStore tests as a workaround for a known Bun runtime issue, keeping the test suite functional while awaiting an upstream fix. The second PR resolves a race condition in the code generation process by randomizing output filenames, preventing conflicts during parallel test execution. These contributions help maintain a stable testing environment for the project.
Thank you all for your contributions to Fedify. Your work helps make federated social networking more accessible to developers.
@fedify@hollo.social
We'd like to recognize some excellent contributions from our #OSSCA (Open Source Contribution Academy) participants who have been working on #Fedify.
@gaebalgom contributed PR #339, which introduces the @fedify/elysia package to provide Elysia integration for Fedify. This work addresses issue #286 by creating a plugin that enables developers using #Bun and #Elysia to integrate Fedify's #ActivityPub capabilities into their applications. The contribution includes the core integration module, documentation, examples, and proper monorepo configuration, making Fedify accessible to the Elysia community.
@r4bb1t submitted PR #315, implementing comprehensive AbortSignal support across multiple APIs to resolve issue #51. This contribution adds request cancellation capabilities not only to lookupWebFinger() but also to lookupObject(), DocumentLoader, and the HTTP signature authentication flow (doubleKnock()), allowing developers to properly handle timeouts and abort ongoing requests throughout the entire request chain. The implementation includes extensive test coverage for cancellation scenarios across all affected components and lays the groundwork for adding --timeout options to various CLI commands like fedify lookup, fedify webfinger, and fedify nodeinfo, making federated applications more robust and responsive.
@ooheunda addressed a testing infrastructure issue with PR #350, fixing a race condition in PostgreSQL message queue tests that was causing intermittent failures (issue #346). By adding explicit initialization before concurrent message queue listeners, this fix prevents table creation conflicts that were affecting test reliability, ensuring more consistent PR testing for all contributors.
@songbirds provided two test stability improvements with PR #344 and PR #347. The first PR adds skip guards to RedisKvStore tests as a workaround for a known Bun runtime issue, keeping the test suite functional while awaiting an upstream fix. The second PR resolves a race condition in the code generation process by randomizing output filenames, preventing conflicts during parallel test execution. These contributions help maintain a stable testing environment for the project.
Thank you all for your contributions to Fedify. Your work helps make federated social networking more accessible to developers.
@fedify@hollo.social
We'd like to recognize some excellent contributions from our #OSSCA (Open Source Contribution Academy) participants who have been working on #Fedify.
@gaebalgom contributed PR #339, which introduces the @fedify/elysia package to provide Elysia integration for Fedify. This work addresses issue #286 by creating a plugin that enables developers using #Bun and #Elysia to integrate Fedify's #ActivityPub capabilities into their applications. The contribution includes the core integration module, documentation, examples, and proper monorepo configuration, making Fedify accessible to the Elysia community.
@r4bb1t submitted PR #315, implementing comprehensive AbortSignal support across multiple APIs to resolve issue #51. This contribution adds request cancellation capabilities not only to lookupWebFinger() but also to lookupObject(), DocumentLoader, and the HTTP signature authentication flow (doubleKnock()), allowing developers to properly handle timeouts and abort ongoing requests throughout the entire request chain. The implementation includes extensive test coverage for cancellation scenarios across all affected components and lays the groundwork for adding --timeout options to various CLI commands like fedify lookup, fedify webfinger, and fedify nodeinfo, making federated applications more robust and responsive.
@ooheunda addressed a testing infrastructure issue with PR #350, fixing a race condition in PostgreSQL message queue tests that was causing intermittent failures (issue #346). By adding explicit initialization before concurrent message queue listeners, this fix prevents table creation conflicts that were affecting test reliability, ensuring more consistent PR testing for all contributors.
@songbirds provided two test stability improvements with PR #344 and PR #347. The first PR adds skip guards to RedisKvStore tests as a workaround for a known Bun runtime issue, keeping the test suite functional while awaiting an upstream fix. The second PR resolves a race condition in the code generation process by randomizing output filenames, preventing conflicts during parallel test execution. These contributions help maintain a stable testing environment for the project.
Thank you all for your contributions to Fedify. Your work helps make federated social networking more accessible to developers.
@fedify@hollo.social
We'd like to recognize some excellent contributions from our #OSSCA (Open Source Contribution Academy) participants who have been working on #Fedify.
@gaebalgom contributed PR #339, which introduces the @fedify/elysia package to provide Elysia integration for Fedify. This work addresses issue #286 by creating a plugin that enables developers using #Bun and #Elysia to integrate Fedify's #ActivityPub capabilities into their applications. The contribution includes the core integration module, documentation, examples, and proper monorepo configuration, making Fedify accessible to the Elysia community.
@r4bb1t submitted PR #315, implementing comprehensive AbortSignal support across multiple APIs to resolve issue #51. This contribution adds request cancellation capabilities not only to lookupWebFinger() but also to lookupObject(), DocumentLoader, and the HTTP signature authentication flow (doubleKnock()), allowing developers to properly handle timeouts and abort ongoing requests throughout the entire request chain. The implementation includes extensive test coverage for cancellation scenarios across all affected components and lays the groundwork for adding --timeout options to various CLI commands like fedify lookup, fedify webfinger, and fedify nodeinfo, making federated applications more robust and responsive.
@ooheunda addressed a testing infrastructure issue with PR #350, fixing a race condition in PostgreSQL message queue tests that was causing intermittent failures (issue #346). By adding explicit initialization before concurrent message queue listeners, this fix prevents table creation conflicts that were affecting test reliability, ensuring more consistent PR testing for all contributors.
@songbirds provided two test stability improvements with PR #344 and PR #347. The first PR adds skip guards to RedisKvStore tests as a workaround for a known Bun runtime issue, keeping the test suite functional while awaiting an upstream fix. The second PR resolves a race condition in the code generation process by randomizing output filenames, preventing conflicts during parallel test execution. These contributions help maintain a stable testing environment for the project.
Thank you all for your contributions to Fedify. Your work helps make federated social networking more accessible to developers.
@fedify@hollo.social
We'd like to recognize some excellent contributions from our #OSSCA (Open Source Contribution Academy) participants who have been working on #Fedify.
@gaebalgom contributed PR #339, which introduces the @fedify/elysia package to provide Elysia integration for Fedify. This work addresses issue #286 by creating a plugin that enables developers using #Bun and #Elysia to integrate Fedify's #ActivityPub capabilities into their applications. The contribution includes the core integration module, documentation, examples, and proper monorepo configuration, making Fedify accessible to the Elysia community.
@r4bb1t submitted PR #315, implementing comprehensive AbortSignal support across multiple APIs to resolve issue #51. This contribution adds request cancellation capabilities not only to lookupWebFinger() but also to lookupObject(), DocumentLoader, and the HTTP signature authentication flow (doubleKnock()), allowing developers to properly handle timeouts and abort ongoing requests throughout the entire request chain. The implementation includes extensive test coverage for cancellation scenarios across all affected components and lays the groundwork for adding --timeout options to various CLI commands like fedify lookup, fedify webfinger, and fedify nodeinfo, making federated applications more robust and responsive.
@ooheunda addressed a testing infrastructure issue with PR #350, fixing a race condition in PostgreSQL message queue tests that was causing intermittent failures (issue #346). By adding explicit initialization before concurrent message queue listeners, this fix prevents table creation conflicts that were affecting test reliability, ensuring more consistent PR testing for all contributors.
@songbirds provided two test stability improvements with PR #344 and PR #347. The first PR adds skip guards to RedisKvStore tests as a workaround for a known Bun runtime issue, keeping the test suite functional while awaiting an upstream fix. The second PR resolves a race condition in the code generation process by randomizing output filenames, preventing conflicts during parallel test execution. These contributions help maintain a stable testing environment for the project.
Thank you all for your contributions to Fedify. Your work helps make federated social networking more accessible to developers.
@fedify@hollo.social
We'd like to recognize some excellent contributions from our #OSSCA (Open Source Contribution Academy) participants who have been working on #Fedify.
@gaebalgom contributed PR #339, which introduces the @fedify/elysia package to provide Elysia integration for Fedify. This work addresses issue #286 by creating a plugin that enables developers using #Bun and #Elysia to integrate Fedify's #ActivityPub capabilities into their applications. The contribution includes the core integration module, documentation, examples, and proper monorepo configuration, making Fedify accessible to the Elysia community.
@r4bb1t submitted PR #315, implementing comprehensive AbortSignal support across multiple APIs to resolve issue #51. This contribution adds request cancellation capabilities not only to lookupWebFinger() but also to lookupObject(), DocumentLoader, and the HTTP signature authentication flow (doubleKnock()), allowing developers to properly handle timeouts and abort ongoing requests throughout the entire request chain. The implementation includes extensive test coverage for cancellation scenarios across all affected components and lays the groundwork for adding --timeout options to various CLI commands like fedify lookup, fedify webfinger, and fedify nodeinfo, making federated applications more robust and responsive.
@ooheunda addressed a testing infrastructure issue with PR #350, fixing a race condition in PostgreSQL message queue tests that was causing intermittent failures (issue #346). By adding explicit initialization before concurrent message queue listeners, this fix prevents table creation conflicts that were affecting test reliability, ensuring more consistent PR testing for all contributors.
@songbirds provided two test stability improvements with PR #344 and PR #347. The first PR adds skip guards to RedisKvStore tests as a workaround for a known Bun runtime issue, keeping the test suite functional while awaiting an upstream fix. The second PR resolves a race condition in the code generation process by randomizing output filenames, preventing conflicts during parallel test execution. These contributions help maintain a stable testing environment for the project.
Thank you all for your contributions to Fedify. Your work helps make federated social networking more accessible to developers.
@fedify@hollo.social
We'd like to recognize some excellent contributions from our #OSSCA (Open Source Contribution Academy) participants who have been working on #Fedify.
@gaebalgom contributed PR #339, which introduces the @fedify/elysia package to provide Elysia integration for Fedify. This work addresses issue #286 by creating a plugin that enables developers using #Bun and #Elysia to integrate Fedify's #ActivityPub capabilities into their applications. The contribution includes the core integration module, documentation, examples, and proper monorepo configuration, making Fedify accessible to the Elysia community.
@r4bb1t submitted PR #315, implementing comprehensive AbortSignal support across multiple APIs to resolve issue #51. This contribution adds request cancellation capabilities not only to lookupWebFinger() but also to lookupObject(), DocumentLoader, and the HTTP signature authentication flow (doubleKnock()), allowing developers to properly handle timeouts and abort ongoing requests throughout the entire request chain. The implementation includes extensive test coverage for cancellation scenarios across all affected components and lays the groundwork for adding --timeout options to various CLI commands like fedify lookup, fedify webfinger, and fedify nodeinfo, making federated applications more robust and responsive.
@ooheunda addressed a testing infrastructure issue with PR #350, fixing a race condition in PostgreSQL message queue tests that was causing intermittent failures (issue #346). By adding explicit initialization before concurrent message queue listeners, this fix prevents table creation conflicts that were affecting test reliability, ensuring more consistent PR testing for all contributors.
@songbirds provided two test stability improvements with PR #344 and PR #347. The first PR adds skip guards to RedisKvStore tests as a workaround for a known Bun runtime issue, keeping the test suite functional while awaiting an upstream fix. The second PR resolves a race condition in the code generation process by randomizing output filenames, preventing conflicts during parallel test execution. These contributions help maintain a stable testing environment for the project.
Thank you all for your contributions to Fedify. Your work helps make federated social networking more accessible to developers.
@inautilo@mastodon.social
#Development #Overviews
JavaScript’s runtime decade · Running JavaScript beyond the browser and Node.js https://ilo.im/165oqw
_____
#JavaScript #Devices #Cloud #Browser #NodeJS #Deno #Bun #WebDev #Frontend #Backend
@inautilo@mastodon.social
#Development #Overviews
JavaScript’s runtime decade · Running JavaScript beyond the browser and Node.js https://ilo.im/165oqw
_____
#JavaScript #Devices #Cloud #Browser #NodeJS #Deno #Bun #WebDev #Frontend #Backend
@fedify@hollo.social
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:
If you're curious, take a look at the #Fedify website! There's comprehensive docs, a demo, a tutorial, example code, and more:

@hongminhee@hollo.social
Introducing #Upyo!
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.
Switch between #SMTP, #Mailgun, #SendGrid without changing your code. Available on #JSR & #npm!

@hongminhee@hollo.social
Introducing #Upyo!
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.
Switch between #SMTP, #Mailgun, #SendGrid without changing your code. Available on #JSR & #npm!

@hongminhee@hollo.social
Introducing #Upyo!
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.
Switch between #SMTP, #Mailgun, #SendGrid without changing your code. Available on #JSR & #npm!

@hongminhee@hollo.social
Introducing #Upyo!
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.
Switch between #SMTP, #Mailgun, #SendGrid without changing your code. Available on #JSR & #npm!

@hongminhee@hollo.social
Introducing #Upyo!
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.
Switch between #SMTP, #Mailgun, #SendGrid without changing your code. Available on #JSR & #npm!

@hongminhee@hollo.social
Introducing #Upyo!
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.
Switch between #SMTP, #Mailgun, #SendGrid without changing your code. Available on #JSR & #npm!

@hongminhee@hollo.social
Introducing #Upyo!
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.
Switch between #SMTP, #Mailgun, #SendGrid without changing your code. Available on #JSR & #npm!

@hongminhee@hollo.social
Introducing #Upyo!
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.
Switch between #SMTP, #Mailgun, #SendGrid without changing your code. Available on #JSR & #npm!

@hongminhee@hollo.social
Introducing #Upyo!
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.
Switch between #SMTP, #Mailgun, #SendGrid without changing your code. Available on #JSR & #npm!

@hongminhee@hollo.social
Introducing #Upyo!
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.
Switch between #SMTP, #Mailgun, #SendGrid without changing your code. Available on #JSR & #npm!

@hongminhee@hollo.social
Introducing #Upyo!
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.
Switch between #SMTP, #Mailgun, #SendGrid without changing your code. Available on #JSR & #npm!

@hongminhee@hollo.social
Introducing #Upyo!
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.
Switch between #SMTP, #Mailgun, #SendGrid without changing your code. Available on #JSR & #npm!

@hollo@hollo.social
Introducing #Hollo. Hollo is an #ActivityPub-enabled single-user microblogging software. Although it's for a single user, it also supports creating and running multiple accounts for different topics.
It's headless, meaning you can use existing #Mastodon client apps instead, with its Mastodon-compatible APIs. It has most feature parity with Mastodon. Two big differences with Mastodon is that you can use #Markdown in the content of your posts and you can quote another post.
Oh, and Hollo is built using #Bun and #Fedify.

@hollo@hollo.social
Introducing #Hollo. Hollo is an #ActivityPub-enabled single-user microblogging software. Although it's for a single user, it also supports creating and running multiple accounts for different topics.
It's headless, meaning you can use existing #Mastodon client apps instead, with its Mastodon-compatible APIs. It has most feature parity with Mastodon. Two big differences with Mastodon is that you can use #Markdown in the content of your posts and you can quote another post.
Oh, and Hollo is built using #Bun and #Fedify.

@hollo@hollo.social
Introducing #Hollo. Hollo is an #ActivityPub-enabled single-user microblogging software. Although it's for a single user, it also supports creating and running multiple accounts for different topics.
It's headless, meaning you can use existing #Mastodon client apps instead, with its Mastodon-compatible APIs. It has most feature parity with Mastodon. Two big differences with Mastodon is that you can use #Markdown in the content of your posts and you can quote another post.
Oh, and Hollo is built using #Bun and #Fedify.

@hongminhee@hollo.social
Anyone here have experience using @vitest with @deno_land, or setting up a unit test suite that works on #Deno, #Node.js, and #Bun?

@hongminhee@hollo.social
Anyone here have experience using @vitest with @deno_land, or setting up a unit test suite that works on #Deno, #Node.js, and #Bun?

@hongminhee@hollo.social
Anyone here have experience using @vitest with @deno_land, or setting up a unit test suite that works on #Deno, #Node.js, and #Bun?

@hollo@hollo.social
Introducing #Hollo. Hollo is an #ActivityPub-enabled single-user microblogging software. Although it's for a single user, it also supports creating and running multiple accounts for different topics.
It's headless, meaning you can use existing #Mastodon client apps instead, with its Mastodon-compatible APIs. It has most feature parity with Mastodon. Two big differences with Mastodon is that you can use #Markdown in the content of your posts and you can quote another post.
Oh, and Hollo is built using #Bun and #Fedify.

@hollo@hollo.social
Introducing #Hollo. Hollo is an #ActivityPub-enabled single-user microblogging software. Although it's for a single user, it also supports creating and running multiple accounts for different topics.
It's headless, meaning you can use existing #Mastodon client apps instead, with its Mastodon-compatible APIs. It has most feature parity with Mastodon. Two big differences with Mastodon is that you can use #Markdown in the content of your posts and you can quote another post.
Oh, and Hollo is built using #Bun and #Fedify.
@fedify@hollo.social
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:
If you're curious, take a look at the #Fedify website! There's comprehensive docs, a demo, a tutorial, example code, and more:

@hollo@hollo.social
Holloを紹介します!
Holloは、個人向けの連合型マイクロブログソフトウェアです。FedifyとBunを基盤に構築され、ActivityPubプロトコルを通じて他のインスタンスやサービスと連携することができます。
Holloの特徴は、一人のユーザーのために設計された専用のインスタンスという点です。これにより、ユーザーは自分だけのスペースを持ちながら、Mastodon、Misskey、その他のActivityPub対応サービスのユーザーとも交流できます。
独自のウェブインターフェースを持たない代わりに、MastodonのAPIと互換性があるため、既存の多くのMastodonクライアントアプリを使用してHolloにアクセスできます。これにより、使い慣れたインターフェースでHolloを利用することができます。
主な機能には、投稿の作成・編集・削除、返信、メディア添付、投票、お気に入り、ブックマーク、ピン留めなどがあります。また、プロフィール編集、フォロー/フォロワー管理、リスト作成なども可能です。さらに、Markdownをサポートしているため、投稿やプロフィールの書式設定が容易に行えます。
Holloは現在開発の初期段階にあり、継続的に機能の追加や改善が行われています。Bunを使用することで、高速なパフォーマンスと効率的な開発が実現されています。オープンソースプロジェクトとして、GitHubで公開されており、コミュニティからの貢献を歓迎しています。
個人のブログとソーシャルメディアの利点を組み合わせたHolloは、プライバシーを重視しながら、より広いコミュニティとのつながりを求める人々に適したプラットフォームとなっています。
https://github.com/dahlia/hollo
#Hollo #ActivityPub #Mastodon #Markdown #Bun #Fedify #fedidev

@revathskumar@fosstodon.org
@s1r83r@pataterie.ca

@hollo@hollo.social
Introducing #Hollo. Hollo is an #ActivityPub-enabled single-user microblogging software. Although it's for a single user, it also supports creating and running multiple accounts for different topics.
It's headless, meaning you can use existing #Mastodon client apps instead, with its Mastodon-compatible APIs. It has most feature parity with Mastodon. Two big differences with Mastodon is that you can use #Markdown in the content of your posts and you can quote another post.
Oh, and Hollo is built using #Bun and #Fedify.
@fedify@hollo.social
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:
If you're curious, take a look at the #Fedify website! There's comprehensive docs, a demo, a tutorial, example code, and more:
@fedify@hollo.social
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:
If you're curious, take a look at the #Fedify website! There's comprehensive docs, a demo, a tutorial, example code, and more:
@inautilo@mastodon.social
#Development #Launches
Mizu.js · Build dynamic web pages without heavy frameworks https://ilo.im/161hgq
_____
#Library #NextJS #Deno #Bun #Browser #WebDev #Frontend #Backend #HTML #JavaScript
@inautilo@mastodon.social
#Development #Launches
Mizu.js · Build dynamic web pages without heavy frameworks https://ilo.im/161hgq
_____
#Library #NextJS #Deno #Bun #Browser #WebDev #Frontend #Backend #HTML #JavaScript

@hollo@hollo.social
Introducing #Hollo. Hollo is an #ActivityPub-enabled single-user microblogging software. Although it's for a single user, it also supports creating and running multiple accounts for different topics.
It's headless, meaning you can use existing #Mastodon client apps instead, with its Mastodon-compatible APIs. It has most feature parity with Mastodon. Two big differences with Mastodon is that you can use #Markdown in the content of your posts and you can quote another post.
Oh, and Hollo is built using #Bun and #Fedify.

@hollo@hollo.social
Introducing #Hollo. Hollo is an #ActivityPub-enabled single-user microblogging software. Although it's for a single user, it also supports creating and running multiple accounts for different topics.
It's headless, meaning you can use existing #Mastodon client apps instead, with its Mastodon-compatible APIs. It has most feature parity with Mastodon. Two big differences with Mastodon is that you can use #Markdown in the content of your posts and you can quote another post.
Oh, and Hollo is built using #Bun and #Fedify.

@hongminhee@hollo.social
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?

@hollo@hollo.social
Introducing #Hollo. Hollo is an #ActivityPub-enabled single-user microblogging software. Although it's for a single user, it also supports creating and running multiple accounts for different topics.
It's headless, meaning you can use existing #Mastodon client apps instead, with its Mastodon-compatible APIs. It has most feature parity with Mastodon. Two big differences with Mastodon is that you can use #Markdown in the content of your posts and you can quote another post.
Oh, and Hollo is built using #Bun and #Fedify.

@hollo@hollo.social
Introducing #Hollo. Hollo is an #ActivityPub-enabled single-user microblogging software. Although it's for a single user, it also supports creating and running multiple accounts for different topics.
It's headless, meaning you can use existing #Mastodon client apps instead, with its Mastodon-compatible APIs. It has most feature parity with Mastodon. Two big differences with Mastodon is that you can use #Markdown in the content of your posts and you can quote another post.
Oh, and Hollo is built using #Bun and #Fedify.
@blake@infosec.town

@hollo@hollo.social · Reply to Hollo :hollo:'s post
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!

@hollo@hollo.social
#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!
Are you interested in trying out the Node.js version of Hollo early? Try to pull ghcr.io/dahlia/hollo:0.4.0-dev.290!
@hongminhee@fosstodon.org · Reply to 洪 民憙 (Hong Minhee)'s post
@jakehamilton@hachyderm.io
Hi everyone, I am now looking for full-time work! If you have a remote Software Engineer position available and work with #Frontend web tech (#HTML / #CSS / #JS / #TS / #React, etc), #NodeJS (or #Bun / #Deno ), #Kubernetes, or #Nix / #NixOS then please reach out! I love building tools to solve problems and delight users.
For examples of my previous work, links to my projects, and my resume, please see my website: https://jakehamilton.dev
Boosts very much appreciated!
@fedify@hollo.social
#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?
| Option | Voters |
|---|---|
| Yes, because it's misleading. | 5 (28%) |
| A logo is a logo, no need to change it. | 13 (72%) |
@hongminhee@fosstodon.org
@hongminhee@fedibird.com
DenoやBunが好きな方いらっしゃいますか?
@fedify@hollo.social
Fedifyは、TypeScriptとJavaScriptで書かれたActivityPubサーバーフレームワークです。分散型のソーシャルネットワークを構築するためのサーバーアプリケーションを作る際の複雑さと冗長なコードを排除し、ビジネスロジックとユーザー体験の開発に集中できるようにすることを目指しています。
現在提供している主な機能は以下の通りです:
興味がある方は、Fedifyのウェブサイトをご覧ください!包括的なドキュメント、デモ、チュートリアル、サンプルコードなどが用意されています:
#Fedify #TypeScript #JavaScript #ActivityPub #NodeInfo #Node #Deno #Bun #fedidev
@wraptile@fosstodon.org · Reply to 洪 民憙 (Hong Minhee)'s post
@hongminhee @deno_land it's amazing what a difference proper tooling makes!
Also check out #Bun which is very similar to Deno but even more convenient at times. I'm always in between these two and not really sure which one is better just happy to never use #nodejs ever again 💀
@hongminhee@fosstodon.org · Reply to 洪 民憙 (Hong Minhee)'s post
One reason I like #Deno (@deno_land) more than #Bun.
@hongminhee@fosstodon.org
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
LogTape v0.5.0 is available from JSR and npm:
• JSR: https://jsr.io/@logtape/logtape@0.5.0
• npm: https://www.npmjs.com/package/@logtape/logtape/v/0.5.0
In addition, a new website with documentation has been launched, so please check it out!
@hongminhee@fosstodon.org · Reply to Pablo Berganza (he/him)'s post
@pablo@sivar.cafe
It’s been years since I’ve used NodeJS and was curious about the current situation. Is Deno a thing? I see they backtracked a bit and now have an NPM compatibility layer (although I don’t mind that). And I think I like the direction with JSR.io.
Is Bun alright? I’ve seen some comments saying that it was not ready for v1 yet.
Is this going to be like an io.js situation and we will all go back to Node eventually?

@hollo@hollo.social
Hollo를 소개합니다!
Hollo는 개인을 위한 연합형 마이크로블로그 소프트웨어입니다. Fedify와 Bun으로 만들어졌으며, #ActivityPub 프로토콜을 통해 다른 인스턴스 및 서비스와 교류할 수 있습니다.
Hollo의 특징은 한 사용자를 위해 설계된 전용 인스턴스라는 점입니다. 이를 통해 사용자는 자신만의 공간을 가지면서도 #Mastodon, #Misskey 및 기타 ActivityPub 지원 서비스의 사용자들과 소통할 수 있습니다.
독자적인 웹 인터페이스는 없지만, Mastodon API와 호환되어 기존의 많은 Mastodon 클라이언트 앱을 사용하여 Hollo에 접근할 수 있습니다. 이로 인해 익숙한 인터페이스로 Hollo를 이용할 수 있습니다.
주요 기능으로는 게시물 작성·편집·삭제, 답글, 미디어 첨부, 투표, 좋아요, 북마크, 고정 등이 있습니다. 또한 프로필 편집, 팔로우/팔로워 관리, 리스트 생성 등도 가능합니다. 더불어 Markdown을 지원하여 게시물이나 프로필의 서식 설정을 쉽게 할 수 있습니다.
Hollo는 현재 개발 초기 단계에 있으며, 지속적으로 기능 추가와 개선이 이루어지고 있습니다. Bun을 사용함으로써 빠른 성능과 효율적인 개발이 이뤄지고 있답니다. 오픈 소스 프로젝트로 GitHub에 공개되어 있으며, 커뮤니티의 기여를 환영합니다.
개인 블로그와 소셜 미디어의 장점을 결합한 Hollo는 프라이버시를 중시하면서도 더 넓은 커뮤니티와의 연결을 원하는 사람들에게 적합한 플랫폼으로 거듭나고 있습니다.

@hollo@hollo.social
Holloを紹介します!
Holloは、個人向けの連合型マイクロブログソフトウェアです。FedifyとBunを基盤に構築され、ActivityPubプロトコルを通じて他のインスタンスやサービスと連携することができます。
Holloの特徴は、一人のユーザーのために設計された専用のインスタンスという点です。これにより、ユーザーは自分だけのスペースを持ちながら、Mastodon、Misskey、その他のActivityPub対応サービスのユーザーとも交流できます。
独自のウェブインターフェースを持たない代わりに、MastodonのAPIと互換性があるため、既存の多くのMastodonクライアントアプリを使用してHolloにアクセスできます。これにより、使い慣れたインターフェースでHolloを利用することができます。
主な機能には、投稿の作成・編集・削除、返信、メディア添付、投票、お気に入り、ブックマーク、ピン留めなどがあります。また、プロフィール編集、フォロー/フォロワー管理、リスト作成なども可能です。さらに、Markdownをサポートしているため、投稿やプロフィールの書式設定が容易に行えます。
Holloは現在開発の初期段階にあり、継続的に機能の追加や改善が行われています。Bunを使用することで、高速なパフォーマンスと効率的な開発が実現されています。オープンソースプロジェクトとして、GitHubで公開されており、コミュニティからの貢献を歓迎しています。
個人のブログとソーシャルメディアの利点を組み合わせたHolloは、プライバシーを重視しながら、より広いコミュニティとのつながりを求める人々に適したプラットフォームとなっています。
https://github.com/dahlia/hollo
#Hollo #ActivityPub #Mastodon #Markdown #Bun #Fedify #fedidev
@fedify@hollo.social
@hongminhee@fosstodon.org
この記事を読むと、自分もHolloでBunの代わりにNode.jsを使うべきなのかなーと。
@hongminhee@fosstodon.org
#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
@hongminhee@fosstodon.org
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.
| Option | Voters |
|---|---|
| Bun | 0 (0%) |
| Deno | 0 (0%) |
| Node.js | 0 (0%) |
@hongminhee@fosstodon.org
I wish the #Temporal API would be built into #Node.js and #Bun as well.
@wraptile@fosstodon.org
#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!
@fedify@hollo.social
The fedify command is now available on #npm! You can install it using the following command:
npm install -g @fedify/cli
Or if you use #Bun:
bun install -g @fedify/cli
@hongminhee@todon.eu
#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
@hongminhee@todon.eu
#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@hollo.social
#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@hollo.social
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:
If you're curious, take a look at the #Fedify website! There's comprehensive docs, a demo, a tutorial, example code, and more:
@hongminhee@fosstodon.org · Reply to 洪 民憙 (Hong Minhee)'s post
@hongminhee@fosstodon.org
@hongminhee@fosstodon.org

@hollo@hollo.social
Introducing #Hollo. Hollo is an #ActivityPub-enabled single-user microblogging software. Although it's for a single user, it also supports creating and running multiple accounts for different topics.
It's headless, meaning you can use existing #Mastodon client apps instead, with its Mastodon-compatible APIs. It has most feature parity with Mastodon. Two big differences with Mastodon is that you can use #Markdown in the content of your posts and you can quote another post.
Oh, and Hollo is built using #Bun and #Fedify.