Skip to content

Piero Bosio Social Web Site Personale Logo Fediverso

Social Forum federato con il resto del mondo. Non contano le istanze, contano le persone
  1. Home
  2. Categories
  3. Fediverso
  4. Journalismus jenseits von Big Tech: unser Report ist da!

Journalismus jenseits von Big Tech: unser Report ist da!

Fediverso
10 6 16
Log in to reply

Feed RSS
Journalismus jenseits von Big Tech: unser Report ist da!

Gli ultimi otto messaggi ricevuti dalla Federazione
  • julian@activitypub.spaceundefined
    julian@activitypub.space

    @jonny@neuromatch.social honestly good for you for investing the time to critique this knowing it's AI (adjacent or wholesale) involvement.

    read more
  • jonny@neuromatch.socialundefined
    jonny@neuromatch.social

    @julian @PortaFed
    giving a further read: I can't really imagine a case where someone would a) regularly be creating signed backups and also b) know in advance where you wanted to migrate to to set the destination_did. Like if this is for the case where the instance has shut down, you might have some signed backup, but you probably haven't planned in advance where you would want to migrate, and if the instance is down you wouldn't be able to create the migration object after the fact.

    the validation strategy for the export is sort of mystifying to me. if the whole object is signed, then why would you need a merkle tree for objects and also an object count? if the contents of the object have changed post signing, then the signature validation will just fail and those are irrelevant.

    true to form for LLM generated documents, several critical things are left undefined, like what last_accepted_sequence is or how that works.

    probably the most important problem is that it's not really clear how all other instances are supposed to handle this, which is the entire hard part of a migration spec. Like, if the purpose here is to preserve identity, then you would need to have all the other instances come to see the new identity as being equivalent to the old identity, and there's no discussion of how that process works for third-party instances at all. like e.g. in FEP-1580 i had to spend a long time gaming out scenarios for how third party instances would handle a move event.

    so without that it's not really an account portabiltiy spec, it's an account export/import spec, which is fine, just not really needed since signing objects and collections (which this spec should use anyway) is already described by other specs.

    read more
  • portafed@mastodon.socialundefined
    portafed@mastodon.social

    @silverpillThank you , these are important corrections and I appreciate you taking the time.
    You're right on both points. I'll update the spec to reflect that FEP-ef61 authority is not actor-rooted in the way I described, and that migration is possible via outbox export-import. I was overstating the gap.
    The distinction I was trying to draw is narrower:

    read more
  • silverpill@mitra.socialundefined
    silverpill@mitra.social

    @PortaFed

    I have a couple of comments regarding the spec https://codeberg.org/portafed/portafed/src/branch/main/portafed-spec/spec.md

    It contains a comparison with FEP-ef61, but it is not quite correct:

    - FEP-ef61 identity is not actor-rooted. The closest equivalent of FEP-ef61 identity in normal ActivityPub is a server with a domain name. A single FEP-ef61 authority can manage multiple actor documents.
    - FEP-ef61 does not lack a migration flow. Strictly speaking, it doesn't need one, because data is not attached to a server and can be continuously synchronized between multiple servers. But a more familiar migration flow is also possible via outbox export-import.

    @lutindiscret

    read more
  • portafed@mastodon.socialundefined
    portafed@mastodon.social

    @benpate That would be great and happy to contribute wherever it fits.
    My guess on the scope decision is the same as yours: hostile-server recovery is genuinely harder, and a cooperative spec is already a lot to get right. Makes sense to tackle it separately.
    Take your time reading. I'll put together a short write-up of how MigrationProof could slot into the existing spec easier to react to something concrete than to an abstract pitch.

    read more
  • julian@activitypub.spaceundefined
    julian@activitypub.space

    @jonny@neuromatch.social tracks doesn't it 😝

    read more
  • jonny@neuromatch.socialundefined
    jonny@neuromatch.social

    @julian
    @evan @benpate @PortaFed
    Can't make heads or tails of this one

    read more
  • ozoned@stream.firesidefedi.liveundefined
    ozoned@stream.firesidefedi.live

    Warm up the fire! We're LIVE!

    Summer in Winter: Norcal Gma 2's Journey with her Dog - E79

    #owncast #streaming #interview #fediverse #fedi #people #show #firesidefedi #FsF

    https://stream.firesidefedi.live

    read more
@pierobosio@soc.bosio.info
Post suggeriti
  • aral@mastodon.ar.alundefined

    Hey everyone,

    Fediverso gazaverified gaza palestine fediverse mastodon israel usa germany
    1
    0 Votes
    1 Posts
    9 Views
    aral@mastodon.ar.alundefined
    Hey everyone,Gaza Verified is now open again for verification calls in 2026.The new process for signing up for verification calls uses sign in with Mastodon and should remove the last remaining technical hurdle that was giving some of our friends in Gaza a hard time (adding the verification link to your Mastodon account is not intuitive in the current Mastodon interface). WiPh this new flow, you won’t have to, we do it for you.https://gaza-verified.orgAlso, please remember that Israel, USA, and Germany are continuing their genocide of the Palestinian people with the complicity of the UK and almost the entire rest of the EU.And we can help, if only a little. And even if it’s just a drop in the ocean it’s still a meaningful drop for those it helps:https://gaza-verified.org/donate/💕#GazaVerified #Gaza #Palestine #fediverse #mastodon #israel #USA #Germany #UK #EU #genocide #ethnicCleansing #apartheid #settlerColonialism #mutualAid #fediAid #StopIsrael #FreePalestine
  • fedify@hollo.socialundefined

    # Fedify 1.10.0: Observability foundations for the future debug dashboard

    Technical Discussion fedify fedidev release fediverse typescript activitypub opentelemetry
    1
    0 Votes
    1 Posts
    8 Views
    fedify@hollo.socialundefined
    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@hackers.pub), 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@hackers.pub) 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
  • ben@werd.socialundefined

    The investigative newsroom I work for, @ProPublica, is raising money right now.

    Uncategorized journalism fediverse
    2
    0 Votes
    2 Posts
    19 Views
    evan@cosocial.caundefined
    @ben @ProPublica thanks for all you do!
  • bjornw@mastodon.socialundefined

    Looking forward to represent @publicspaces @berlinfedidayThe program schedule looks awesome!

    Fediverso fediverse publicspaces fediday nextsocials
    2
    0 Votes
    2 Posts
    25 Views
    bjornw@mastodon.socialundefined
    Looking forward to represent @publicspaces @berlinfedidayThe program schedule looks awesome! With people like @_elena @evan @melaniebartos @andypiper @bjoernsta and many more sharing their ideas, experiences on and beyond the Fediversehttps://berlinfedi.day/ #Fediverse #PublicSpaces #Fediday #NextSocials