@weekinfediverse@mitra.social We can also announce that Klonkt 1.6.0 was released last night and is looking for a maintainer. It is the first release with the proposed FEP-633c: Guardians implemented and the last one before a refactor. These are exciting times for us and we are focusing on the future again. A few major changes have already made it into the new version on the main branch on GitHub and foreseeing changes to the ActivityPub service that has grown substantially we do not have the capacity to do both.Klonkt is a NodeJS project with a modest dependency footprint and is aimed at independent artists and other kinds of publishers. 

In a perfect world, I would have one account, I could follow everyone, and everyone could follow me.The Fediverse is not in a perfect world.Admin1 does not like Admin2, but I want to follow User1 and User2, who have nothing to do with their drama. And User3 and User4 want to follow me, who also have nothing to do with their drama.Likewise, despite being a good boy and following all my site rules, your site rules, and everyone else's site rules, Admin3 doesn't like me. So now User5 has to be creative to follow me, and I have to be more creative for User6.This is the fragmentation of the Fediverse. It is annoying, but there is not much a single user can do about it. It is, however, why apps like FediLabs exist and allow you to use multiple accounts in a single app.Let that sink in. Enough people have been annoyed by this nonsense that they have dedicated their free time just to develop and support apps to overcome the fragmentation.If you have never heard of the apps, I suggest you look into them: @apps#Fediverse #ActivityPub #Mastodon #Misskey #OpenSource #Foss

I wonder whether there are any opportunities (for me) to work with #activitypub and #fediverse. My background is in #PHP (decoupled #Drupal), but I am keen to diversify into other languages. I also have solid experience with #REST, #bash and CLI tools.#Fedihire

Activity-Relay Server 2.5.0 RC 1 is now live at https://relay.argentwolf.orgPlease help me out with connecting and testing! If you have any issues, please let me know! You can reach me at @alan, or open an issue on https://github.com/thystra/Activity-RelayWhat’s new in Activity-Relay v2.5.0-rc1Adds relay-signed actor and object fetches for Mastodon authorized-fetch and secure-mode compatibility.Publishes the relay actor as an ActivityStreams Application, allowing current Friendica versions to discover and register the relay while preserving the existing actor ID, endpoints, and public key.Uses a shared, exact-authority HTTP-signature implementation for both authorized fetches and outbound delivery.Adds durable per-receiver delivery-health tracking through /status.json schema version 4.Adds an optional private observability listener for Prometheus metrics, process health, and Redis-backed readiness checks.Adds bounded Redis-backed operational metrics shared across the API and worker processes.Migrates asynchronous delivery to the maintained Redis-only Machinery v2 fork.Adds leased in-flight task claims and at-least-once recovery, preventing silent task loss after an abrupt worker or host failure. A duplicate delivery remains possible if the remote server accepts a request immediately before the worker terminates.Preserves the existing actor key, actor address, queue data, delayed retries, configuration names, and Redis database through the tested upgrade path.Includes extensive package, rollback, Redis-failure, worker-interruption, Mastodon, Friendica, NodeBB, container, race-test, and production validation.Full RC changelog: Activity-Relay v2.5.0-rc1 changelogFull release notes and downloads: Activity-Relay v2.5.0-rc1 releaseKnown limitation: NodeBB 4.14.2 may return HTTP 424 when it performs an unsigned follow-up fetch from an origin that requires signed GET requests. The relay-delivered request itself remains properly signed. (Bug Report)If you find this project useful, please give it a star on GitHub! Any tips and/or support contributions are appreciated!#activitypub #friendica #mastodon #fediverse #nodebb #relay #relayserver #relayservers

@birdwing no, this option is intended exclusively for profiles deleted by moderators and not for profiles who have decided to delete their account.

@alan Amazing!

littleMesh addendum: readable handles and replaceable relays Yesterday's post left one thing unsolved. Your littleMesh identity is your Ed25519 public key, which is great for security and terrible for a handle: nobody wants to type @alice@a1b2c3...52-characters....mesh.littlefedi.social, let alone read it out loud. And the lighthouse we mentioned, the relay that introduces you to the world, was baked into that identity too. Change relay, and you'd look like a different node. We've been studying how to fix both, and we think we see a path. The idea is a small signed directory sitting next to the mesh itself. You'd reserve a friendly alias, something like red-house.mesh.littlefedi.social, and your node would publish a signed record binding that alias to your node ID and to up to three lighthouses. Signed with the same mesh key you already have, no new identity, no new PKI. The record would carry a sequence number and an expiry, so nobody, not even the directory operator, could roll it back to an older version or serve a stale one past its time. What we like about it is what it wouldn't change. Your handle would stay @alice@red-house.mesh.littlefedi.social, readable. Underneath, WebFinger would still resolve to your real actor ID, the one built from your node ID, exactly as today. And switching lighthouses, would just mean publishing an updated signed record. Same handle. Same actor ID. Nobody following you would notice anything happened. The directory itself would stay deliberately weak in what it's trusted with. It couldn't produce a valid record for your node ID without your key, and every connection would still authenticate the node ID end to end, so even a malicious or compromised directory could deny service but never impersonate you. We're building this over the next few days, opt-in, as an experiment. Once it's up, we want to see it survive a real follow exchange with stock Mastodon, snac and GoToSocial, and a lighthouse swap that doesn't touch the handle, before deciding whether it earns a permanent place in littleMesh or gets reworked. Worth trying, not yet worth trusting. #littleFedi #littleMesh #Fediverse #OwnYourData

