Mit der Lieferung der Sprachdatei ist klar, dass das Friendica-Release unmittelbar bevorsteht.
Die neuen Features und Verbesserungen der Usability kann man inzwischen nicht mehr zählen. Daher vorab ein großes Dankeschön an alle Beteiligten.

#Friendica #RC #Release #Stable

Mit der Lieferung der Sprachdatei ist klar, dass das Friendica-Release unmittelbar bevorsteht.
Die neuen Features und Verbesserungen der Usability kann man inzwischen nicht mehr zählen. Daher vorab ein großes Dankeschön an alle Beteiligten.

#Friendica #RC #Release #Stable

Mit der Lieferung der Sprachdatei ist klar, dass das Friendica-Release unmittelbar bevorsteht.
Die neuen Features und Verbesserungen der Usability kann man inzwischen nicht mehr zählen. Daher vorab ein großes Dankeschön an alle Beteiligten.

#Friendica #RC #Release #Stable

Mit der Lieferung der Sprachdatei ist klar, dass das Friendica-Release unmittelbar bevorsteht.
Die neuen Features und Verbesserungen der Usability kann man inzwischen nicht mehr zählen. Daher vorab ein großes Dankeschön an alle Beteiligten.

#Friendica #RC #Release #Stable

Home Assistant 2026.1 🥂

Home dashboard improvements 🏡, easier navigation to protocol dashboards 🔎, and ESPHome action responses are just a few of the small but important changes this release. 😎

#HomeAssistant #SmartHome #Release #HomeAutomation
https://www.home-assistant.io/blog/2026/01/07/release-20261

Pidgin 3.0 Experimental 5 (2.94.0) has been released https://lobste.rs/s/ukybhb #c #release
https://discourse.imfreedom.org/t/pidgin-3-0-experimental-5-2-94-0-has-been-released/338

If I were to release a service to run on servers, how would you prefer I package it? A #poll: #selfhosting #software #release

If I were to release a service to run on servers, how would you prefer I package it? A #poll: #selfhosting #software #release

Fedify 1.10.0: Observability foundations for the future debug dashboard

Fedify is a #TypeScript framework for building #ActivityPub servers that participate in the #fediverse. It reduces the complexity and boilerplate typically required for ActivityPub implementation while providing comprehensive federation capabilities.

We're excited to announce #Fedify 1.10.0, a focused release that lays critical groundwork for future debugging and observability features. Released on December 24, 2025, this version introduces infrastructure improvements that will enable the upcoming debug dashboard while maintaining full backward compatibility with existing Fedify applications.

This release represents a transitional step toward Fedify 2.0.0, introducing optional capabilities that will become standard in the next major version. The changes focus on enabling richer observability through OpenTelemetry enhancements and adding prefix scanning capabilities to the key–value store interface.

Enhanced OpenTelemetry instrumentation

Fedify 1.10.0 significantly expands OpenTelemetry instrumentation with span events that capture detailed ActivityPub data. These enhancements enable richer observability and debugging capabilities without relying solely on span attributes, which are limited to primitive values.

The new span events provide complete activity payloads and verification status, making it possible to build comprehensive debugging tools that show the full context of federation operations:

• activitypub.activity.received event on activitypub.inbox span — records the full activity JSON, verification status (activity verified, HTTP signatures verified, Linked Data signatures verified), and actor information
• activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
• activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

• activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
• activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These instrumentation improvements emerged from work on issue #234 (Real-time ActivityPub debug dashboard). Rather than introducing a custom observer interface as originally proposed in #323, we leveraged Fedify's existing OpenTelemetry infrastructure to capture rich federation data through span events. This approach provides a standards-based foundation that's composable with existing observability tools like Jaeger, Zipkin, and Grafana Tempo.

Distributed trace storage with FedifySpanExporter

Building on the enhanced instrumentation, Fedify 1.10.0 introduces FedifySpanExporter, a new OpenTelemetry SpanExporter that persists ActivityPub activity traces to a KvStore. This enables distributed tracing support across multiple nodes in a Fedify deployment, which is essential for building debug dashboards that can show complete request flows across web servers and background workers.

The new @fedify/fedify/otel module provides the following types and interfaces:

import { MemoryKvStore } from "@fedify/fedify";
import { FedifySpanExporter } from "@fedify/fedify/otel";
import {
  BasicTracerProvider,
  SimpleSpanProcessor,
} from "@opentelemetry/sdk-trace-base";

const kv = new MemoryKvStore();
const exporter = new FedifySpanExporter(kv, {
  ttl: Temporal.Duration.from({ hours: 1 }),
});

const provider = new BasicTracerProvider();
provider.addSpanProcessor(new SimpleSpanProcessor(exporter));

The stored traces can be queried for display in debugging interfaces:

// Get all activities for a specific trace
const activities = await exporter.getActivitiesByTraceId(traceId);

// Get recent traces with summary information
const recentTraces = await exporter.getRecentTraces({ limit: 100 });

The exporter supports two storage strategies depending on the KvStore capabilities. When the list() method is available (preferred), it stores individual records with keys like [prefix, traceId, spanId]. When only cas() is available, it uses compare-and-swap operations to append records to arrays stored per trace.

This infrastructure provides the foundation for implementing a comprehensive debug dashboard as a custom SpanExporter, as outlined in the updated implementation plan for issue #234.

Optional list() method for KvStore interface

Fedify 1.10.0 adds an optional list() method to the KvStore interface for enumerating entries by key prefix. This method enables efficient prefix scanning, which is useful for implementing features like distributed trace storage, cache invalidation by prefix, and listing related entries.

interface KvStore {
  // ... existing methods
  list?(prefix?: KvKey): AsyncIterable<KvStoreListEntry>;
}

When the prefix parameter is omitted or empty, list() returns all entries in the store. This is useful for debugging and administrative purposes. All official KvStore implementations have been updated to support this method:

• MemoryKvStore — filters in-memory keys by prefix
• SqliteKvStore — uses LIKE query with JSON key pattern
• PostgresKvStore — uses array slice comparison
• RedisKvStore — uses SCAN with pattern matching and key deserialization
• DenoKvStore — delegates to Deno KV's built-in list() API
• WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