Il primo dominio che registrai nella mia vita fu fuocoelegna.it, nell'aprile del 2000. Avrei voluto registrare altri domini sotto il tld .it a quell'epoca, ma non lo potevo fare perché non avevo la p.iva e non mi andava di prenderla per una cazzata simile. Esisteva quella che a mio giudizio è una assurda e stupida regola tutta italiana: I privati senza p.iva potevano registrare uno e un solo solo dominio sotto il tld .it. Quel limite venne poi eliminato quasi ben cinque anni dopo.

[image: Screenshot_from_2026-07-29_01-22-20.png] It's been a while since an update! While the automated status updates on this account have stopped (four years ago), the site has been running in the background all this time. Work has been done by the new owners to fix some of the performance related issues, and to modernize the site. Latest updates, in addition to fixing loading times, include icons for most of the major platforms and a search box for instance names. Check it out and join the Matrix chat room. https://the-federation.info #thefederation #fediverse #activitypub #diaspora #decentralization

littleFedi introducing littleMesh We've been buried in littleFedi work lately, and there's one piece I want to talk about because it's the one I'm genuinely excited about: littleMesh. The problem is an old one. Federation assumes you have a domain, a public IP, an open port, a TLS certificate. Fine if you're renting a VPS somewhere. Not fine if your instance lives on a Raspberry Pi in your house, behind CGNAT, with an ISP that will never hand you a real IP address no matter how nicely you ask. Until now, that simply meant no federation for you. Full stop. littleMesh gets rid of that requirement entirely, without asking you to build any of the infrastructure above. On first run, your instance generates its own Ed25519 keypair. That key becomes your identity, no domain required, because your instance's address is derived straight from your public key, in the form <your-node-id>.mesh.<suffix>. Then your node opens an outbound connection to a "lighthouse", a small, publicly reachable relay, and registers itself there. Since the connection is outbound, it works from behind any NAT, any CGNAT, with zero port forwarding. The ISP never even notices. When someone wants to reach you, they ask the lighthouse to open a circuit. The lighthouse introduces both sides, you call back, and it splices the connection together, but it only ever sees encrypted bytes, never your actual traffic. Once the introduction is made, if you happen to have a reachable address after all, both sides skip the relay and talk directly. If not, the relay just keeps carrying you, quietly, in the background. And if you already run an instance with a real domain, you can still turn on littleMesh, purely to reach mesh-only instances. Your own identity doesn't change at all. There will be a default pair of community lighthouses, so you don't even need to find or run your own relay to get started, just say yes during littleFedi init and you're on the mesh. The fediverse shouldn't require you to be reachable. It should reach you. #littleFedi #littleMesh #Fediverse #OwnYourData

Only 2 days left to share your voice in our annual #Fediverse survey!If you run, manage, or moderate a #SocialWeb service, your anonymised and aggregated feedback goes directly to lawmakers and regulators around the world.If they don’t know our concerns, they can’t write laws that protect our mission.Help shape the policies that impact us. Take 5 minutes to share your experience:➡️ https://tally.so/r/81MW6k

We're still in kinda stealth mode, as we don't have any formal release yet, and our instances are invite-only.But we will publish our first release after the holidays, and start openly inviting folks around the same time.Until then, you can find us at https://cookifed.dev !

@dansup Congratulations! 🥳

Today is announcement day 🔥 Bonfire is shifting its centre of gravity: from social features to community tools. Four things ship today, and the whole story is here: bonfirenetworks.org/posts/bo... 1. Bonfire for communities Groups and topics, community rules, decision-making (from quick polls through structured consensus to weighted score voting, where an objection can count for more than an approval), events, shared organisation profiles, announcements. A ready-to-use space you can then take apart: add what's missing, fork what almost fits, switch off what you don't need. 2. Our first Mosaic case study Six months with Jacobin's German edition, building jacobin.social from the ground up: a home for 3,000+ readers, wired into their Ghost publication, in their language and their look and feel. Their readers crowdfunded the project, which included a reboot of the magazine and a new community space. Now every publisher can benefit. What one community funds, every community inherits. Details: bonfirenetworks.org/case-stu... 3. A deep Ghost integration Keep publishing exactly as you do now, and Bonfire can become the home for everything that happens around the work: your archive imported, new articles followed, members and tiers synced, sign-in through Ghost, federated discussion under every piece. Details: bonfirenetworks.org/ghost/ 4. The Telling One script tag turns any web page into a federated conversation. Readers reply with an account they already have, on Bonfire, Mastodon, anywhere. The thread lives on your server, and you can take it with you. Details: bonfirenetworks.org/telling/ Being straight with you: this is a 1.0 beta. Groups work within a server and don't federate yet. We're designing that in the open with the W3C groups task force, because we'd rather it work across the whole fediverse than ship a dialect only Bonfire speaks. Want to poke at it? Groups are live on the campground, our open test instance. Make an account and try it out: campground.bonfire.cafe Finally, we've rebuilt the website to reflect the new direction: bonfirenetworks.org/ Now back to following up with crowdfunding backers to organise install parties, co-design workshops, and other rewards. Thank you for your patience 💛<span class="invisible"> <a class="hashtag" rel="tag ugc" href="https://bonfire.cafe/hashtag/fediverse">#fediverse</a> <a class="hashtag" rel="tag ugc" href="https://bonfire.cafe/hashtag/activitypub">#ActivityPub</a> </span>

@alan@friendica.argentwolf.org well, good news, I'm now a follower... but bad news, that's not right behaviour on my end, so that's firmly on me <img class="not-responsive emoji" src="https://activitypub.space/assets/plugins/nodebb-plugin-emoji/emoji/android/1f613.png?v=c7cc56fe415" title=":sweat:" /> But at least it sounds like I'm able to receive your activities now!

@hpod16 @luca @Aakerbeere @EUauditors @janalbrecht Is it just me or only @HennaVirkkunen is “institutional”? 8-(

@denial403 @internetOggi manderemo un messaggio anche per promuovere Matrix 😀

The Blog Option in littleFedi littleFedi, like many social platforms, had both a strength and a limit. Posts, by their nature, are ephemeral. They get published, federated (unless local-only, which littleFedi handles) and then, over time, lost. Partly through self-deletion, partly through their normal blending in with the thousands of other posts that pile up over time. Sometimes, though, we want something to stay. And not just stay as a social post, but as an actual blog. A bit like with BSSG, I had thought it would be convenient to have a minimal system. Not to compete with WordPress or other solutions, but to have a small blog, integrated into littleFedi, that would produce and serve a blog updated every now and then, whenever the person writing felt like doing it. And that's why the blog option was born. The idea is simple: when you write a post, from the web UI or from the CLI, there's a checkbox, "blog post". If you check it, that post stops being just a status that will scroll past and disappear. littleFedi renders it into a real static site. No JavaScript, just HTML and CSS, an Atom feed, tag pages, a chronological archive. Nothing exotic, nothing that needs maintenance five years from now. The blog isn't a parallel system you have to feed separately. It's not an export, not an import, not a bridge to some other CMS. The post you wrote is the blog post. Same database, same act of writing, still boostable, still repliable, still part of the conversation on the fediverse side. The blog is just a second representation of the same content, generated automatically. Every time you create, edit, or delete a blog post, the whole static site for your account gets rebuilt from scratch, and the new version replaces the old one atomically, so nobody ever lands on a half-built page. If the build fails, the previous version stays in place. Simple, but it has to work reliably, or the whole idea is pointless. That's the core of it: two representations of the same post. As a status, it lives in the fediverse, interactive, part of the conversation, subject to replies and boosts like anything else. As a static page, it lives on the web, durable, indexable, with a permalink, something an RSS reader can hold onto. You don't have to decide in advance which posts deserve to last. You write normally, and if something turns out to be worth keeping, you flag it, and it gets its own page. One detail I cared about while thinking this through: the generated site has to be self-contained. When littleFedi builds it, media gets copied or hard-linked into the generated directory - images, audio, video. If it's stored on S3, it keeps its public URL directly. Either way, the point is that the site on disk doesn't depend on the instance staying up. If the server goes down tomorrow, the blog files are still a complete, working website. That wasn't an afterthought, it was one of the requirements from the start. Not every account gets a blog, and that's intentional. The instance admin has to enable the feature globally ([blog] enabled = true), and then grant it per account. It's not meant to be a CMS, and I didn't want it to become one. Blog posts can't be replies, can't be boosts, have to be public and top-level. These are constraints, not missing features: the blog is for your own writing, not for threads or reshared content. There's no JavaScript anywhere in the generated site. That was deliberate too. It loads fast, it works offline if you cache it, and it will still render correctly in ten years without anyone having to update a dependency. In the end, the blog option doesn't ask you to choose between writing socially and writing something permanent. You keep writing the way you always do, on littleFedi, and if a post is worth keeping, you check a box. No separate platform, no migration, no vendor lock-in. Just your own posts, some of them rendered into a small static site you can host anywhere, built out of something that already existed on the open web. Remember: all this is being currently served by a Raspberry PI Zero W powered by NetBSD Here's the result: https://rpi0w.stefanomarinelli.it/@stefano/blog/691cb62e-e7a1-434b-ba65-d059ee58ac41/ #littleFedi #SSG #BSSG #OwnYourData #Blogging #Fediverse #NetBSD

@phnt I don't see it that way. There are at least 4 different fediverse symbols. One of them was introduced by Ghost (IIRC) but it didn't gain much traction.

@aliceif I've just always been able to do it on Mastodon and Sharkey so I wanted to know if it was possible and if so how to do it on Misskey.