While list() is currently optional to give existing custom KvStore implementations time to add support, it will become a required method in Fedify 2.0.0 (tracked in issue #499). This migration path allows implementers to gradually adopt the new capability throughout the 1.x release cycle.

The addition of list() support was implemented in pull request #500, which also included the setup of proper testing infrastructure for WorkersKvStore using Vitest with @cloudflare/vitest-pool-workers.

NestJS 11 and Express 5 support

Thanks to a contribution from Cho Hasang (@crohasang), the @fedify/nestjs package now supports NestJS 11 environments that use Express 5. The peer dependency range for Express has been widened to ^4.0.0 || ^5.0.0, eliminating peer dependency conflicts in modern NestJS projects while maintaining backward compatibility with Express 4.

This change, implemented in pull request #493, keeps the workspace catalog pinned to Express 4 for internal development and test stability while allowing Express 5 in consuming applications.

What's next

Fedify 1.10.0 serves as a stepping stone toward the upcoming 2.0.0 release. The optional list() method introduced in this version will become required in 2.0.0, simplifying the interface contract and allowing Fedify internals to rely on prefix scanning being universally available.

The enhanced #OpenTelemetry instrumentation and FedifySpanExporter provide the foundation for implementing the debug dashboard proposed in issue #234. The next steps include building the web dashboard UI with real-time activity lists, filtering, and JSON inspection capabilities—all as a separate package that leverages the standards-based observability infrastructure introduced in this release.

Depending on the development timeline and feature priorities, there may be additional 1.x releases before the 2.0.0 migration. For developers building custom KvStore implementations, now is the time to add list() support to prepare for the eventual 2.0.0 upgrade. The implementation patterns used in the official backends provide clear guidance for various storage strategies.

Acknowledgments

Special thanks to Cho Hasang (@crohasang) for the NestJS 11 compatibility improvements, and to all community members who provided feedback and testing for the new observability features.

For the complete list of changes, bug fixes, and improvements, please refer to the CHANGES.md file in the repository.

#fedidev #release

Fedify 1.10.0: Observability foundations for the future debug dashboard

Fedify is a #TypeScript framework for building #ActivityPub servers that participate in the #fediverse. It reduces the complexity and boilerplate typically required for ActivityPub implementation while providing comprehensive federation capabilities.

We're excited to announce #Fedify 1.10.0, a focused release that lays critical groundwork for future debugging and observability features. Released on December 24, 2025, this version introduces infrastructure improvements that will enable the upcoming debug dashboard while maintaining full backward compatibility with existing Fedify applications.

This release represents a transitional step toward Fedify 2.0.0, introducing optional capabilities that will become standard in the next major version. The changes focus on enabling richer observability through OpenTelemetry enhancements and adding prefix scanning capabilities to the key–value store interface.

Enhanced OpenTelemetry instrumentation

Fedify 1.10.0 significantly expands OpenTelemetry instrumentation with span events that capture detailed ActivityPub data. These enhancements enable richer observability and debugging capabilities without relying solely on span attributes, which are limited to primitive values.

The new span events provide complete activity payloads and verification status, making it possible to build comprehensive debugging tools that show the full context of federation operations:

• activitypub.activity.received event on activitypub.inbox span — records the full activity JSON, verification status (activity verified, HTTP signatures verified, Linked Data signatures verified), and actor information
• activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
• activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

• activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
• activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These instrumentation improvements emerged from work on issue #234 (Real-time ActivityPub debug dashboard). Rather than introducing a custom observer interface as originally proposed in #323, we leveraged Fedify's existing OpenTelemetry infrastructure to capture rich federation data through span events. This approach provides a standards-based foundation that's composable with existing observability tools like Jaeger, Zipkin, and Grafana Tempo.

Distributed trace storage with FedifySpanExporter

Building on the enhanced instrumentation, Fedify 1.10.0 introduces FedifySpanExporter, a new OpenTelemetry SpanExporter that persists ActivityPub activity traces to a KvStore. This enables distributed tracing support across multiple nodes in a Fedify deployment, which is essential for building debug dashboards that can show complete request flows across web servers and background workers.

The new @fedify/fedify/otel module provides the following types and interfaces:

import { MemoryKvStore } from "@fedify/fedify";
import { FedifySpanExporter } from "@fedify/fedify/otel";
import {
  BasicTracerProvider,
  SimpleSpanProcessor,
} from "@opentelemetry/sdk-trace-base";

const kv = new MemoryKvStore();
const exporter = new FedifySpanExporter(kv, {
  ttl: Temporal.Duration.from({ hours: 1 }),
});

const provider = new BasicTracerProvider();
provider.addSpanProcessor(new SimpleSpanProcessor(exporter));

The stored traces can be queried for display in debugging interfaces:

// Get all activities for a specific trace
const activities = await exporter.getActivitiesByTraceId(traceId);

// Get recent traces with summary information
const recentTraces = await exporter.getRecentTraces({ limit: 100 });

The exporter supports two storage strategies depending on the KvStore capabilities. When the list() method is available (preferred), it stores individual records with keys like [prefix, traceId, spanId]. When only cas() is available, it uses compare-and-swap operations to append records to arrays stored per trace.

This infrastructure provides the foundation for implementing a comprehensive debug dashboard as a custom SpanExporter, as outlined in the updated implementation plan for issue #234.

Optional list() method for KvStore interface

Fedify 1.10.0 adds an optional list() method to the KvStore interface for enumerating entries by key prefix. This method enables efficient prefix scanning, which is useful for implementing features like distributed trace storage, cache invalidation by prefix, and listing related entries.

interface KvStore {
  // ... existing methods
  list?(prefix?: KvKey): AsyncIterable<KvStoreListEntry>;
}

When the prefix parameter is omitted or empty, list() returns all entries in the store. This is useful for debugging and administrative purposes. All official KvStore implementations have been updated to support this method:

• MemoryKvStore — filters in-memory keys by prefix
• SqliteKvStore — uses LIKE query with JSON key pattern
• PostgresKvStore — uses array slice comparison
• RedisKvStore — uses SCAN with pattern matching and key deserialization
• DenoKvStore — delegates to Deno KV's built-in list() API
• WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

While list() is currently optional to give existing custom KvStore implementations time to add support, it will become a required method in Fedify 2.0.0 (tracked in issue #499). This migration path allows implementers to gradually adopt the new capability throughout the 1.x release cycle.

The addition of list() support was implemented in pull request #500, which also included the setup of proper testing infrastructure for WorkersKvStore using Vitest with @cloudflare/vitest-pool-workers.

NestJS 11 and Express 5 support

Thanks to a contribution from Cho Hasang (@crohasang), the @fedify/nestjs package now supports NestJS 11 environments that use Express 5. The peer dependency range for Express has been widened to ^4.0.0 || ^5.0.0, eliminating peer dependency conflicts in modern NestJS projects while maintaining backward compatibility with Express 4.

This change, implemented in pull request #493, keeps the workspace catalog pinned to Express 4 for internal development and test stability while allowing Express 5 in consuming applications.

What's next

Fedify 1.10.0 serves as a stepping stone toward the upcoming 2.0.0 release. The optional list() method introduced in this version will become required in 2.0.0, simplifying the interface contract and allowing Fedify internals to rely on prefix scanning being universally available.

The enhanced #OpenTelemetry instrumentation and FedifySpanExporter provide the foundation for implementing the debug dashboard proposed in issue #234. The next steps include building the web dashboard UI with real-time activity lists, filtering, and JSON inspection capabilities—all as a separate package that leverages the standards-based observability infrastructure introduced in this release.

Depending on the development timeline and feature priorities, there may be additional 1.x releases before the 2.0.0 migration. For developers building custom KvStore implementations, now is the time to add list() support to prepare for the eventual 2.0.0 upgrade. The implementation patterns used in the official backends provide clear guidance for various storage strategies.

Acknowledgments

Special thanks to Cho Hasang (@crohasang) for the NestJS 11 compatibility improvements, and to all community members who provided feedback and testing for the new observability features.

For the complete list of changes, bug fixes, and improvements, please refer to the CHANGES.md file in the repository.

#fedidev #release

Fedify 1.10.0: Observability foundations for the future debug dashboard

Fedify is a #TypeScript framework for building #ActivityPub servers that participate in the #fediverse. It reduces the complexity and boilerplate typically required for ActivityPub implementation while providing comprehensive federation capabilities.

We're excited to announce #Fedify 1.10.0, a focused release that lays critical groundwork for future debugging and observability features. Released on December 24, 2025, this version introduces infrastructure improvements that will enable the upcoming debug dashboard while maintaining full backward compatibility with existing Fedify applications.

This release represents a transitional step toward Fedify 2.0.0, introducing optional capabilities that will become standard in the next major version. The changes focus on enabling richer observability through OpenTelemetry enhancements and adding prefix scanning capabilities to the key–value store interface.

Enhanced OpenTelemetry instrumentation

Fedify 1.10.0 significantly expands OpenTelemetry instrumentation with span events that capture detailed ActivityPub data. These enhancements enable richer observability and debugging capabilities without relying solely on span attributes, which are limited to primitive values.

The new span events provide complete activity payloads and verification status, making it possible to build comprehensive debugging tools that show the full context of federation operations:

• activitypub.activity.received event on activitypub.inbox span — records the full activity JSON, verification status (activity verified, HTTP signatures verified, Linked Data signatures verified), and actor information
• activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
• activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

• activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
• activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These instrumentation improvements emerged from work on issue #234 (Real-time ActivityPub debug dashboard). Rather than introducing a custom observer interface as originally proposed in #323, we leveraged Fedify's existing OpenTelemetry infrastructure to capture rich federation data through span events. This approach provides a standards-based foundation that's composable with existing observability tools like Jaeger, Zipkin, and Grafana Tempo.

Distributed trace storage with FedifySpanExporter

Building on the enhanced instrumentation, Fedify 1.10.0 introduces FedifySpanExporter, a new OpenTelemetry SpanExporter that persists ActivityPub activity traces to a KvStore. This enables distributed tracing support across multiple nodes in a Fedify deployment, which is essential for building debug dashboards that can show complete request flows across web servers and background workers.

The new @fedify/fedify/otel module provides the following types and interfaces:

import { MemoryKvStore } from "@fedify/fedify";
import { FedifySpanExporter } from "@fedify/fedify/otel";
import {
  BasicTracerProvider,
  SimpleSpanProcessor,
} from "@opentelemetry/sdk-trace-base";

const kv = new MemoryKvStore();
const exporter = new FedifySpanExporter(kv, {
  ttl: Temporal.Duration.from({ hours: 1 }),
});

const provider = new BasicTracerProvider();
provider.addSpanProcessor(new SimpleSpanProcessor(exporter));

The stored traces can be queried for display in debugging interfaces:

// Get all activities for a specific trace
const activities = await exporter.getActivitiesByTraceId(traceId);

// Get recent traces with summary information
const recentTraces = await exporter.getRecentTraces({ limit: 100 });

The exporter supports two storage strategies depending on the KvStore capabilities. When the list() method is available (preferred), it stores individual records with keys like [prefix, traceId, spanId]. When only cas() is available, it uses compare-and-swap operations to append records to arrays stored per trace.

This infrastructure provides the foundation for implementing a comprehensive debug dashboard as a custom SpanExporter, as outlined in the updated implementation plan for issue #234.

Optional list() method for KvStore interface

Fedify 1.10.0 adds an optional list() method to the KvStore interface for enumerating entries by key prefix. This method enables efficient prefix scanning, which is useful for implementing features like distributed trace storage, cache invalidation by prefix, and listing related entries.

interface KvStore {
  // ... existing methods
  list?(prefix?: KvKey): AsyncIterable<KvStoreListEntry>;
}

When the prefix parameter is omitted or empty, list() returns all entries in the store. This is useful for debugging and administrative purposes. All official KvStore implementations have been updated to support this method:

• MemoryKvStore — filters in-memory keys by prefix
• SqliteKvStore — uses LIKE query with JSON key pattern
• PostgresKvStore — uses array slice comparison
• RedisKvStore — uses SCAN with pattern matching and key deserialization
• DenoKvStore — delegates to Deno KV's built-in list() API
• WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

While list() is currently optional to give existing custom KvStore implementations time to add support, it will become a required method in Fedify 2.0.0 (tracked in issue #499). This migration path allows implementers to gradually adopt the new capability throughout the 1.x release cycle.

The addition of list() support was implemented in pull request #500, which also included the setup of proper testing infrastructure for WorkersKvStore using Vitest with @cloudflare/vitest-pool-workers.

NestJS 11 and Express 5 support

Thanks to a contribution from Cho Hasang (@crohasang), the @fedify/nestjs package now supports NestJS 11 environments that use Express 5. The peer dependency range for Express has been widened to ^4.0.0 || ^5.0.0, eliminating peer dependency conflicts in modern NestJS projects while maintaining backward compatibility with Express 4.

This change, implemented in pull request #493, keeps the workspace catalog pinned to Express 4 for internal development and test stability while allowing Express 5 in consuming applications.

What's next

Fedify 1.10.0 serves as a stepping stone toward the upcoming 2.0.0 release. The optional list() method introduced in this version will become required in 2.0.0, simplifying the interface contract and allowing Fedify internals to rely on prefix scanning being universally available.

The enhanced #OpenTelemetry instrumentation and FedifySpanExporter provide the foundation for implementing the debug dashboard proposed in issue #234. The next steps include building the web dashboard UI with real-time activity lists, filtering, and JSON inspection capabilities—all as a separate package that leverages the standards-based observability infrastructure introduced in this release.

Depending on the development timeline and feature priorities, there may be additional 1.x releases before the 2.0.0 migration. For developers building custom KvStore implementations, now is the time to add list() support to prepare for the eventual 2.0.0 upgrade. The implementation patterns used in the official backends provide clear guidance for various storage strategies.

Acknowledgments

Special thanks to Cho Hasang (@crohasang) for the NestJS 11 compatibility improvements, and to all community members who provided feedback and testing for the new observability features.

For the complete list of changes, bug fixes, and improvements, please refer to the CHANGES.md file in the repository.

#fedidev #release

Fedify 1.10.0: Observability foundations for the future debug dashboard

Fedify is a #TypeScript framework for building #ActivityPub servers that participate in the #fediverse. It reduces the complexity and boilerplate typically required for ActivityPub implementation while providing comprehensive federation capabilities.

We're excited to announce #Fedify 1.10.0, a focused release that lays critical groundwork for future debugging and observability features. Released on December 24, 2025, this version introduces infrastructure improvements that will enable the upcoming debug dashboard while maintaining full backward compatibility with existing Fedify applications.

This release represents a transitional step toward Fedify 2.0.0, introducing optional capabilities that will become standard in the next major version. The changes focus on enabling richer observability through OpenTelemetry enhancements and adding prefix scanning capabilities to the key–value store interface.

Enhanced OpenTelemetry instrumentation

Fedify 1.10.0 significantly expands OpenTelemetry instrumentation with span events that capture detailed ActivityPub data. These enhancements enable richer observability and debugging capabilities without relying solely on span attributes, which are limited to primitive values.

The new span events provide complete activity payloads and verification status, making it possible to build comprehensive debugging tools that show the full context of federation operations:

• activitypub.activity.received event on activitypub.inbox span — records the full activity JSON, verification status (activity verified, HTTP signatures verified, Linked Data signatures verified), and actor information
• activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
• activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

• activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
• activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These instrumentation improvements emerged from work on issue #234 (Real-time ActivityPub debug dashboard). Rather than introducing a custom observer interface as originally proposed in #323, we leveraged Fedify's existing OpenTelemetry infrastructure to capture rich federation data through span events. This approach provides a standards-based foundation that's composable with existing observability tools like Jaeger, Zipkin, and Grafana Tempo.

Distributed trace storage with FedifySpanExporter

Building on the enhanced instrumentation, Fedify 1.10.0 introduces FedifySpanExporter, a new OpenTelemetry SpanExporter that persists ActivityPub activity traces to a KvStore. This enables distributed tracing support across multiple nodes in a Fedify deployment, which is essential for building debug dashboards that can show complete request flows across web servers and background workers.

The new @fedify/fedify/otel module provides the following types and interfaces:

import { MemoryKvStore } from "@fedify/fedify";
import { FedifySpanExporter } from "@fedify/fedify/otel";
import {
  BasicTracerProvider,
  SimpleSpanProcessor,
} from "@opentelemetry/sdk-trace-base";

const kv = new MemoryKvStore();
const exporter = new FedifySpanExporter(kv, {
  ttl: Temporal.Duration.from({ hours: 1 }),
});

const provider = new BasicTracerProvider();
provider.addSpanProcessor(new SimpleSpanProcessor(exporter));

The stored traces can be queried for display in debugging interfaces:

// Get all activities for a specific trace
const activities = await exporter.getActivitiesByTraceId(traceId);

// Get recent traces with summary information
const recentTraces = await exporter.getRecentTraces({ limit: 100 });

The exporter supports two storage strategies depending on the KvStore capabilities. When the list() method is available (preferred), it stores individual records with keys like [prefix, traceId, spanId]. When only cas() is available, it uses compare-and-swap operations to append records to arrays stored per trace.

This infrastructure provides the foundation for implementing a comprehensive debug dashboard as a custom SpanExporter, as outlined in the updated implementation plan for issue #234.

Optional list() method for KvStore interface

Fedify 1.10.0 adds an optional list() method to the KvStore interface for enumerating entries by key prefix. This method enables efficient prefix scanning, which is useful for implementing features like distributed trace storage, cache invalidation by prefix, and listing related entries.

interface KvStore {
  // ... existing methods
  list?(prefix?: KvKey): AsyncIterable<KvStoreListEntry>;
}

When the prefix parameter is omitted or empty, list() returns all entries in the store. This is useful for debugging and administrative purposes. All official KvStore implementations have been updated to support this method:

• MemoryKvStore — filters in-memory keys by prefix
• SqliteKvStore — uses LIKE query with JSON key pattern
• PostgresKvStore — uses array slice comparison
• RedisKvStore — uses SCAN with pattern matching and key deserialization
• DenoKvStore — delegates to Deno KV's built-in list() API
• WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

While list() is currently optional to give existing custom KvStore implementations time to add support, it will become a required method in Fedify 2.0.0 (tracked in issue #499). This migration path allows implementers to gradually adopt the new capability throughout the 1.x release cycle.

The addition of list() support was implemented in pull request #500, which also included the setup of proper testing infrastructure for WorkersKvStore using Vitest with @cloudflare/vitest-pool-workers.

NestJS 11 and Express 5 support

Thanks to a contribution from Cho Hasang (@crohasang), the @fedify/nestjs package now supports NestJS 11 environments that use Express 5. The peer dependency range for Express has been widened to ^4.0.0 || ^5.0.0, eliminating peer dependency conflicts in modern NestJS projects while maintaining backward compatibility with Express 4.

This change, implemented in pull request #493, keeps the workspace catalog pinned to Express 4 for internal development and test stability while allowing Express 5 in consuming applications.

What's next

Fedify 1.10.0 serves as a stepping stone toward the upcoming 2.0.0 release. The optional list() method introduced in this version will become required in 2.0.0, simplifying the interface contract and allowing Fedify internals to rely on prefix scanning being universally available.

The enhanced #OpenTelemetry instrumentation and FedifySpanExporter provide the foundation for implementing the debug dashboard proposed in issue #234. The next steps include building the web dashboard UI with real-time activity lists, filtering, and JSON inspection capabilities—all as a separate package that leverages the standards-based observability infrastructure introduced in this release.

Depending on the development timeline and feature priorities, there may be additional 1.x releases before the 2.0.0 migration. For developers building custom KvStore implementations, now is the time to add list() support to prepare for the eventual 2.0.0 upgrade. The implementation patterns used in the official backends provide clear guidance for various storage strategies.

Acknowledgments

Special thanks to Cho Hasang (@crohasang) for the NestJS 11 compatibility improvements, and to all community members who provided feedback and testing for the new observability features.

For the complete list of changes, bug fixes, and improvements, please refer to the CHANGES.md file in the repository.

#fedidev #release

Fedify 1.10.0: Observability foundations for the future debug dashboard

Fedify is a #TypeScript framework for building #ActivityPub servers that participate in the #fediverse. It reduces the complexity and boilerplate typically required for ActivityPub implementation while providing comprehensive federation capabilities.

We're excited to announce #Fedify 1.10.0, a focused release that lays critical groundwork for future debugging and observability features. Released on December 24, 2025, this version introduces infrastructure improvements that will enable the upcoming debug dashboard while maintaining full backward compatibility with existing Fedify applications.

This release represents a transitional step toward Fedify 2.0.0, introducing optional capabilities that will become standard in the next major version. The changes focus on enabling richer observability through OpenTelemetry enhancements and adding prefix scanning capabilities to the key–value store interface.

Enhanced OpenTelemetry instrumentation

Fedify 1.10.0 significantly expands OpenTelemetry instrumentation with span events that capture detailed ActivityPub data. These enhancements enable richer observability and debugging capabilities without relying solely on span attributes, which are limited to primitive values.

The new span events provide complete activity payloads and verification status, making it possible to build comprehensive debugging tools that show the full context of federation operations:

• activitypub.activity.received event on activitypub.inbox span — records the full activity JSON, verification status (activity verified, HTTP signatures verified, Linked Data signatures verified), and actor information
• activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
• activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

• activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
• activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These instrumentation improvements emerged from work on issue #234 (Real-time ActivityPub debug dashboard). Rather than introducing a custom observer interface as originally proposed in #323, we leveraged Fedify's existing OpenTelemetry infrastructure to capture rich federation data through span events. This approach provides a standards-based foundation that's composable with existing observability tools like Jaeger, Zipkin, and Grafana Tempo.

Distributed trace storage with FedifySpanExporter

Building on the enhanced instrumentation, Fedify 1.10.0 introduces FedifySpanExporter, a new OpenTelemetry SpanExporter that persists ActivityPub activity traces to a KvStore. This enables distributed tracing support across multiple nodes in a Fedify deployment, which is essential for building debug dashboards that can show complete request flows across web servers and background workers.

The new @fedify/fedify/otel module provides the following types and interfaces:

import { MemoryKvStore } from "@fedify/fedify";
import { FedifySpanExporter } from "@fedify/fedify/otel";
import {
  BasicTracerProvider,
  SimpleSpanProcessor,
} from "@opentelemetry/sdk-trace-base";

const kv = new MemoryKvStore();
const exporter = new FedifySpanExporter(kv, {
  ttl: Temporal.Duration.from({ hours: 1 }),
});

const provider = new BasicTracerProvider();
provider.addSpanProcessor(new SimpleSpanProcessor(exporter));

The stored traces can be queried for display in debugging interfaces:

// Get all activities for a specific trace
const activities = await exporter.getActivitiesByTraceId(traceId);

// Get recent traces with summary information
const recentTraces = await exporter.getRecentTraces({ limit: 100 });

The exporter supports two storage strategies depending on the KvStore capabilities. When the list() method is available (preferred), it stores individual records with keys like [prefix, traceId, spanId]. When only cas() is available, it uses compare-and-swap operations to append records to arrays stored per trace.

This infrastructure provides the foundation for implementing a comprehensive debug dashboard as a custom SpanExporter, as outlined in the updated implementation plan for issue #234.

Optional list() method for KvStore interface

Fedify 1.10.0 adds an optional list() method to the KvStore interface for enumerating entries by key prefix. This method enables efficient prefix scanning, which is useful for implementing features like distributed trace storage, cache invalidation by prefix, and listing related entries.

interface KvStore {
  // ... existing methods
  list?(prefix?: KvKey): AsyncIterable<KvStoreListEntry>;
}

When the prefix parameter is omitted or empty, list() returns all entries in the store. This is useful for debugging and administrative purposes. All official KvStore implementations have been updated to support this method:

• MemoryKvStore — filters in-memory keys by prefix
• SqliteKvStore — uses LIKE query with JSON key pattern
• PostgresKvStore — uses array slice comparison
• RedisKvStore — uses SCAN with pattern matching and key deserialization
• DenoKvStore — delegates to Deno KV's built-in list() API
• WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

While list() is currently optional to give existing custom KvStore implementations time to add support, it will become a required method in Fedify 2.0.0 (tracked in issue #499). This migration path allows implementers to gradually adopt the new capability throughout the 1.x release cycle.

The addition of list() support was implemented in pull request #500, which also included the setup of proper testing infrastructure for WorkersKvStore using Vitest with @cloudflare/vitest-pool-workers.

NestJS 11 and Express 5 support

Thanks to a contribution from Cho Hasang (@crohasang), the @fedify/nestjs package now supports NestJS 11 environments that use Express 5. The peer dependency range for Express has been widened to ^4.0.0 || ^5.0.0, eliminating peer dependency conflicts in modern NestJS projects while maintaining backward compatibility with Express 4.

This change, implemented in pull request #493, keeps the workspace catalog pinned to Express 4 for internal development and test stability while allowing Express 5 in consuming applications.

What's next

Fedify 1.10.0 serves as a stepping stone toward the upcoming 2.0.0 release. The optional list() method introduced in this version will become required in 2.0.0, simplifying the interface contract and allowing Fedify internals to rely on prefix scanning being universally available.

The enhanced #OpenTelemetry instrumentation and FedifySpanExporter provide the foundation for implementing the debug dashboard proposed in issue #234. The next steps include building the web dashboard UI with real-time activity lists, filtering, and JSON inspection capabilities—all as a separate package that leverages the standards-based observability infrastructure introduced in this release.

Depending on the development timeline and feature priorities, there may be additional 1.x releases before the 2.0.0 migration. For developers building custom KvStore implementations, now is the time to add list() support to prepare for the eventual 2.0.0 upgrade. The implementation patterns used in the official backends provide clear guidance for various storage strategies.

Acknowledgments

Special thanks to Cho Hasang (@crohasang) for the NestJS 11 compatibility improvements, and to all community members who provided feedback and testing for the new observability features.

For the complete list of changes, bug fixes, and improvements, please refer to the CHANGES.md file in the repository.

#fedidev #release

Fedify 1.10.0: Observability foundations for the future debug dashboard

Fedify is a #TypeScript framework for building #ActivityPub servers that participate in the #fediverse. It reduces the complexity and boilerplate typically required for ActivityPub implementation while providing comprehensive federation capabilities.

We're excited to announce #Fedify 1.10.0, a focused release that lays critical groundwork for future debugging and observability features. Released on December 24, 2025, this version introduces infrastructure improvements that will enable the upcoming debug dashboard while maintaining full backward compatibility with existing Fedify applications.

This release represents a transitional step toward Fedify 2.0.0, introducing optional capabilities that will become standard in the next major version. The changes focus on enabling richer observability through OpenTelemetry enhancements and adding prefix scanning capabilities to the key–value store interface.

Enhanced OpenTelemetry instrumentation

Fedify 1.10.0 significantly expands OpenTelemetry instrumentation with span events that capture detailed ActivityPub data. These enhancements enable richer observability and debugging capabilities without relying solely on span attributes, which are limited to primitive values.

The new span events provide complete activity payloads and verification status, making it possible to build comprehensive debugging tools that show the full context of federation operations:

• activitypub.activity.received event on activitypub.inbox span — records the full activity JSON, verification status (activity verified, HTTP signatures verified, Linked Data signatures verified), and actor information
• activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
• activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

• activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
• activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These instrumentation improvements emerged from work on issue #234 (Real-time ActivityPub debug dashboard). Rather than introducing a custom observer interface as originally proposed in #323, we leveraged Fedify's existing OpenTelemetry infrastructure to capture rich federation data through span events. This approach provides a standards-based foundation that's composable with existing observability tools like Jaeger, Zipkin, and Grafana Tempo.

Distributed trace storage with FedifySpanExporter

Building on the enhanced instrumentation, Fedify 1.10.0 introduces FedifySpanExporter, a new OpenTelemetry SpanExporter that persists ActivityPub activity traces to a KvStore. This enables distributed tracing support across multiple nodes in a Fedify deployment, which is essential for building debug dashboards that can show complete request flows across web servers and background workers.

The new @fedify/fedify/otel module provides the following types and interfaces:

import { MemoryKvStore } from "@fedify/fedify";
import { FedifySpanExporter } from "@fedify/fedify/otel";
import {
  BasicTracerProvider,
  SimpleSpanProcessor,
} from "@opentelemetry/sdk-trace-base";

const kv = new MemoryKvStore();
const exporter = new FedifySpanExporter(kv, {
  ttl: Temporal.Duration.from({ hours: 1 }),
});

const provider = new BasicTracerProvider();
provider.addSpanProcessor(new SimpleSpanProcessor(exporter));

The stored traces can be queried for display in debugging interfaces:

// Get all activities for a specific trace
const activities = await exporter.getActivitiesByTraceId(traceId);

// Get recent traces with summary information
const recentTraces = await exporter.getRecentTraces({ limit: 100 });

The exporter supports two storage strategies depending on the KvStore capabilities. When the list() method is available (preferred), it stores individual records with keys like [prefix, traceId, spanId]. When only cas() is available, it uses compare-and-swap operations to append records to arrays stored per trace.

This infrastructure provides the foundation for implementing a comprehensive debug dashboard as a custom SpanExporter, as outlined in the updated implementation plan for issue #234.

Optional list() method for KvStore interface

Fedify 1.10.0 adds an optional list() method to the KvStore interface for enumerating entries by key prefix. This method enables efficient prefix scanning, which is useful for implementing features like distributed trace storage, cache invalidation by prefix, and listing related entries.

interface KvStore {
  // ... existing methods
  list?(prefix?: KvKey): AsyncIterable<KvStoreListEntry>;
}

When the prefix parameter is omitted or empty, list() returns all entries in the store. This is useful for debugging and administrative purposes. All official KvStore implementations have been updated to support this method:

• MemoryKvStore — filters in-memory keys by prefix
• SqliteKvStore — uses LIKE query with JSON key pattern
• PostgresKvStore — uses array slice comparison
• RedisKvStore — uses SCAN with pattern matching and key deserialization
• DenoKvStore — delegates to Deno KV's built-in list() API
• WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

While list() is currently optional to give existing custom KvStore implementations time to add support, it will become a required method in Fedify 2.0.0 (tracked in issue #499). This migration path allows implementers to gradually adopt the new capability throughout the 1.x release cycle.

The addition of list() support was implemented in pull request #500, which also included the setup of proper testing infrastructure for WorkersKvStore using Vitest with @cloudflare/vitest-pool-workers.

NestJS 11 and Express 5 support

Thanks to a contribution from Cho Hasang (@crohasang), the @fedify/nestjs package now supports NestJS 11 environments that use Express 5. The peer dependency range for Express has been widened to ^4.0.0 || ^5.0.0, eliminating peer dependency conflicts in modern NestJS projects while maintaining backward compatibility with Express 4.

This change, implemented in pull request #493, keeps the workspace catalog pinned to Express 4 for internal development and test stability while allowing Express 5 in consuming applications.

What's next

Fedify 1.10.0 serves as a stepping stone toward the upcoming 2.0.0 release. The optional list() method introduced in this version will become required in 2.0.0, simplifying the interface contract and allowing Fedify internals to rely on prefix scanning being universally available.

The enhanced #OpenTelemetry instrumentation and FedifySpanExporter provide the foundation for implementing the debug dashboard proposed in issue #234. The next steps include building the web dashboard UI with real-time activity lists, filtering, and JSON inspection capabilities—all as a separate package that leverages the standards-based observability infrastructure introduced in this release.

Depending on the development timeline and feature priorities, there may be additional 1.x releases before the 2.0.0 migration. For developers building custom KvStore implementations, now is the time to add list() support to prepare for the eventual 2.0.0 upgrade. The implementation patterns used in the official backends provide clear guidance for various storage strategies.

Acknowledgments

Special thanks to Cho Hasang (@crohasang) for the NestJS 11 compatibility improvements, and to all community members who provided feedback and testing for the new observability features.

For the complete list of changes, bug fixes, and improvements, please refer to the CHANGES.md file in the repository.

#fedidev #release

Fedify 1.10.0: Observability foundations for the future debug dashboard

Fedify is a #TypeScript framework for building #ActivityPub servers that participate in the #fediverse. It reduces the complexity and boilerplate typically required for ActivityPub implementation while providing comprehensive federation capabilities.

We're excited to announce #Fedify 1.10.0, a focused release that lays critical groundwork for future debugging and observability features. Released on December 24, 2025, this version introduces infrastructure improvements that will enable the upcoming debug dashboard while maintaining full backward compatibility with existing Fedify applications.

This release represents a transitional step toward Fedify 2.0.0, introducing optional capabilities that will become standard in the next major version. The changes focus on enabling richer observability through OpenTelemetry enhancements and adding prefix scanning capabilities to the key–value store interface.

Enhanced OpenTelemetry instrumentation

Fedify 1.10.0 significantly expands OpenTelemetry instrumentation with span events that capture detailed ActivityPub data. These enhancements enable richer observability and debugging capabilities without relying solely on span attributes, which are limited to primitive values.

The new span events provide complete activity payloads and verification status, making it possible to build comprehensive debugging tools that show the full context of federation operations:

• activitypub.activity.received event on activitypub.inbox span — records the full activity JSON, verification status (activity verified, HTTP signatures verified, Linked Data signatures verified), and actor information
• activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
• activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

• activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
• activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These instrumentation improvements emerged from work on issue #234 (Real-time ActivityPub debug dashboard). Rather than introducing a custom observer interface as originally proposed in #323, we leveraged Fedify's existing OpenTelemetry infrastructure to capture rich federation data through span events. This approach provides a standards-based foundation that's composable with existing observability tools like Jaeger, Zipkin, and Grafana Tempo.

Distributed trace storage with FedifySpanExporter

Building on the enhanced instrumentation, Fedify 1.10.0 introduces FedifySpanExporter, a new OpenTelemetry SpanExporter that persists ActivityPub activity traces to a KvStore. This enables distributed tracing support across multiple nodes in a Fedify deployment, which is essential for building debug dashboards that can show complete request flows across web servers and background workers.

The new @fedify/fedify/otel module provides the following types and interfaces:

import { MemoryKvStore } from "@fedify/fedify";
import { FedifySpanExporter } from "@fedify/fedify/otel";
import {
  BasicTracerProvider,
  SimpleSpanProcessor,
} from "@opentelemetry/sdk-trace-base";

const kv = new MemoryKvStore();
const exporter = new FedifySpanExporter(kv, {
  ttl: Temporal.Duration.from({ hours: 1 }),
});

const provider = new BasicTracerProvider();
provider.addSpanProcessor(new SimpleSpanProcessor(exporter));

The stored traces can be queried for display in debugging interfaces:

// Get all activities for a specific trace
const activities = await exporter.getActivitiesByTraceId(traceId);

// Get recent traces with summary information
const recentTraces = await exporter.getRecentTraces({ limit: 100 });

The exporter supports two storage strategies depending on the KvStore capabilities. When the list() method is available (preferred), it stores individual records with keys like [prefix, traceId, spanId]. When only cas() is available, it uses compare-and-swap operations to append records to arrays stored per trace.

This infrastructure provides the foundation for implementing a comprehensive debug dashboard as a custom SpanExporter, as outlined in the updated implementation plan for issue #234.

Optional list() method for KvStore interface

Fedify 1.10.0 adds an optional list() method to the KvStore interface for enumerating entries by key prefix. This method enables efficient prefix scanning, which is useful for implementing features like distributed trace storage, cache invalidation by prefix, and listing related entries.

interface KvStore {
  // ... existing methods
  list?(prefix?: KvKey): AsyncIterable<KvStoreListEntry>;
}

When the prefix parameter is omitted or empty, list() returns all entries in the store. This is useful for debugging and administrative purposes. All official KvStore implementations have been updated to support this method:

• MemoryKvStore — filters in-memory keys by prefix
• SqliteKvStore — uses LIKE query with JSON key pattern
• PostgresKvStore — uses array slice comparison
• RedisKvStore — uses SCAN with pattern matching and key deserialization
• DenoKvStore — delegates to Deno KV's built-in list() API
• WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

While list() is currently optional to give existing custom KvStore implementations time to add support, it will become a required method in Fedify 2.0.0 (tracked in issue #499). This migration path allows implementers to gradually adopt the new capability throughout the 1.x release cycle.

The addition of list() support was implemented in pull request #500, which also included the setup of proper testing infrastructure for WorkersKvStore using Vitest with @cloudflare/vitest-pool-workers.

NestJS 11 and Express 5 support

Thanks to a contribution from Cho Hasang (@crohasang), the @fedify/nestjs package now supports NestJS 11 environments that use Express 5. The peer dependency range for Express has been widened to ^4.0.0 || ^5.0.0, eliminating peer dependency conflicts in modern NestJS projects while maintaining backward compatibility with Express 4.

This change, implemented in pull request #493, keeps the workspace catalog pinned to Express 4 for internal development and test stability while allowing Express 5 in consuming applications.

What's next

Fedify 1.10.0 serves as a stepping stone toward the upcoming 2.0.0 release. The optional list() method introduced in this version will become required in 2.0.0, simplifying the interface contract and allowing Fedify internals to rely on prefix scanning being universally available.

The enhanced #OpenTelemetry instrumentation and FedifySpanExporter provide the foundation for implementing the debug dashboard proposed in issue #234. The next steps include building the web dashboard UI with real-time activity lists, filtering, and JSON inspection capabilities—all as a separate package that leverages the standards-based observability infrastructure introduced in this release.

Depending on the development timeline and feature priorities, there may be additional 1.x releases before the 2.0.0 migration. For developers building custom KvStore implementations, now is the time to add list() support to prepare for the eventual 2.0.0 upgrade. The implementation patterns used in the official backends provide clear guidance for various storage strategies.

Acknowledgments

Special thanks to Cho Hasang (@crohasang) for the NestJS 11 compatibility improvements, and to all community members who provided feedback and testing for the new observability features.

For the complete list of changes, bug fixes, and improvements, please refer to the CHANGES.md file in the repository.

#fedidev #release

Fedify 1.10.0: Observability foundations for the future debug dashboard

Fedify is a #TypeScript framework for building #ActivityPub servers that participate in the #fediverse. It reduces the complexity and boilerplate typically required for ActivityPub implementation while providing comprehensive federation capabilities.

We're excited to announce #Fedify 1.10.0, a focused release that lays critical groundwork for future debugging and observability features. Released on December 24, 2025, this version introduces infrastructure improvements that will enable the upcoming debug dashboard while maintaining full backward compatibility with existing Fedify applications.

This release represents a transitional step toward Fedify 2.0.0, introducing optional capabilities that will become standard in the next major version. The changes focus on enabling richer observability through OpenTelemetry enhancements and adding prefix scanning capabilities to the key–value store interface.

Enhanced OpenTelemetry instrumentation

Fedify 1.10.0 significantly expands OpenTelemetry instrumentation with span events that capture detailed ActivityPub data. These enhancements enable richer observability and debugging capabilities without relying solely on span attributes, which are limited to primitive values.

The new span events provide complete activity payloads and verification status, making it possible to build comprehensive debugging tools that show the full context of federation operations:

• activitypub.activity.received event on activitypub.inbox span — records the full activity JSON, verification status (activity verified, HTTP signatures verified, Linked Data signatures verified), and actor information
• activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
• activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

• activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
• activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These instrumentation improvements emerged from work on issue #234 (Real-time ActivityPub debug dashboard). Rather than introducing a custom observer interface as originally proposed in #323, we leveraged Fedify's existing OpenTelemetry infrastructure to capture rich federation data through span events. This approach provides a standards-based foundation that's composable with existing observability tools like Jaeger, Zipkin, and Grafana Tempo.

Distributed trace storage with FedifySpanExporter

Building on the enhanced instrumentation, Fedify 1.10.0 introduces FedifySpanExporter, a new OpenTelemetry SpanExporter that persists ActivityPub activity traces to a KvStore. This enables distributed tracing support across multiple nodes in a Fedify deployment, which is essential for building debug dashboards that can show complete request flows across web servers and background workers.

The new @fedify/fedify/otel module provides the following types and interfaces:

import { MemoryKvStore } from "@fedify/fedify";
import { FedifySpanExporter } from "@fedify/fedify/otel";
import {
  BasicTracerProvider,
  SimpleSpanProcessor,
} from "@opentelemetry/sdk-trace-base";

const kv = new MemoryKvStore();
const exporter = new FedifySpanExporter(kv, {
  ttl: Temporal.Duration.from({ hours: 1 }),
});

const provider = new BasicTracerProvider();
provider.addSpanProcessor(new SimpleSpanProcessor(exporter));

The stored traces can be queried for display in debugging interfaces:

// Get all activities for a specific trace
const activities = await exporter.getActivitiesByTraceId(traceId);

// Get recent traces with summary information
const recentTraces = await exporter.getRecentTraces({ limit: 100 });

The exporter supports two storage strategies depending on the KvStore capabilities. When the list() method is available (preferred), it stores individual records with keys like [prefix, traceId, spanId]. When only cas() is available, it uses compare-and-swap operations to append records to arrays stored per trace.

This infrastructure provides the foundation for implementing a comprehensive debug dashboard as a custom SpanExporter, as outlined in the updated implementation plan for issue #234.

Optional list() method for KvStore interface

Fedify 1.10.0 adds an optional list() method to the KvStore interface for enumerating entries by key prefix. This method enables efficient prefix scanning, which is useful for implementing features like distributed trace storage, cache invalidation by prefix, and listing related entries.

interface KvStore {
  // ... existing methods
  list?(prefix?: KvKey): AsyncIterable<KvStoreListEntry>;
}

When the prefix parameter is omitted or empty, list() returns all entries in the store. This is useful for debugging and administrative purposes. All official KvStore implementations have been updated to support this method:

• MemoryKvStore — filters in-memory keys by prefix
• SqliteKvStore — uses LIKE query with JSON key pattern
• PostgresKvStore — uses array slice comparison
• RedisKvStore — uses SCAN with pattern matching and key deserialization
• DenoKvStore — delegates to Deno KV's built-in list() API
• WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

While list() is currently optional to give existing custom KvStore implementations time to add support, it will become a required method in Fedify 2.0.0 (tracked in issue #499). This migration path allows implementers to gradually adopt the new capability throughout the 1.x release cycle.

The addition of list() support was implemented in pull request #500, which also included the setup of proper testing infrastructure for WorkersKvStore using Vitest with @cloudflare/vitest-pool-workers.

NestJS 11 and Express 5 support

Thanks to a contribution from Cho Hasang (@crohasang), the @fedify/nestjs package now supports NestJS 11 environments that use Express 5. The peer dependency range for Express has been widened to ^4.0.0 || ^5.0.0, eliminating peer dependency conflicts in modern NestJS projects while maintaining backward compatibility with Express 4.

This change, implemented in pull request #493, keeps the workspace catalog pinned to Express 4 for internal development and test stability while allowing Express 5 in consuming applications.

What's next

Fedify 1.10.0 serves as a stepping stone toward the upcoming 2.0.0 release. The optional list() method introduced in this version will become required in 2.0.0, simplifying the interface contract and allowing Fedify internals to rely on prefix scanning being universally available.

The enhanced #OpenTelemetry instrumentation and FedifySpanExporter provide the foundation for implementing the debug dashboard proposed in issue #234. The next steps include building the web dashboard UI with real-time activity lists, filtering, and JSON inspection capabilities—all as a separate package that leverages the standards-based observability infrastructure introduced in this release.

Depending on the development timeline and feature priorities, there may be additional 1.x releases before the 2.0.0 migration. For developers building custom KvStore implementations, now is the time to add list() support to prepare for the eventual 2.0.0 upgrade. The implementation patterns used in the official backends provide clear guidance for various storage strategies.

Acknowledgments

Special thanks to Cho Hasang (@crohasang) for the NestJS 11 compatibility improvements, and to all community members who provided feedback and testing for the new observability features.

For the complete list of changes, bug fixes, and improvements, please refer to the CHANGES.md file in the repository.

#fedidev #release

Fedify 1.10.0: Observability foundations for the future debug dashboard

Fedify is a #TypeScript framework for building #ActivityPub servers that participate in the #fediverse. It reduces the complexity and boilerplate typically required for ActivityPub implementation while providing comprehensive federation capabilities.

We're excited to announce #Fedify 1.10.0, a focused release that lays critical groundwork for future debugging and observability features. Released on December 24, 2025, this version introduces infrastructure improvements that will enable the upcoming debug dashboard while maintaining full backward compatibility with existing Fedify applications.

This release represents a transitional step toward Fedify 2.0.0, introducing optional capabilities that will become standard in the next major version. The changes focus on enabling richer observability through OpenTelemetry enhancements and adding prefix scanning capabilities to the key–value store interface.

Enhanced OpenTelemetry instrumentation

Fedify 1.10.0 significantly expands OpenTelemetry instrumentation with span events that capture detailed ActivityPub data. These enhancements enable richer observability and debugging capabilities without relying solely on span attributes, which are limited to primitive values.

The new span events provide complete activity payloads and verification status, making it possible to build comprehensive debugging tools that show the full context of federation operations:

• activitypub.activity.received event on activitypub.inbox span — records the full activity JSON, verification status (activity verified, HTTP signatures verified, Linked Data signatures verified), and actor information
• activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
• activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

• activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
• activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These instrumentation improvements emerged from work on issue #234 (Real-time ActivityPub debug dashboard). Rather than introducing a custom observer interface as originally proposed in #323, we leveraged Fedify's existing OpenTelemetry infrastructure to capture rich federation data through span events. This approach provides a standards-based foundation that's composable with existing observability tools like Jaeger, Zipkin, and Grafana Tempo.

Distributed trace storage with FedifySpanExporter

Building on the enhanced instrumentation, Fedify 1.10.0 introduces FedifySpanExporter, a new OpenTelemetry SpanExporter that persists ActivityPub activity traces to a KvStore. This enables distributed tracing support across multiple nodes in a Fedify deployment, which is essential for building debug dashboards that can show complete request flows across web servers and background workers.

The new @fedify/fedify/otel module provides the following types and interfaces:

import { MemoryKvStore } from "@fedify/fedify";
import { FedifySpanExporter } from "@fedify/fedify/otel";
import {
  BasicTracerProvider,
  SimpleSpanProcessor,
} from "@opentelemetry/sdk-trace-base";

const kv = new MemoryKvStore();
const exporter = new FedifySpanExporter(kv, {
  ttl: Temporal.Duration.from({ hours: 1 }),
});

const provider = new BasicTracerProvider();
provider.addSpanProcessor(new SimpleSpanProcessor(exporter));

The stored traces can be queried for display in debugging interfaces:

// Get all activities for a specific trace
const activities = await exporter.getActivitiesByTraceId(traceId);

// Get recent traces with summary information
const recentTraces = await exporter.getRecentTraces({ limit: 100 });

The exporter supports two storage strategies depending on the KvStore capabilities. When the list() method is available (preferred), it stores individual records with keys like [prefix, traceId, spanId]. When only cas() is available, it uses compare-and-swap operations to append records to arrays stored per trace.

This infrastructure provides the foundation for implementing a comprehensive debug dashboard as a custom SpanExporter, as outlined in the updated implementation plan for issue #234.

Optional list() method for KvStore interface

Fedify 1.10.0 adds an optional list() method to the KvStore interface for enumerating entries by key prefix. This method enables efficient prefix scanning, which is useful for implementing features like distributed trace storage, cache invalidation by prefix, and listing related entries.

interface KvStore {
  // ... existing methods
  list?(prefix?: KvKey): AsyncIterable<KvStoreListEntry>;
}

When the prefix parameter is omitted or empty, list() returns all entries in the store. This is useful for debugging and administrative purposes. All official KvStore implementations have been updated to support this method:

• MemoryKvStore — filters in-memory keys by prefix
• SqliteKvStore — uses LIKE query with JSON key pattern
• PostgresKvStore — uses array slice comparison
• RedisKvStore — uses SCAN with pattern matching and key deserialization
• DenoKvStore — delegates to Deno KV's built-in list() API
• WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

While list() is currently optional to give existing custom KvStore implementations time to add support, it will become a required method in Fedify 2.0.0 (tracked in issue #499). This migration path allows implementers to gradually adopt the new capability throughout the 1.x release cycle.

The addition of list() support was implemented in pull request #500, which also included the setup of proper testing infrastructure for WorkersKvStore using Vitest with @cloudflare/vitest-pool-workers.

NestJS 11 and Express 5 support

Thanks to a contribution from Cho Hasang (@crohasang), the @fedify/nestjs package now supports NestJS 11 environments that use Express 5. The peer dependency range for Express has been widened to ^4.0.0 || ^5.0.0, eliminating peer dependency conflicts in modern NestJS projects while maintaining backward compatibility with Express 4.

This change, implemented in pull request #493, keeps the workspace catalog pinned to Express 4 for internal development and test stability while allowing Express 5 in consuming applications.

What's next

Fedify 1.10.0 serves as a stepping stone toward the upcoming 2.0.0 release. The optional list() method introduced in this version will become required in 2.0.0, simplifying the interface contract and allowing Fedify internals to rely on prefix scanning being universally available.

The enhanced #OpenTelemetry instrumentation and FedifySpanExporter provide the foundation for implementing the debug dashboard proposed in issue #234. The next steps include building the web dashboard UI with real-time activity lists, filtering, and JSON inspection capabilities—all as a separate package that leverages the standards-based observability infrastructure introduced in this release.

Depending on the development timeline and feature priorities, there may be additional 1.x releases before the 2.0.0 migration. For developers building custom KvStore implementations, now is the time to add list() support to prepare for the eventual 2.0.0 upgrade. The implementation patterns used in the official backends provide clear guidance for various storage strategies.

Acknowledgments

Special thanks to Cho Hasang (@crohasang) for the NestJS 11 compatibility improvements, and to all community members who provided feedback and testing for the new observability features.

For the complete list of changes, bug fixes, and improvements, please refer to the CHANGES.md file in the repository.

#fedidev #release

Fedify 1.10.0: Observability foundations for the future debug dashboard

Fedify is a #TypeScript framework for building #ActivityPub servers that participate in the #fediverse. It reduces the complexity and boilerplate typically required for ActivityPub implementation while providing comprehensive federation capabilities.

We're excited to announce #Fedify 1.10.0, a focused release that lays critical groundwork for future debugging and observability features. Released on December 24, 2025, this version introduces infrastructure improvements that will enable the upcoming debug dashboard while maintaining full backward compatibility with existing Fedify applications.

This release represents a transitional step toward Fedify 2.0.0, introducing optional capabilities that will become standard in the next major version. The changes focus on enabling richer observability through OpenTelemetry enhancements and adding prefix scanning capabilities to the key–value store interface.

Enhanced OpenTelemetry instrumentation

Fedify 1.10.0 significantly expands OpenTelemetry instrumentation with span events that capture detailed ActivityPub data. These enhancements enable richer observability and debugging capabilities without relying solely on span attributes, which are limited to primitive values.

The new span events provide complete activity payloads and verification status, making it possible to build comprehensive debugging tools that show the full context of federation operations:

• activitypub.activity.received event on activitypub.inbox span — records the full activity JSON, verification status (activity verified, HTTP signatures verified, Linked Data signatures verified), and actor information
• activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
• activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

• activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
• activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These instrumentation improvements emerged from work on issue #234 (Real-time ActivityPub debug dashboard). Rather than introducing a custom observer interface as originally proposed in #323, we leveraged Fedify's existing OpenTelemetry infrastructure to capture rich federation data through span events. This approach provides a standards-based foundation that's composable with existing observability tools like Jaeger, Zipkin, and Grafana Tempo.

Distributed trace storage with FedifySpanExporter

Building on the enhanced instrumentation, Fedify 1.10.0 introduces FedifySpanExporter, a new OpenTelemetry SpanExporter that persists ActivityPub activity traces to a KvStore. This enables distributed tracing support across multiple nodes in a Fedify deployment, which is essential for building debug dashboards that can show complete request flows across web servers and background workers.

The new @fedify/fedify/otel module provides the following types and interfaces:

import { MemoryKvStore } from "@fedify/fedify";
import { FedifySpanExporter } from "@fedify/fedify/otel";
import {
  BasicTracerProvider,
  SimpleSpanProcessor,
} from "@opentelemetry/sdk-trace-base";

const kv = new MemoryKvStore();
const exporter = new FedifySpanExporter(kv, {
  ttl: Temporal.Duration.from({ hours: 1 }),
});

const provider = new BasicTracerProvider();
provider.addSpanProcessor(new SimpleSpanProcessor(exporter));

The stored traces can be queried for display in debugging interfaces:

// Get all activities for a specific trace
const activities = await exporter.getActivitiesByTraceId(traceId);

// Get recent traces with summary information
const recentTraces = await exporter.getRecentTraces({ limit: 100 });

The exporter supports two storage strategies depending on the KvStore capabilities. When the list() method is available (preferred), it stores individual records with keys like [prefix, traceId, spanId]. When only cas() is available, it uses compare-and-swap operations to append records to arrays stored per trace.

This infrastructure provides the foundation for implementing a comprehensive debug dashboard as a custom SpanExporter, as outlined in the updated implementation plan for issue #234.

Optional list() method for KvStore interface

Fedify 1.10.0 adds an optional list() method to the KvStore interface for enumerating entries by key prefix. This method enables efficient prefix scanning, which is useful for implementing features like distributed trace storage, cache invalidation by prefix, and listing related entries.

interface KvStore {
  // ... existing methods
  list?(prefix?: KvKey): AsyncIterable<KvStoreListEntry>;
}

When the prefix parameter is omitted or empty, list() returns all entries in the store. This is useful for debugging and administrative purposes. All official KvStore implementations have been updated to support this method:

• MemoryKvStore — filters in-memory keys by prefix
• SqliteKvStore — uses LIKE query with JSON key pattern
• PostgresKvStore — uses array slice comparison
• RedisKvStore — uses SCAN with pattern matching and key deserialization
• DenoKvStore — delegates to Deno KV's built-in list() API
• WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

While list() is currently optional to give existing custom KvStore implementations time to add support, it will become a required method in Fedify 2.0.0 (tracked in issue #499). This migration path allows implementers to gradually adopt the new capability throughout the 1.x release cycle.

The addition of list() support was implemented in pull request #500, which also included the setup of proper testing infrastructure for WorkersKvStore using Vitest with @cloudflare/vitest-pool-workers.

NestJS 11 and Express 5 support

Thanks to a contribution from Cho Hasang (@crohasang), the @fedify/nestjs package now supports NestJS 11 environments that use Express 5. The peer dependency range for Express has been widened to ^4.0.0 || ^5.0.0, eliminating peer dependency conflicts in modern NestJS projects while maintaining backward compatibility with Express 4.

This change, implemented in pull request #493, keeps the workspace catalog pinned to Express 4 for internal development and test stability while allowing Express 5 in consuming applications.

What's next

Fedify 1.10.0 serves as a stepping stone toward the upcoming 2.0.0 release. The optional list() method introduced in this version will become required in 2.0.0, simplifying the interface contract and allowing Fedify internals to rely on prefix scanning being universally available.

The enhanced #OpenTelemetry instrumentation and FedifySpanExporter provide the foundation for implementing the debug dashboard proposed in issue #234. The next steps include building the web dashboard UI with real-time activity lists, filtering, and JSON inspection capabilities—all as a separate package that leverages the standards-based observability infrastructure introduced in this release.

Depending on the development timeline and feature priorities, there may be additional 1.x releases before the 2.0.0 migration. For developers building custom KvStore implementations, now is the time to add list() support to prepare for the eventual 2.0.0 upgrade. The implementation patterns used in the official backends provide clear guidance for various storage strategies.

Acknowledgments

Special thanks to Cho Hasang (@crohasang) for the NestJS 11 compatibility improvements, and to all community members who provided feedback and testing for the new observability features.

For the complete list of changes, bug fixes, and improvements, please refer to the CHANGES.md file in the repository.

#fedidev #release

Introducing Open Forms via @federicoschonborn https://lobste.rs/s/mvqno1 #release
https://www.aryank.in/posts/2025-12-21-introducing-open-forms/

OUT NOW: Dungeon Puzzle Sweeper!

The perfect game to play at the airport or under the dinner table this holiday season 🎄 It auto-saves, is optimized for mobile, and has online leaderboards!

This little remake has been kicking around all year and I wanted to finish up the rest of the presentation and get it out there. Free on itch!!

https://britown.itch.io/sweeper

Please boost and tell your friends!

#gamedev #indiegame #itch #release #minesweeper

OUT NOW: Dungeon Puzzle Sweeper!

The perfect game to play at the airport or under the dinner table this holiday season 🎄 It auto-saves, is optimized for mobile, and has online leaderboards!

This little remake has been kicking around all year and I wanted to finish up the rest of the presentation and get it out there. Free on itch!!

https://britown.itch.io/sweeper

Please boost and tell your friends!

#gamedev #indiegame #itch #release #minesweeper

Mbin 1.9.0 stable is finally out! Thank you everybody who made this release possible!

See the link for the full upgrade instructions.

#mbin #kbin #new #release

🚀 Vernissage 1.26.0 is out today!

API updates:
- Migration to Swift 6.2
- Renamed unit test titles (less code duplication)
- GPT-5.2 support (optional ALT text & hashtag generation by the photo author)
- All dependencies updated

Web client:
- Upgrade to Angular 21 (getting closer to zoneless 😉)
- Fixed bug after canceling photo upload
- All dependencies updated

🙏 Thanks for all the help and valuable feedback!

#Vernissage #Release #Swift #Angular #Fediverse #Photography #PhotoSharing

🚀 Vernissage 1.26.0 is out today!

API updates:
- Migration to Swift 6.2
- Renamed unit test titles (less code duplication)
- GPT-5.2 support (optional ALT text & hashtag generation by the photo author)
- All dependencies updated

Web client:
- Upgrade to Angular 21 (getting closer to zoneless 😉)
- Fixed bug after canceling photo upload
- All dependencies updated

🙏 Thanks for all the help and valuable feedback!

#Vernissage #Release #Swift #Angular #Fediverse #Photography #PhotoSharing

🚀 Vernissage 1.26.0 is out today!

API updates:
- Migration to Swift 6.2
- Renamed unit test titles (less code duplication)
- GPT-5.2 support (optional ALT text & hashtag generation by the photo author)
- All dependencies updated

Web client:
- Upgrade to Angular 21 (getting closer to zoneless 😉)
- Fixed bug after canceling photo upload
- All dependencies updated

🙏 Thanks for all the help and valuable feedback!

#Vernissage #Release #Swift #Angular #Fediverse #Photography #PhotoSharing

🚀 Vernissage 1.26.0 is out today!

API updates:
- Migration to Swift 6.2
- Renamed unit test titles (less code duplication)
- GPT-5.2 support (optional ALT text & hashtag generation by the photo author)
- All dependencies updated

Web client:
- Upgrade to Angular 21 (getting closer to zoneless 😉)
- Fixed bug after canceling photo upload
- All dependencies updated

🙏 Thanks for all the help and valuable feedback!

#Vernissage #Release #Swift #Angular #Fediverse #Photography #PhotoSharing

We've further improved Cinderward, our simple, no-nonsense, init-agnostic, Wayland-friendly GUI for firewalld, and released it as Cinderward v. 0.0.2.

The next release of Nitrux will include Cinderward (and thus, firewalld) by default.

https://github.com/Nitrux/cinderward

#Nitrux #Firewall #Release

Just released! 🚀🐍

Python 3.14.1

Waiting for the .1 to upgrade? This one's especially for you!

🥧 Deferred type annotation evaluation!
🥧 T-strings!
🥧 Zstandard!
🥧 Syntax highlighting in the REPL!
🥧 Colour in unittest, argparse, json and calendar CLIs!
🥧 UUID v6-8!
🥧 And much more!

https://discuss.python.org/t/python-3-14-1-is-now-available/105163

#Python #CPython #Python314 #release

Just released! 🚀🐍

Python 3.14.1

Waiting for the .1 to upgrade? This one's especially for you!

🥧 Deferred type annotation evaluation!
🥧 T-strings!
🥧 Zstandard!
🥧 Syntax highlighting in the REPL!
🥧 Colour in unittest, argparse, json and calendar CLIs!
🥧 UUID v6-8!
🥧 And much more!

https://discuss.python.org/t/python-3-14-1-is-now-available/105163

#Python #CPython #Python314 #release

🆕 pandoc 3.8.3 🎉

This release adds three new input formats (#Asciidoc, #PPTX, and #XLSX) and one new output format (#BBCode + variants).

It also fixes a number of bugs (including some regressions in 3.8). See the changelog for full details.

Thanks to all who contributed!

https://github.com/jgm/pandoc/releases/tag/3.8.3

#pandoc #release

🎉 New production release of OpenCloud

We are very excited about the new release, which features multi-tenancy, new Helm charts, Files on Demand, and a new UI design with dark mode.

A big thank you goes to our development team and everyone involved who made this release possible. 💚

Learn more about the new features: https://opencloud.eu/en/news/opencloud-production-release-multi-tenancy-helm-charts

#OpenCloud #Release #OpenSource #DigitalSovereignty #Teamwork

🎉 Neues Production Release von OpenCloud
Wir freuen uns sehr über das neue Release, mit Mandantenfähigkeit, neuen Helm-Charts, Files on Demand und einem neuen UI-Design mit Dark Mode.

Ein großer Dank geht an unser Entwicklerteam und alle Beteiligten, die dieses Release möglich gemacht haben. 💚

Erfahren Sie mehr über die Neuerungen: https://opencloud.eu/de/news/opencloud-production-release-von-mandantenfaehigkeit-bis-helm-charts

#OpenCloud #Release #OpenSource #DigitaleSouveränität #Teamwork

New 𝗩𝗮𝗹𝘂𝗮𝗯𝗹𝗲 𝗙𝗿𝗲𝗲𝗕𝗦𝗗 𝟭𝟱.𝟬-𝗥𝗘𝗟𝗘𝗔𝗦𝗘 𝗨𝗽𝗱𝗮𝘁𝗲𝘀 [Valuable FreeBSD 15.0-RELEASE Updates] article.

https://vermaden.wordpress.com/2025/11/30/valuable-freebsd-15-0-release-updates/

#verblog #freebsd #improvements #release #updates

🚀 Woodpecker 3.10.0 is live!
- Pull‑request metadata & task‑UUID labels for tighter CI pipelines
- New org‑listing API (CLI & Go SDK) + milestone support
- Smarter error traces, CLI auto‑completion & human‑readable queue info
- Dozens of dependency fixes

Upgrade now for a smoother CI experience! 🎉 #CI #DevOps #woodpeckerci #release

https://github.com/woodpecker-ci/woodpecker/releases/tag/v3.10.0

Just released! 🚀

🎶 pylast 7.0.0

🎤 A #Python interface to @lastfm and Libre.fm

🗑️ Remove `SCROBBLE_SOURCE_*` and `SCROBBLE_MODE_*` constants. Last used in 2017, you probably weren't using them

📻 Add `chosen_by_user` parameter to `scrobble`. Set to false if you don't have "direct" control over the source, like radio or a stream.

🐍 Add support for Python 3.15

📼 Test against recorded API instead of live

🦀 Replace pre-commit with prek

Thanks to @scy!

https://github.com/pylast/pylast/releases/tag/7.0.0
#release #LastFM

🥳 PHP 8.5 Released!

In this new release, we have:

🌐 URI Extension
▶️ Pipe Operator
📑 Clone With
⚠️ A New #[\NoDiscard] Attribute
🆕 Closures and First-Class Callables in Constant Expressions
🌀 Persistent cURL Share Handles

👓 Read all about it on: https://www.php.net/releases/8.5/

🔗 https://php.net/ChangeLog-8#8.5.0
📦 https://php.net/downloads

#PHP #PHP85 #Release

🥳 PHP 8.5 Released!

In this new release, we have:

🌐 URI Extension
▶️ Pipe Operator
📑 Clone With
⚠️ A New #[\NoDiscard] Attribute
🆕 Closures and First-Class Callables in Constant Expressions
🌀 Persistent cURL Share Handles

👓 Read all about it on: https://www.php.net/releases/8.5/

🔗 https://php.net/ChangeLog-8#8.5.0
📦 https://php.net/downloads

#PHP #PHP85 #Release

🥳 PHP 8.5 Released!

In this new release, we have:

🌐 URI Extension
▶️ Pipe Operator
📑 Clone With
⚠️ A New #[\NoDiscard] Attribute
🆕 Closures and First-Class Callables in Constant Expressions
🌀 Persistent cURL Share Handles

👓 Read all about it on: https://www.php.net/releases/8.5/

🔗 https://php.net/ChangeLog-8#8.5.0
📦 https://php.net/downloads

#PHP #PHP85 #Release

🥳 PHP 8.5 Released!

In this new release, we have:

🌐 URI Extension
▶️ Pipe Operator
📑 Clone With
⚠️ A New #[\NoDiscard] Attribute
🆕 Closures and First-Class Callables in Constant Expressions
🌀 Persistent cURL Share Handles

👓 Read all about it on: https://www.php.net/releases/8.5/

🔗 https://php.net/ChangeLog-8#8.5.0
📦 https://php.net/downloads

#PHP #PHP85 #Release

A new GTK 4 development snapshot with lots and lots of features is available: https://gitlab.gnome.org/GNOME/gtk/-/releases/4.21.2

#gtk #gtk4 #release #announcement

Just released! 🚀

After one sequential-only CI failure, two artifacts builds, one GitHub outage, two fixes for the Windows installer build, four Windows builds, and a NuGet outage:

🐍 Python 3.15 alpha 2!

🔬 PEP 799: A new high-frequency statistical sampling profiler
💬 PEP 686: Python now uses UTF-8 as the default encoding
🌊 PEP 782: A new PyBytesWriter C API to create a Python bytes object
⚠️ Better error messages

https://discuss.python.org/t/python-3-15-0a2/104948?u=hugovk

#Python #Python315 #CPython #release #PEP799 #PEP686

Just released! 🚀

After one sequential-only CI failure, two artifacts builds, one GitHub outage, two fixes for the Windows installer build, four Windows builds, and a NuGet outage:

🐍 Python 3.15 alpha 2!

🔬 PEP 799: A new high-frequency statistical sampling profiler
💬 PEP 686: Python now uses UTF-8 as the default encoding
🌊 PEP 782: A new PyBytesWriter C API to create a Python bytes object
⚠️ Better error messages

https://discuss.python.org/t/python-3-15-0a2/104948?u=hugovk

#Python #Python315 #CPython #release #PEP799 #PEP686

🚀 WoodpeckerCI 3.12.0 is here! Get full commit changes in Bitbucket pushes, support file changes in Bitbucket Cloud, agent version logging & improved log streaming. Plus many bug fixes & security updates! Upgrade now! 🔒🐦 #WoodpeckerCI #release #CI #DevOps #Changelog

Movim 0.32, codename Wilk is out ✨

This might be one of the biggest release ever made on the project.

We improved the way to follow, publish, upload share and comment content 🗒️but also redesigned the chat layout 🗨️, refactored the end-to-end-encryption code 🔒, improved our bridges integration 🌉, dropping dependencies 🧹 and improving video-conferencing performances 📹

Checkout the release note to have all the details of this exciting release 🤩

https://mov.im/community/pubsub.movim.eu/Movim/here-comes-movim-0-32-codename-wilk-CBbSYh

If you really like the project don't forget to share the good new around and support us, you will find all the link on our main website ❤️

#movim #xmpp #release

Movim 0.32, codename Wilk is out ✨

This might be one of the biggest release ever made on the project.

We improved the way to follow, publish, upload share and comment content 🗒️but also redesigned the chat layout 🗨️, refactored the end-to-end-encryption code 🔒, improved our bridges integration 🌉, dropping dependencies 🧹 and improving video-conferencing performances 📹

Checkout the release note to have all the details of this exciting release 🤩

https://mov.im/community/pubsub.movim.eu/Movim/here-comes-movim-0-32-codename-wilk-CBbSYh

If you really like the project don't forget to share the good new around and support us, you will find all the link on our main website ❤️

#movim #xmpp #release

Just released! 🚀

🪑 PrettyTable 3.17.0

https://github.com/prettytable/prettytable/releases/tag/3.17.0

Add support for Python 3.15, drop 3.9, test 3.13t-3.15t
Set dicts with column-specific config for all column-specific attrs
Update type hints
Replace pre-commit with prek
& more!

#Python #release #PrettyTable #Python315 #Python39

New Android release (v2.11.4)!

- You can now quote other people’s posts (if they permit it) when connected to a server that supports it
- Other minor fixes and improvements

- https://github.com/mastodon/mastodon-android/releases
- https://play.google.com/store/apps/details?id=org.joinmastodon.android

#mastodon #update #release #android

New Android release (v2.11.4)!

- You can now quote other people’s posts (if they permit it) when connected to a server that supports it
- Other minor fixes and improvements

- https://github.com/mastodon/mastodon-android/releases
- https://play.google.com/store/apps/details?id=org.joinmastodon.android

#mastodon #update #release #android

After a long wait, GHC 9.14.1-rc1 is now available. This includes an important fix which ensures compatibility with macOS 26 and later. We expect that this same fix will be backported to GHC 9.12 and 9.10 in the coming months.

Happy Haskelling!

#haskell #ghc #release

https:/ /www.haskell.org/ghc/blog/20251030-ghc-9.14.1-rc1-released.html

After a long wait, GHC 9.14.1-rc1 is now available. This includes an important fix which ensures compatibility with macOS 26 and later. We expect that this same fix will be backported to GHC 9.12 and 9.10 in the coming months.

Happy Haskelling!

#haskell #ghc #release

https:/ /www.haskell.org/ghc/blog/20251030-ghc-9.14.1-rc1-released.html

Boa release v0.21:

https://boajs.dev/blog/2025/10/22/boa-release-21

#Boa is an experimental #JavaScript lexer, #parser and #compiler written in #Rust. It now passes 94.12% of conformance tests in the official #ECMAScript Test Suite (Test262).

#Release #JSEngine #JavaScriptEngine #VM #RustLang

Boa release v0.21:

https://boajs.dev/blog/2025/10/22/boa-release-21

#Boa is an experimental #JavaScript lexer, #parser and #compiler written in #Rust. It now passes 94.12% of conformance tests in the official #ECMAScript Test Suite (Test262).

#Release #JSEngine #JavaScriptEngine #VM #RustLang

Just released! 🚀

🎨 termcolor 3.2.0

https://github.com/termcolor/termcolor/releases/tag/3.2.0

🟣 Expose `can_colorize` as public API
🟢 Add support for Python 3.15 (🥉 at https://pyreadiness.org/3.15/)
🔴 Drop support for EOLish Python 3.9

#Python #release #termcolor #Python315 #Python39

Just released! 🚀

📜 Python Docs Sphinx Theme, with added Arabic, French, Romanian and Russian translations.

https://github.com/python/python-docs-theme/releases/tag/2025.10

#Python #release #PythonDocsSphinxTheme #Sphinx #theme #translations

Plasma 6.5 is out! Look forward to cool interface re-designs (rounded corners! Automatic smooth light-to-dark transitions!), features (smart KRunner searches! Pinned clipboard items!) and tons of usability and accessibility improvements:

https://kde.org/announcements/plasma/6/6.5.0/

#desktop #Plasma6 #OpenSource #FreeSoftware #Release

OpenBSD 7.8 released

Release notes: https://www.openbsd.org/78.html

Announce: https://marc.info/?l=openbsd-announce&m=176109731212545&w=2

#release

OpenBSD 7.8 released

Release notes: https://www.openbsd.org/78.html

Announce: https://marc.info/?l=openbsd-announce&m=176109731212545&w=2

#release

Plasma 6.5 is out! Look forward to cool interface re-designs (rounded corners! Automatic smooth light-to-dark transitions!), features (smart KRunner searches! Pinned clipboard items!) and tons of usability and accessibility improvements:

https://kde.org/announcements/plasma/6/6.5.0/

#desktop #Plasma6 #OpenSource #FreeSoftware #Release

Plasma 6.5 is out! Look forward to cool interface re-designs (rounded corners! Automatic smooth light-to-dark transitions!), features (smart KRunner searches! Pinned clipboard items!) and tons of usability and accessibility improvements:

https://kde.org/announcements/plasma/6/6.5.0/

#desktop #Plasma6 #OpenSource #FreeSoftware #Release

Plasma 6.5 is out! Look forward to cool interface re-designs (rounded corners! Automatic smooth light-to-dark transitions!), features (smart KRunner searches! Pinned clipboard items!) and tons of usability and accessibility improvements:

https://kde.org/announcements/plasma/6/6.5.0/

#desktop #Plasma6 #OpenSource #FreeSoftware #Release

Plasma 6.5 is out! Look forward to cool interface re-designs (rounded corners! Automatic smooth light-to-dark transitions!), features (smart KRunner searches! Pinned clipboard items!) and tons of usability and accessibility improvements:

https://kde.org/announcements/plasma/6/6.5.0/

#desktop #Plasma6 #OpenSource #FreeSoftware #Release

🆕 pandoc 3.8.2.1

This release fixes a citeproc-related performance regression.
The only document conversion change is support for dynamic blocks and block attributes in Org-mode.
Thanks to all who contributed!

https://github.com/jgm/pandoc/releases/tag/3.8.2.1

#pandoc #release #citeproc #orgmode

WoodpeckerCI v3.11.0 is here! 🎉 Configure repo-specific config extensions, enjoy smoother logs, paginated repos & teams, and enhanced Bitbucket build status. Plus, bug fixes & docs updates for a better experience! 🚀 #WoodpeckerCI #release #DevOps #CI_CD

Just released! 🚀🚀🚀🚀🚀

Pillow 12.0.0
https://fosstodon.org/@pillow/115379893139846791

norwegianblue 0.23.0
https://github.com/hugovk/norwegianblue/releases/tag/0.23.0

pypinfo 23.0.0
https://github.com/ofek/pypinfo/blob/master/CHANGELOG.rst#2300

Humanize 4.14.0
https://github.com/python-humanize/humanize/releases/tag/4.14.0

Tablib 3.9.0
https://github.com/jazzband/tablib/releases/tag/v3.9.0

#Python #release #Pillow #pypinfo #Humanize #norwegianblue #Tablib

Just released! 🚀🚀🚀🚀🚀

Pillow 12.0.0
https://fosstodon.org/@pillow/115379893139846791

norwegianblue 0.23.0
https://github.com/hugovk/norwegianblue/releases/tag/0.23.0

pypinfo 23.0.0
https://github.com/ofek/pypinfo/blob/master/CHANGELOG.rst#2300

Humanize 4.14.0
https://github.com/python-humanize/humanize/releases/tag/4.14.0

Tablib 3.9.0
https://github.com/jazzband/tablib/releases/tag/v3.9.0

#Python #release #Pillow #pypinfo #Humanize #norwegianblue #Tablib

Forget* about Python 3.14, all the cool kids are trying out Python 3.15.0 alpha 1 (but not on production)! 🚀

🔬 PEP 799: A dedicated profiling package for Python profiling tools
💬 PEP 686: Python now uses UTF-8 as the default encoding
🌊 PEP 782: A new PyBytesWriter C API to create a Python bytes object
⚠️ Better error messages

https://discuss.python.org/t/python-3-15-alpha-1/104358?u=hugovk

* Please don't forget about 3.14...

#Python #Python315 #release #PEP799 #PEP686 #PEP782

Release pandoc 3.8.2

This release fixes a regression in the Typst template (since 3.8), which caused links to be omitted.

It also adds a new default Markdown extension, `table_attributes`, which allows attributes to be added to tables by putting them after the caption.

https://github.com/jgm/pandoc/releases/tag/3.8.2

#pandoc #release #Markdown #Typst

Release pandoc 3.8.2

This release fixes a regression in the Typst template (since 3.8), which caused links to be omitted.

It also adds a new default Markdown extension, `table_attributes`, which allows attributes to be added to tables by putting them after the caption.

https://github.com/jgm/pandoc/releases/tag/3.8.2

#pandoc #release #Markdown #Typst

🚀 It's out!

🥧 Please install and enjoy Python 3.14!

https://discuss.python.org/t/python-3-14-0-final-is-here/104210?u=hugovk

#Python #Python314 #release

🚀 It's out!

🥧 Please install and enjoy Python 3.14!

https://discuss.python.org/t/python-3-14-0-final-is-here/104210?u=hugovk

#Python #Python314 #release

🚀 It's out!

🥧 Please install and enjoy Python 3.14!

https://discuss.python.org/t/python-3-14-0-final-is-here/104210?u=hugovk

#Python #Python314 #release

🚀 It's out!

🥧 Please install and enjoy Python 3.14!

https://discuss.python.org/t/python-3-14-0-final-is-here/104210?u=hugovk

#Python #Python314 #release

🚀 It's out!

🥧 Please install and enjoy Python 3.14!

https://discuss.python.org/t/python-3-14-0-final-is-here/104210?u=hugovk

#Python #Python314 #release

🚀 It's out!

🥧 Please install and enjoy Python 3.14!

https://discuss.python.org/t/python-3-14-0-final-is-here/104210?u=hugovk

#Python #Python314 #release

macOS installer done, next on the final publishing and announcing steps.

#Python #Python314 #release

The Windows build is ready and macOS is underway.

#Python #Python314 #release

The Windows build has been started.

The jobs with profile-guided optimisation (PGO) build once, then collect a profile by running the tests, and then build again using that profile, to see how "real" code executes and optimises for that.

https://dev.azure.com/Python/cpython/_build/results?buildId=164907&view=results

Meanwhile, the docs+source+Android build has finished and the artifacts have been copied to where they need to go with SBOMs created.

#Python #Python314 #release

(That's actually the second CI attempt, we had to update some script arguments following an Android test runner update.)

This build takes about half an hour.

I've also informed the Windows and macOS release managers about the tag and they will start up installer builds.

This takes a few hours, so I've got time to finish up the release notes.

PEP 101 is the full process, but much is automated and we don't need to follow it all manually.

https://peps.python.org/pep-0101/

#Python #Python314 #release

Next up, merge and backport the final change to What's New in Python 3.14 to declare it latest stable.
https://github.com/python/cpython/pull/139631

Now start run_release.py, the main release automation script, which does a bunch of pre-checks, runs blurb to create a merged changelog, bumps some numbers, and pushes a branch and tag to my fork. It'll go upstream at the end of a successful build.

Then kick off the CI to build source zips, docs and Android binaries.
https://github.com/python/release-tools/actions/runs/18308460797

#Python #Python314 #release

Release day!

First off, check blockers and buildbots.

A new release-blocker appeared yesterday (because of course) but it can wait until 3.14.1.

https://github.com/python/cpython/labels/release-blocker

Three deferred-blockers are also waiting until 3.14.1.

https://github.com/python/cpython/labels/deferred-blocker

A new tier-2 buildbot failure appeared yesterday (because of course) but it had previously been offline for a month and will need some reconfiguration. Can ignore.

https://buildbot.python.org/#/release_status

OK, let's make a Python!

#Python #Python314 #release

🔥 RSS/Atom support opens up data portability beyond the fediverse.
You can now subscribe to user feeds, thread comments, posts, articles, events, media feeds, or custom feeds directly in your RSS client.

Demo: https://www.tella.tv/video/cmg57fu7u00050bjj2skigzpn/embed?b=0&title=0&a=1&loop=0&t=0&muted=0&wt=0%22

Read more about 1.0 RC3: https://bonfirenetworks.org/posts/bonfire-social-1-0rc3/

#enshittification #release #dataportability

🔥 RSS/Atom support opens up data portability beyond the fediverse.
You can now subscribe to user feeds, thread comments, posts, articles, events, media feeds, or custom feeds directly in your RSS client.

Demo: https://www.tella.tv/video/cmg57fu7u00050bjj2skigzpn/embed?b=0&title=0&a=1&loop=0&t=0&muted=0&wt=0%22

Read more about 1.0 RC3: https://bonfirenetworks.org/posts/bonfire-social-1-0rc3/

#enshittification #release #dataportability

Just released! 🚀

flake8-implicit-str-concat 0.6.0

A Flake8 plugin to identify those unjoined strings that a first Black run leaves behind:
"111111111111111111111" "222222222222222222222"

I hear there's another big release tomorrow? This release adds support for Python 3.14 and for once code changes were needed due to AST deprecation removals.

Also drop support for almost-very-nearly-EOL Python 3.9.

https://github.com/flake8-implicit-str-concat/flake8-implicit-str-concat/releases/tag/0.6.0
#Python #flake8 #release #Python314 #Python39

🔥 More anti-enshittification features now live in Bonfire

✨ Complete data portability: Export/import now supports circles/lists, bookmarks, likes, and boosts alongside follows, blocks, and posts.

✨ Transparency by design: A dedicated real-time dashboard to monitor migration progress in detail and troubleshoot issues.

Read more about 1.0 RC3: https://bonfirenetworks.org/posts/bonfire-social-1-0rc3/
#enshittification #release

🔥 More anti-enshittification features now live in Bonfire

✨ Complete data portability: Export/import now supports circles/lists, bookmarks, likes, and boosts alongside follows, blocks, and posts.

✨ Transparency by design: A dedicated real-time dashboard to monitor migration progress in detail and troubleshoot issues.

Read more about 1.0 RC3: https://bonfirenetworks.org/posts/bonfire-social-1-0rc3/
#enshittification #release

🔥 More anti-enshittification features now live in Bonfire

✨ Complete data portability: Export/import now supports circles/lists, bookmarks, likes, and boosts alongside follows, blocks, and posts.

✨ Transparency by design: A dedicated real-time dashboard to monitor migration progress in detail and troubleshoot issues.

Read more about 1.0 RC3: https://bonfirenetworks.org/posts/bonfire-social-1-0rc3/
#enshittification #release

Optique 0.6.0: Shell completion support for type-safe CLI parsers https://lobste.rs/s/rnekre #javascript #release
https://hackers.pub/@hongminhee/2025/optique-060

Optique 0.6.0: Shell completion support for type-safe CLI parsers https://lobste.rs/s/rnekre #javascript #release
https://hackers.pub/@hongminhee/2025/optique-060

Optique 0.6.0: Shell completion support for type-safe CLI parsers https://lobste.rs/s/rnekre #javascript #release
https://hackers.pub/@hongminhee/2025/optique-060

🔥 More anti-enshittification features now live in Bonfire

✨ Complete data portability: Export/import now supports circles/lists, bookmarks, likes, and boosts alongside follows, blocks, and posts.

✨ Transparency by design: A dedicated real-time dashboard to monitor migration progress in detail and troubleshoot issues.

Read more about 1.0 RC3: https://bonfirenetworks.org/posts/bonfire-social-1-0rc3/
#enshittification #release

Optique 0.6.0: Shell completion support for type-safe CLI parsers https://lobste.rs/s/rnekre #javascript #release
https://hackers.pub/@hongminhee/2025/optique-060

🚀 Woodpecker 3.10.0 is live!
- Pull‑request metadata & task‑UUID labels for tighter CI pipelines
- New org‑listing API (CLI & Go SDK) + milestone support
- Smarter error traces, CLI auto‑completion & human‑readable queue info
- Dozens of dependency fixes

Upgrade now for a smoother CI experience! 🎉 #CI #DevOps #woodpeckerci #release

https://github.com/woodpecker-ci/woodpecker/releases/tag/v3.10.0

Just released! 🚀

em-keyboard 5.3.0

🎲 Pick a random emoji from a search. For example:

❯ em --search music --random
Copied! 👩‍🎤 woman_singer

🧛‍♂️ Drop support for Python 3.9

https://github.com/hugovk/em-keyboard/releases/tag/v5.3.0

#Python #EmKeyboard #em #CLI #release #emoji

Just released! 🚀

🎶 pylast 6.0.0

🎤 A Python interface to Last.fm and Libre.fm

📯 Restore proxy support (potential breaking change: proxies are now always stored as a dict, before it was a str or dict)

🪇 Drop support for almost-EOL Python 3.9

https://github.com/pylast/pylast/releases/tag/6.0.0

#Python #pylast #LastFM #LibreFM #release #Python39

🎉 PHP 8.5.0 RC 1 is available for testing!

This is the first release candidate for PHP 8.5, including

- Implementation of remaining deprecations and warnings
- Finishing up the new Uri extension
- Bug fixes thanks to your testing and feedback

… and more!

➕ Do: Test your projects!

➖ Don't: Run it in production. It's not fully ready yet.

Congratulations to Daniel, @edorian, and @adoy

🔗 https://www.php.net/archive/2025.php#2025-09-25-3

#PHP #PHP85 #Release

🎉 PHP 8.5.0 RC 1 is available for testing!

This is the first release candidate for PHP 8.5, including

- Implementation of remaining deprecations and warnings
- Finishing up the new Uri extension
- Bug fixes thanks to your testing and feedback

… and more!

➕ Do: Test your projects!

➖ Don't: Run it in production. It's not fully ready yet.

Congratulations to Daniel, @edorian, and @adoy

🔗 https://www.php.net/archive/2025.php#2025-09-25-3

#PHP #PHP85 #Release

New Android release (v2.11.0)!

- You can now quote other people’s posts (if they permit it) when connected to a server that supports it
- Other minor fixes and improvements

- https://github.com/mastodon/mastodon-android/releases
- https://play.google.com/store/apps/details?id=org.joinmastodon.android

#mastodon #update #release #android

New Android release (v2.11.0)!

- You can now quote other people’s posts (if they permit it) when connected to a server that supports it
- Other minor fixes and improvements

- https://github.com/mastodon/mastodon-android/releases
- https://play.google.com/store/apps/details?id=org.joinmastodon.android

#mastodon #update #release #android

Just released: Python 3.14.0 release candidate 3! 🚀🐍

🪄 Finally, the final release candidate

🪄 We fixed *another* bug that required the ".pyc magic number" to be increased

🪄 The ABI isn't changing, and wheels built for rc1 and rc2 should still work

👤 This was the first release @savannah shadowed!

🏆 Please test and report bugs!

https://discuss.python.org/t/python-3-14-0rc3-is-go/103815?u=hugovk

#Python #CPython #Python314 #release

Wasm 3.0 Completed https://lobste.rs/s/bqiqjm #release #wasm
https://webassembly.org/news/2025-09-17-wasm-3.0/

Wasm 3.0 Completed https://lobste.rs/s/bqiqjm #release #wasm
https://webassembly.org/news/2025-09-17-wasm-3.0/

LogTape 1.1.0 is here, and it focuses on making your logging smarter and more flexible. This release introduces two major features we think you'll love.

Introducing fingers crossed logging

Tired of noisy production logs? Wish you had the full story when an error finally pops up? Our new “fingers crossed” logging pattern was built for exactly that.

With fingers crossed logging, LogTape buffers your debug and low-level logs in memory instead of immediately outputting them. When an error occurs, it flushes the entire buffer—giving you the complete sequence of events leading up to the problem. Once the error is logged, subsequent logs pass through normally until the next trigger event.

import { configure, fingersCrossed, getConsoleSink } from "@logtape/logtape";

await configure({
  sinks: {
    console: fingersCrossed(getConsoleSink(), {
      triggerLevel: "error",  // Buffer until an error occurs
      maxBufferSize: 500,     // Keep last 500 records
    }),
  },
  loggers: [
    { category: [], sinks: ["console"], lowestLevel: "debug" },
  ],
});

It's the best of both worlds: clean logs when things are running smoothly, and rich, detailed context the moment an issue occurs. Stop choosing between too much noise and not enough information.

Category isolation for complex applications

For applications with multiple modules or services, the new category isolation feature prevents one component's errors from flushing unrelated logs:

fingersCrossed(getConsoleSink(), {
  isolateByCategory: "descendant",  // Only flush related categories
})

You can choose how categories relate to each other—flush child categories when a parent triggers, parent categories when a child triggers, or both. This surgical precision keeps your logs focused and relevant.

Direct log emission for external systems

Integrating logs from external systems just got a lot easier. With the new Logger.emit() method, you can now feed logs from Kafka, legacy applications, or any other source directly into LogTape while preserving their original timestamps and metadata.

const logger = getLogger(["my-app", "integration"]);

// Preserve the original timestamp from an external system
logger.emit({
  timestamp: kafkaMessage.originalTimestamp,
  level: "info",
  message: [kafkaMessage.content],
  rawMessage: kafkaMessage.content,
  properties: {
    source: "kafka",
    partition: kafkaMessage.partition,
    offset: kafkaMessage.offset,
  },
});

This new low-level API gives you full control over the log record, allowing you to leverage LogTape's powerful filtering, formatting, and sink ecosystem for any log source. It's particularly valuable for:

• Migrating from other logging systems while preserving historical context
• Aggregating logs from multiple sources with accurate timestamps
• Building custom adapters for specialized logging scenarios

Bug fixes and improvements

Beyond the headline features, we've strengthened LogTape's reliability across the ecosystem. Check out the full changelog for complete details.

@logtape/file

• Fixed potential data loss during high-volume logging by ensuring all buffered logs are fully written before disposal
• Changed getStreamFileSink() to properly implement AsyncDisposable for cleaner resource management

@logtape/sentry

• Improved cross-runtime compatibility by introducing a structural interface that avoids type conflicts
• Fixed template metadata preservation for better Sentry breadcrumb formatting
• Removed unnecessary Node.js dependencies for broader runtime support

@logtape/pretty

• Added support for displaying structured data properties directly in pretty-formatted output (thanks to Matthias Feist for the contribution)

Why upgrade?

Upgrading to 1.1.0 is a no-brainer. It's fully backward-compatible and makes your setup more powerful. The fingers crossed feature alone will change how you debug in production. Imagine getting a complete stack trace with full context for every error, without the performance hit of constant verbose logging.

If you're new to LogTape, this release shows what we're all about: building tools that solve real-world problems. We don't think you should have to choose between noisy logs and insufficient context. LogTape adapts to what you need, buffering logs when things are quiet and providing rich detail when it matters most.

Getting started

Upgrade to LogTape 1.1.0:

npm update @logtape/logtape
# or
deno add jsr:@logtape/logtape@^1.1.0

The new features are opt-in, so your existing configuration continues working exactly as before. When you're ready, explore fingers crossed logging for cleaner production logs or use emit() for advanced integration scenarios.

Let us know what you think of the new features! We're always active in our GitHub discussions and would love to hear your feedback.

LogTape 1.1.0 is here, and it focuses on making your logging smarter and more flexible. This release introduces two major features we think you'll love.

Introducing fingers crossed logging

Tired of noisy production logs? Wish you had the full story when an error finally pops up? Our new “fingers crossed” logging pattern was built for exactly that.

With fingers crossed logging, LogTape buffers your debug and low-level logs in memory instead of immediately outputting them. When an error occurs, it flushes the entire buffer—giving you the complete sequence of events leading up to the problem. Once the error is logged, subsequent logs pass through normally until the next trigger event.

import { configure, fingersCrossed, getConsoleSink } from "@logtape/logtape";

await configure({
  sinks: {
    console: fingersCrossed(getConsoleSink(), {
      triggerLevel: "error",  // Buffer until an error occurs
      maxBufferSize: 500,     // Keep last 500 records
    }),
  },
  loggers: [
    { category: [], sinks: ["console"], lowestLevel: "debug" },
  ],
});

It's the best of both worlds: clean logs when things are running smoothly, and rich, detailed context the moment an issue occurs. Stop choosing between too much noise and not enough information.

Category isolation for complex applications

For applications with multiple modules or services, the new category isolation feature prevents one component's errors from flushing unrelated logs:

fingersCrossed(getConsoleSink(), {
  isolateByCategory: "descendant",  // Only flush related categories
})

You can choose how categories relate to each other—flush child categories when a parent triggers, parent categories when a child triggers, or both. This surgical precision keeps your logs focused and relevant.

Direct log emission for external systems

Integrating logs from external systems just got a lot easier. With the new Logger.emit() method, you can now feed logs from Kafka, legacy applications, or any other source directly into LogTape while preserving their original timestamps and metadata.

const logger = getLogger(["my-app", "integration"]);

// Preserve the original timestamp from an external system
logger.emit({
  timestamp: kafkaMessage.originalTimestamp,
  level: "info",
  message: [kafkaMessage.content],
  rawMessage: kafkaMessage.content,
  properties: {
    source: "kafka",
    partition: kafkaMessage.partition,
    offset: kafkaMessage.offset,
  },
});

This new low-level API gives you full control over the log record, allowing you to leverage LogTape's powerful filtering, formatting, and sink ecosystem for any log source. It's particularly valuable for:

• Migrating from other logging systems while preserving historical context
• Aggregating logs from multiple sources with accurate timestamps
• Building custom adapters for specialized logging scenarios

Bug fixes and improvements

Beyond the headline features, we've strengthened LogTape's reliability across the ecosystem. Check out the full changelog for complete details.

@logtape/file

• Fixed potential data loss during high-volume logging by ensuring all buffered logs are fully written before disposal
• Changed getStreamFileSink() to properly implement AsyncDisposable for cleaner resource management

@logtape/sentry

• Improved cross-runtime compatibility by introducing a structural interface that avoids type conflicts
• Fixed template metadata preservation for better Sentry breadcrumb formatting
• Removed unnecessary Node.js dependencies for broader runtime support

@logtape/pretty

• Added support for displaying structured data properties directly in pretty-formatted output (thanks to Matthias Feist for the contribution)

Why upgrade?

Upgrading to 1.1.0 is a no-brainer. It's fully backward-compatible and makes your setup more powerful. The fingers crossed feature alone will change how you debug in production. Imagine getting a complete stack trace with full context for every error, without the performance hit of constant verbose logging.

If you're new to LogTape, this release shows what we're all about: building tools that solve real-world problems. We don't think you should have to choose between noisy logs and insufficient context. LogTape adapts to what you need, buffering logs when things are quiet and providing rich detail when it matters most.

Getting started

Upgrade to LogTape 1.1.0:

npm update @logtape/logtape
# or
deno add jsr:@logtape/logtape@^1.1.0

The new features are opt-in, so your existing configuration continues working exactly as before. When you're ready, explore fingers crossed logging for cleaner production logs or use emit() for advanced integration scenarios.

Let us know what you think of the new features! We're always active in our GitHub discussions and would love to hear your feedback.

LogTape 1.1.0 is here, and it focuses on making your logging smarter and more flexible. This release introduces two major features we think you'll love.

Introducing fingers crossed logging

Tired of noisy production logs? Wish you had the full story when an error finally pops up? Our new “fingers crossed” logging pattern was built for exactly that.

With fingers crossed logging, LogTape buffers your debug and low-level logs in memory instead of immediately outputting them. When an error occurs, it flushes the entire buffer—giving you the complete sequence of events leading up to the problem. Once the error is logged, subsequent logs pass through normally until the next trigger event.

import { configure, fingersCrossed, getConsoleSink } from "@logtape/logtape";

await configure({
  sinks: {
    console: fingersCrossed(getConsoleSink(), {
      triggerLevel: "error",  // Buffer until an error occurs
      maxBufferSize: 500,     // Keep last 500 records
    }),
  },
  loggers: [
    { category: [], sinks: ["console"], lowestLevel: "debug" },
  ],
});

It's the best of both worlds: clean logs when things are running smoothly, and rich, detailed context the moment an issue occurs. Stop choosing between too much noise and not enough information.

Category isolation for complex applications

For applications with multiple modules or services, the new category isolation feature prevents one component's errors from flushing unrelated logs:

fingersCrossed(getConsoleSink(), {
  isolateByCategory: "descendant",  // Only flush related categories
})

You can choose how categories relate to each other—flush child categories when a parent triggers, parent categories when a child triggers, or both. This surgical precision keeps your logs focused and relevant.

Direct log emission for external systems

Integrating logs from external systems just got a lot easier. With the new Logger.emit() method, you can now feed logs from Kafka, legacy applications, or any other source directly into LogTape while preserving their original timestamps and metadata.

const logger = getLogger(["my-app", "integration"]);

// Preserve the original timestamp from an external system
logger.emit({
  timestamp: kafkaMessage.originalTimestamp,
  level: "info",
  message: [kafkaMessage.content],
  rawMessage: kafkaMessage.content,
  properties: {
    source: "kafka",
    partition: kafkaMessage.partition,
    offset: kafkaMessage.offset,
  },
});

This new low-level API gives you full control over the log record, allowing you to leverage LogTape's powerful filtering, formatting, and sink ecosystem for any log source. It's particularly valuable for:

• Migrating from other logging systems while preserving historical context
• Aggregating logs from multiple sources with accurate timestamps
• Building custom adapters for specialized logging scenarios

Bug fixes and improvements

Beyond the headline features, we've strengthened LogTape's reliability across the ecosystem. Check out the full changelog for complete details.

@logtape/file

• Fixed potential data loss during high-volume logging by ensuring all buffered logs are fully written before disposal
• Changed getStreamFileSink() to properly implement AsyncDisposable for cleaner resource management

@logtape/sentry

• Improved cross-runtime compatibility by introducing a structural interface that avoids type conflicts
• Fixed template metadata preservation for better Sentry breadcrumb formatting
• Removed unnecessary Node.js dependencies for broader runtime support

@logtape/pretty

• Added support for displaying structured data properties directly in pretty-formatted output (thanks to Matthias Feist for the contribution)

Why upgrade?

Upgrading to 1.1.0 is a no-brainer. It's fully backward-compatible and makes your setup more powerful. The fingers crossed feature alone will change how you debug in production. Imagine getting a complete stack trace with full context for every error, without the performance hit of constant verbose logging.

If you're new to LogTape, this release shows what we're all about: building tools that solve real-world problems. We don't think you should have to choose between noisy logs and insufficient context. LogTape adapts to what you need, buffering logs when things are quiet and providing rich detail when it matters most.

Getting started

Upgrade to LogTape 1.1.0:

npm update @logtape/logtape
# or
deno add jsr:@logtape/logtape@^1.1.0

The new features are opt-in, so your existing configuration continues working exactly as before. When you're ready, explore fingers crossed logging for cleaner production logs or use emit() for advanced integration scenarios.

Let us know what you think of the new features! We're always active in our GitHub discussions and would love to hear your feedback.

LogTape 1.1.0 is here, and it focuses on making your logging smarter and more flexible. This release introduces two major features we think you'll love.

Introducing fingers crossed logging

Tired of noisy production logs? Wish you had the full story when an error finally pops up? Our new “fingers crossed” logging pattern was built for exactly that.

With fingers crossed logging, LogTape buffers your debug and low-level logs in memory instead of immediately outputting them. When an error occurs, it flushes the entire buffer—giving you the complete sequence of events leading up to the problem. Once the error is logged, subsequent logs pass through normally until the next trigger event.

import { configure, fingersCrossed, getConsoleSink } from "@logtape/logtape";

await configure({
  sinks: {
    console: fingersCrossed(getConsoleSink(), {
      triggerLevel: "error",  // Buffer until an error occurs
      maxBufferSize: 500,     // Keep last 500 records
    }),
  },
  loggers: [
    { category: [], sinks: ["console"], lowestLevel: "debug" },
  ],
});

It's the best of both worlds: clean logs when things are running smoothly, and rich, detailed context the moment an issue occurs. Stop choosing between too much noise and not enough information.

Category isolation for complex applications

For applications with multiple modules or services, the new category isolation feature prevents one component's errors from flushing unrelated logs:

fingersCrossed(getConsoleSink(), {
  isolateByCategory: "descendant",  // Only flush related categories
})

You can choose how categories relate to each other—flush child categories when a parent triggers, parent categories when a child triggers, or both. This surgical precision keeps your logs focused and relevant.

Direct log emission for external systems

Integrating logs from external systems just got a lot easier. With the new Logger.emit() method, you can now feed logs from Kafka, legacy applications, or any other source directly into LogTape while preserving their original timestamps and metadata.

const logger = getLogger(["my-app", "integration"]);

// Preserve the original timestamp from an external system
logger.emit({
  timestamp: kafkaMessage.originalTimestamp,
  level: "info",
  message: [kafkaMessage.content],
  rawMessage: kafkaMessage.content,
  properties: {
    source: "kafka",
    partition: kafkaMessage.partition,
    offset: kafkaMessage.offset,
  },
});

This new low-level API gives you full control over the log record, allowing you to leverage LogTape's powerful filtering, formatting, and sink ecosystem for any log source. It's particularly valuable for:

• Migrating from other logging systems while preserving historical context
• Aggregating logs from multiple sources with accurate timestamps
• Building custom adapters for specialized logging scenarios

Bug fixes and improvements

Beyond the headline features, we've strengthened LogTape's reliability across the ecosystem. Check out the full changelog for complete details.

@logtape/file

• Fixed potential data loss during high-volume logging by ensuring all buffered logs are fully written before disposal
• Changed getStreamFileSink() to properly implement AsyncDisposable for cleaner resource management

@logtape/sentry

• Improved cross-runtime compatibility by introducing a structural interface that avoids type conflicts
• Fixed template metadata preservation for better Sentry breadcrumb formatting
• Removed unnecessary Node.js dependencies for broader runtime support

@logtape/pretty

• Added support for displaying structured data properties directly in pretty-formatted output (thanks to Matthias Feist for the contribution)

Why upgrade?

Upgrading to 1.1.0 is a no-brainer. It's fully backward-compatible and makes your setup more powerful. The fingers crossed feature alone will change how you debug in production. Imagine getting a complete stack trace with full context for every error, without the performance hit of constant verbose logging.

If you're new to LogTape, this release shows what we're all about: building tools that solve real-world problems. We don't think you should have to choose between noisy logs and insufficient context. LogTape adapts to what you need, buffering logs when things are quiet and providing rich detail when it matters most.

Getting started

Upgrade to LogTape 1.1.0:

npm update @logtape/logtape
# or
deno add jsr:@logtape/logtape@^1.1.0

The new features are opt-in, so your existing configuration continues working exactly as before. When you're ready, explore fingers crossed logging for cleaner production logs or use emit() for advanced integration scenarios.

Let us know what you think of the new features! We're always active in our GitHub discussions and would love to hear your feedback.

LogTape 1.1.0 is here, and it focuses on making your logging smarter and more flexible. This release introduces two major features we think you'll love.

Introducing fingers crossed logging

Tired of noisy production logs? Wish you had the full story when an error finally pops up? Our new “fingers crossed” logging pattern was built for exactly that.

With fingers crossed logging, LogTape buffers your debug and low-level logs in memory instead of immediately outputting them. When an error occurs, it flushes the entire buffer—giving you the complete sequence of events leading up to the problem. Once the error is logged, subsequent logs pass through normally until the next trigger event.

import { configure, fingersCrossed, getConsoleSink } from "@logtape/logtape";

await configure({
  sinks: {
    console: fingersCrossed(getConsoleSink(), {
      triggerLevel: "error",  // Buffer until an error occurs
      maxBufferSize: 500,     // Keep last 500 records
    }),
  },
  loggers: [
    { category: [], sinks: ["console"], lowestLevel: "debug" },
  ],
});

It's the best of both worlds: clean logs when things are running smoothly, and rich, detailed context the moment an issue occurs. Stop choosing between too much noise and not enough information.

Category isolation for complex applications

For applications with multiple modules or services, the new category isolation feature prevents one component's errors from flushing unrelated logs:

fingersCrossed(getConsoleSink(), {
  isolateByCategory: "descendant",  // Only flush related categories
})

You can choose how categories relate to each other—flush child categories when a parent triggers, parent categories when a child triggers, or both. This surgical precision keeps your logs focused and relevant.

Direct log emission for external systems

Integrating logs from external systems just got a lot easier. With the new Logger.emit() method, you can now feed logs from Kafka, legacy applications, or any other source directly into LogTape while preserving their original timestamps and metadata.

const logger = getLogger(["my-app", "integration"]);

// Preserve the original timestamp from an external system
logger.emit({
  timestamp: kafkaMessage.originalTimestamp,
  level: "info",
  message: [kafkaMessage.content],
  rawMessage: kafkaMessage.content,
  properties: {
    source: "kafka",
    partition: kafkaMessage.partition,
    offset: kafkaMessage.offset,
  },
});

This new low-level API gives you full control over the log record, allowing you to leverage LogTape's powerful filtering, formatting, and sink ecosystem for any log source. It's particularly valuable for:

• Migrating from other logging systems while preserving historical context
• Aggregating logs from multiple sources with accurate timestamps
• Building custom adapters for specialized logging scenarios

Bug fixes and improvements

Beyond the headline features, we've strengthened LogTape's reliability across the ecosystem. Check out the full changelog for complete details.

@logtape/file

• Fixed potential data loss during high-volume logging by ensuring all buffered logs are fully written before disposal
• Changed getStreamFileSink() to properly implement AsyncDisposable for cleaner resource management

@logtape/sentry

• Improved cross-runtime compatibility by introducing a structural interface that avoids type conflicts
• Fixed template metadata preservation for better Sentry breadcrumb formatting
• Removed unnecessary Node.js dependencies for broader runtime support

@logtape/pretty

• Added support for displaying structured data properties directly in pretty-formatted output (thanks to Matthias Feist for the contribution)

Why upgrade?

Upgrading to 1.1.0 is a no-brainer. It's fully backward-compatible and makes your setup more powerful. The fingers crossed feature alone will change how you debug in production. Imagine getting a complete stack trace with full context for every error, without the performance hit of constant verbose logging.

If you're new to LogTape, this release shows what we're all about: building tools that solve real-world problems. We don't think you should have to choose between noisy logs and insufficient context. LogTape adapts to what you need, buffering logs when things are quiet and providing rich detail when it matters most.

Getting started

Upgrade to LogTape 1.1.0:

npm update @logtape/logtape
# or
deno add jsr:@logtape/logtape@^1.1.0

The new features are opt-in, so your existing configuration continues working exactly as before. When you're ready, explore fingers crossed logging for cleaner production logs or use emit() for advanced integration scenarios.

Let us know what you think of the new features! We're always active in our GitHub discussions and would love to hear your feedback.

LogTape 1.1.0 is here, and it focuses on making your logging smarter and more flexible. This release introduces two major features we think you'll love.

Introducing fingers crossed logging

Tired of noisy production logs? Wish you had the full story when an error finally pops up? Our new “fingers crossed” logging pattern was built for exactly that.

With fingers crossed logging, LogTape buffers your debug and low-level logs in memory instead of immediately outputting them. When an error occurs, it flushes the entire buffer—giving you the complete sequence of events leading up to the problem. Once the error is logged, subsequent logs pass through normally until the next trigger event.

import { configure, fingersCrossed, getConsoleSink } from "@logtape/logtape";

await configure({
  sinks: {
    console: fingersCrossed(getConsoleSink(), {
      triggerLevel: "error",  // Buffer until an error occurs
      maxBufferSize: 500,     // Keep last 500 records
    }),
  },
  loggers: [
    { category: [], sinks: ["console"], lowestLevel: "debug" },
  ],
});

It's the best of both worlds: clean logs when things are running smoothly, and rich, detailed context the moment an issue occurs. Stop choosing between too much noise and not enough information.

Category isolation for complex applications

For applications with multiple modules or services, the new category isolation feature prevents one component's errors from flushing unrelated logs:

fingersCrossed(getConsoleSink(), {
  isolateByCategory: "descendant",  // Only flush related categories
})

You can choose how categories relate to each other—flush child categories when a parent triggers, parent categories when a child triggers, or both. This surgical precision keeps your logs focused and relevant.

Direct log emission for external systems

Integrating logs from external systems just got a lot easier. With the new Logger.emit() method, you can now feed logs from Kafka, legacy applications, or any other source directly into LogTape while preserving their original timestamps and metadata.

const logger = getLogger(["my-app", "integration"]);

// Preserve the original timestamp from an external system
logger.emit({
  timestamp: kafkaMessage.originalTimestamp,
  level: "info",
  message: [kafkaMessage.content],
  rawMessage: kafkaMessage.content,
  properties: {
    source: "kafka",
    partition: kafkaMessage.partition,
    offset: kafkaMessage.offset,
  },
});

This new low-level API gives you full control over the log record, allowing you to leverage LogTape's powerful filtering, formatting, and sink ecosystem for any log source. It's particularly valuable for:

• Migrating from other logging systems while preserving historical context
• Aggregating logs from multiple sources with accurate timestamps
• Building custom adapters for specialized logging scenarios

Bug fixes and improvements

Beyond the headline features, we've strengthened LogTape's reliability across the ecosystem. Check out the full changelog for complete details.

@logtape/file

• Fixed potential data loss during high-volume logging by ensuring all buffered logs are fully written before disposal
• Changed getStreamFileSink() to properly implement AsyncDisposable for cleaner resource management

@logtape/sentry

• Improved cross-runtime compatibility by introducing a structural interface that avoids type conflicts
• Fixed template metadata preservation for better Sentry breadcrumb formatting
• Removed unnecessary Node.js dependencies for broader runtime support

@logtape/pretty

• Added support for displaying structured data properties directly in pretty-formatted output (thanks to Matthias Feist for the contribution)

Why upgrade?

Upgrading to 1.1.0 is a no-brainer. It's fully backward-compatible and makes your setup more powerful. The fingers crossed feature alone will change how you debug in production. Imagine getting a complete stack trace with full context for every error, without the performance hit of constant verbose logging.

If you're new to LogTape, this release shows what we're all about: building tools that solve real-world problems. We don't think you should have to choose between noisy logs and insufficient context. LogTape adapts to what you need, buffering logs when things are quiet and providing rich detail when it matters most.

Getting started

Upgrade to LogTape 1.1.0:

npm update @logtape/logtape
# or
deno add jsr:@logtape/logtape@^1.1.0

The new features are opt-in, so your existing configuration continues working exactly as before. When you're ready, explore fingers crossed logging for cleaner production logs or use emit() for advanced integration scenarios.

Let us know what you think of the new features! We're always active in our GitHub discussions and would love to hear your feedback.

term.everything: Run any GUI app in the terminal https://lobste.rs/s/9m1tto #show #release
https://github.com/mmulet/term.everything

🆕 release: pandoc 3.8 🎉
This release comes with many small improvements and a few larger ones.
Among the more visible changes:

• A new input/output format `xml`, which represents a pandoc AST in XML.

• Syntax highlighting updates, including a new command line option `--syntax-highlighting`.

• New extensions `smart_quotes` and `special_strings` for org mode, bringing pandoc's parsing closer to Emacs org-mode's behavior.

Thanks to all who contributed!

https://github.com/jgm/pandoc/releases/tag/3.8

#pandoc #release

Today's Cockpit #release brings Stratis V2 support, better distro branding support, persistent serial VM consoles, and more. Enjoy!

https://cockpit-project.org/blog/cockpit-346.html

Today's Cockpit #release brings Stratis V2 support, better distro branding support, persistent serial VM consoles, and more. Enjoy!

https://cockpit-project.org/blog/cockpit-346.html

zfsbackrest: pgbackrest style encrypted backups for ZFS filesystems via @sphericalkat https://lobste.rs/s/ewbgui #release
https://github.com/gargakshit/zfsbackrest

zfsbackrest: pgbackrest style encrypted backups for ZFS filesystems via @sphericalkat https://lobste.rs/s/ewbgui #release
https://github.com/gargakshit/zfsbackrest

We're releasing Optique 0.3.0 with several improvements that make building complex CLI applications more straightforward. This release focuses on expanding parser flexibility and improving the help system based on feedback from the community, particularly from the Fedify project's migration from Cliffy to Optique. Special thanks to @z9mb1 for her invaluable insights during this process.

What's new

• Required Boolean flags with the new flag() parser for dependent options patterns
• Flexible type defaults in withDefault() supporting union types for conditional CLI structures
• Extended or() capacity now supporting up to 10 parsers (previously 5)
• Enhanced merge() combinator that works with any object-producing parser, not just object()
• Context-aware help using the new longestMatch() combinator
• Version display support in both @optique/core and @optique/run
• Structured output functions for consistent terminal formatting

Required Boolean flags with flag()

The new flag() parser creates Boolean flags that must be explicitly provided. While option() defaults to false when absent, flag() fails parsing entirely if not present. This subtle difference enables cleaner patterns for dependent options.

Consider a scenario where certain options only make sense when a mode is explicitly enabled:

import { flag, object, option, withDefault } from "@optique/core/parser";
import { integer } from "@optique/core/valueparser";

// Without the --advanced flag, these options aren't available
const parser = withDefault(
  object({
    advanced: flag("--advanced"),
    maxThreads: option("--threads", integer()),
    cacheSize: option("--cache-size", integer())
  }),
  { advanced: false as const }
);

// Usage:
// myapp                    → { advanced: false }
// myapp --advanced         → Error: --threads and --cache-size required
// myapp --advanced --threads 4 --cache-size 100 → Success

This pattern is particularly useful for confirmation flags (--yes-i-am-sure) or mode switches that fundamentally change how your CLI behaves.

Union types in withDefault()

Previously, withDefault() required the default value to match the parser's type exactly. Now it supports different types, creating union types that enable conditional CLI structures:

const conditionalParser = withDefault(
  object({
    server: flag("-s", "--server"),
    port: option("-p", "--port", integer()),
    host: option("-h", "--host", string())
  }),
  { server: false as const }
);

// Result type is now a union:
// | { server: false }
// | { server: true, port: number, host: string }

This change makes it much easier to build CLIs where different flags enable different sets of options, without resorting to complex or() chains.

More flexible merge() combinator

The merge() combinator now accepts any parser that produces object-like values. Previously limited to object() parsers, it now works with withDefault(), map(), and other transformative parsers:

const transformedConfig = map(
  object({
    host: option("--host", string()),
    port: option("--port", integer())
  }),
  ({ host, port }) => ({ endpoint: `${host}:${port}` })
);

const conditionalFeatures = withDefault(
  object({
    experimental: flag("--experimental"),
    debugLevel: option("--debug-level", integer())
  }),
  { experimental: false as const }
);

// Can now merge different parser types
const appConfig = merge(
  transformedConfig,        // map() result
  conditionalFeatures,      // withDefault() parser
  object({                  // traditional object()
    verbose: option("-v", "--verbose")
  })
);

This improvement came from recognizing that many parsers ultimately produce objects, and artificially restricting merge() to only object() parsers was limiting composition patterns.

Context-aware help with longestMatch()

The new longestMatch() combinator selects the parser that consumes the most input tokens. This enables sophisticated help systems where command --help shows help for that specific command rather than global help:

const normalParser = object({
  help: constant(false),
  command: or(
    command("list", listOptions),
    command("add", addOptions)
  )
});

const contextualHelp = object({
  help: constant(true),
  commands: multiple(argument(string())),
  helpFlag: flag("--help")
});

const cli = longestMatch(normalParser, contextualHelp);

// myapp --help           → Shows global help
// myapp list --help      → Shows help for 'list' command
// myapp add --help       → Shows help for 'add' command