Kurzer Hinweis an andere Mastodon-Admins: Diese Registrierungs-Spam-Welle ist noch nicht überstanden.

Bei lsbt.me kamen zunächst massenhaft API-Registrierungen mit Python/aiohttp rein. Auffällig waren Nutzernamen nach dem Muster bp plus 16 Hex-Zeichen und als Antragstext immer Automated protocol deliverability probe. Eine enge Sperre auf diesen User-Agent hat die erste Welle gestoppt.

Heute kamen trotzdem fünf neue Registrierungen mit denselben Nutzernamen und demselben Antragstext. Der Bot gab sich diesmal einfach als Chrome 126 aus. Genau deshalb taugt ein User-Agent nur als kurzfristiger Filter. Er ist ein frei wählbarer Header.

Die Requests laufen über POST /api/v1/accounts. Dieser Endpoint erlaubt Client-Apps, einen neuen lokalen Account direkt in der App anzulegen. Für OAuth-Verbindungen bestehender Accounts braucht ihn keine App. Auch #FediSuite nutzt ihn nicht. Sie registriert sich über /api/v1/apps, holt die Zustimmung über /oauth/authorize und arbeitet danach mit einem User-Token. Die normale Registrierung über die Mastodon-Webseite läuft ebenfalls getrennt über POST /auth.

Ich habe die API-Kontoerstellung auf lsbt.me deshalb komplett abgeschaltet. Webregistrierung, OAuth und bestehende Clients laufen unverändert weiter. Wer einen neuen Account möchte, registriert sich einmal ganz normal wie bisher im Web und kann danach jeden Client nutzen.

Falls ihr diesen optionalen Native-Sign-up-Weg ebenfalls nicht anbieten wollt, könnt ihr in eurem Nginx-Serverblock vor dem allgemeinen location /-Block Folgendes ergänzen. Das Beispiel setzt den in vielen Mastodon-Nginx-Configs vorhandenen @proxy voraus:

location = /api/v1/accounts {
  limit_except GET {
    deny all;
  }
  try_files $uri @proxy;
}

Damit erhält nur POST /api/v1/accounts ein 403. Der lesende GET-Endpoint bleibt erreichbar. Danach wie immer nginx -t und erst bei erfolgreichem Test reloaden.

#Mastodon #Fediverse #MastoAdmin #FediAdmin #FediMod #FediBlock #Moderation #Registration #Spam #Nginx #SelfHosting #SysAdmin #ActivityPub

Quick heads-up for other Mastodon admins: this registration spam wave isn't over yet.

On lsbt.me, we first saw a flood of API registrations using Python/aiohttp. The telltale signs were usernames following the pattern bp plus 16 hex characters, and the sign-up reason was always "Automated protocol deliverability probe". A narrow block on that user agent stopped the first wave.

Today, however, five new registrations came in with the same usernames and the same sign-up reason. This time the bot simply identified itself as Chrome 126. That's exactly why a user agent is only useful as a short-term filter. It's a header the client can set to anything.

The requests go to POST /api/v1/accounts. This endpoint lets client apps create a new local account directly in the app. No app needs it for OAuth connections to existing accounts. #FediSuite doesn't use it either. It registers itself via /api/v1/apps, obtains consent via /oauth/authorize, and then works with a user token. Regular sign-up through the Mastodon website is also handled separately via POST /auth.

So I've completely disabled API account creation on lsbt.me. Web sign-up, OAuth, and existing clients keep working as before. Anyone who wants a new account just signs up once on the web as usual and can then use any client.

If you'd also rather not offer this optional native sign-up path, you can add the following to your Nginx server block, before the general location / block. The example assumes the @proxy location that many Mastodon Nginx configs already include:

location = /api/v1/accounts {
  limit_except GET {
    deny all;
  }
  try_files $uri @proxy;
}

This returns a 403 only for POST /api/v1/accounts. The read-only GET endpoint remains reachable. As always, run nginx -t afterwards and only reload once the test passes.

#Mastodon #Fediverse #MastoAdmin #FediAdmin #FediMod #FediBlock #Moderation #Registration #Spam #Nginx #SelfHosting #SysAdmin #ActivityPub

A couple quick notes on ActivityPub

A few weeks ago, I made this site publish to ActivityPub (really mostly thinking about Mastodon, although as an open standard other software can consume it). Just wanted to write down a few notes on the experience for posterity. …

Read the full post

»Trunk & Tidbits, August 2026« https://blog.joinmastodon.org/2026/09/trunk-tidbits-august-2026/?Fedizen.EU #Fedizen #Fediverse #ActivityPub #News

Als Admin von #Friendica beschäftigt mich schon länger eine Frage:

Warum zeigen viele entfernte #Threads beim normalen Lesen nur zwei, drei Antworten und der Rest taucht erst auf, wenn ich (in friendica als Nutzer) „Vollständiger Thread“ anklicke, oft erst Tage später?

Die Ursache ist mir bekannt: #ActivityPub liefert nur adressiert aus, was nie zugestellt wird, kann mein Knoten schlicht nicht anzeigen.

Wie aber gehen andere Admins damit um? Ist das für euch eine akzeptierte Grenze des #Fediverse, oder justiert ihr aktiv an fetch_replies und max_fetchreplies_depth?

Mich würde interessieren, ob die Thread-Lücken bei #Mastodon, #Pleroma, #Akkoma und Co. genauso auftreten oder ob ich das primär in der Friendica-Welt zu spüren bekomme. Bei Mastodon sollte es IMHO jedenfalls genauso sein.

Wer von euch überlässt das Nachziehen der Replies-Collection komplett dem eigenen Server, wer greift manuell ein, oder hat einen pragmatischen Weg dazwischen gefunden?

Eigentlich sollte man erwarten, dass die ausliefernden Server ihre Replies-Collection halbwegs zuverlässig pflegen, statt dass jeder Betreiber auf eigene Faust nachhelfen muss.

Über konkrete Erfahrungen und Einstellungen würde ich mich freuen.

Ok, people of #Mastodon, can anyone explain to me why it is not possible to somehow connect #ActivityPub and #ATProto. It seems a bit ridiculous to me that we have #alternatives to #BigTech that seem to work against each other.
Links to posts or blogs that explain the problem a bit further would also be super helpful. Please share! Thank you! #Fediverse #Bluesky #Eurosky

Just finished listening to this interview with Eli Mallen (@iameli) of https://stream.place (from last year) talk about taking on Twitch in the open social web. He talked about his history in other protocol spaces like SSB and Ethereum and why he chose to work with #ATProto and not #ActivityPub
https://devtools.fm/episode/140

Laravel + PHP gains a batteries included package for ActivityPub support, with both draft-cavage and RFC 9421 HTTP Sig support and the ability to extend every aspect, with before() and after() hooks for easy custom processing.

It's quite amazing.

I'll be tagging a new release this week.

#laravel #php #activitypub #pixelfed #loops

Alt...

laravel-activitypub

The social web is evolving: into open, decentralized spaces no single organization controls. The Social Web Foundation is building a global town square that works for everyone: E2E encryption, GDPR-ready privacy, a healthier fediverse.

https://socialwebfoundation.org/

#SocialWeb #Fediverse #ActivityPub

laravel-activitypub, a batteries included ActivityPub package for laravel.

Soon will power @pixelfed and @joinloops

Shoutout to @FediverseSymbol

https://github.com/dansup/laravel-activitypub

#laravelActivitypub #laravel #activitypub #pixelfed #loops

Alt...

laravel activitypub readme header image

Okay, laravel-activitypub is near ready to ship!

I'll be testing it with shutter, a single user activitypub server for image sharing.

#laravel #activitypub #Pixelfed #Loops

Alt...

laravel-activitypub test suite, all tests passing now 😮‍💨

Alt...

screenshot of shutter.social

Making real progress on laravel-activitypub, a batteries included ActivityPub package for laravel.

This will replace federation logic in @pixelfed and @joinloops and make it really easy to implement AP in your own laravel apps!

#laravel #activityPub

Alt...

Laravel ActivityPub

#snac2 #fediverse #frugalfediverse

LOLA is a proposal for live online account portability between two ActivityPub servers at the request of a user. The goal is to allow the user to pursue the following workflow:

- Request a destination server to copy an ActivityPub account from a source server
- Authorize the destination server to the source server
- See the content in its new location after the destination server completes copying it over
- Optionally, at a later time, ask the source server to send notifications to followers that the account is moving
- Optionally, at a later time, redirect the content at the source server to the destination server

https://swicg.github.io/activitypub-data-portability/lola

#W3C #LOLA #ActivityPub #Fediverse

I do host my own single user #snac server and want to keep it that way. I do have more than one account, but since I am by myself - my local timeline is useless. If I only could have geographically close messages in there!

This feature belongs into #ActivityPub and not in one implementation of it!

Also pinging @grunfink@comam.es - maybe you're insterested

ActivityPub - Is it worth defending against replay attacks and message/signature time skew?

Here's a problem that I've found with ActivityBot - my little ActivityPub server. Sometimes it receives messages which were originally sent months ago. Why does that happen and is it risky to accept and process them?

My tl;dr is that it probably isn't worth worrying about. But I'd love someone to tell me why I'm wrong.

Here's my thinking:

Causes

All ActivityPub messages should have a "published" timestamp in their body. Some will have an "updated" timestamp. That tells you, unsurprisingly, when the message is alleged to have been originally published or updated. That time might be very different to the time you receive the message.

There are, I think, three different reasons why a server might receive a message which has an out-of-date timestamp.

The first is that sometimes servers are just slow. Processing thousands of messages at the same time means that some of those messages take a while to send. ActivityPub is one big chain-mail so it can take several minutes for a message to be sent to all your followers.

Similarly, your server might be slow. If it doesn't acknowledge receipt of a message, the original server will try sending it again. Sometimes that can take a while.

Finally, some servers take a relaxed view of standards. They send an update to an old message but keep the original publication date. Ideally, they'd use an "updated" timestamp but quite often they don't.

For the purposes of checking the legitimacy of the message, you do not need to check when a message says it was published or updated. You might want to check it isn't an obviously bogus date like far in the future or impossibly far in the past - but that's up to you.

It is normal that your server receives messages which appear to have been published at a totally different time from now.

Is that a problem?

Probably not.

As described above, there are various reasons why a message may be delayed in transit - or may appear to come from the distant past.

What we can check is when the message was cryptographically signed by the sending server. This is independent of its published or updated timestamp.

HTTP requests to your server will have a date header which looks like Tue, 01 Sep 2026 15:54:21 GMT - this is in the slightly peculiar and Anglocentric RFC 5322 format.

New style RFC 9421 headers will also have a signature-input header which will contain something like created=1788278061. That uses the slightly obscure UNIX / POSIX time which counts seconds since the "Epoch" of 1st January 1970.

If you convert the UNIX time to something more modern, you should get an identical value to the date header.

But that isn't always the case. For example, the RFC 9421 standard gives this example:

 Date: Tue, 20 Apr 2021 02:07:55 GMT
"@signature-params": ("@method" "@authority" "@path" \
  "content-digest" "content-length" "content-type")\
  ;created=1618884473;keyid="test-key-rsa-pss"

Converting 1618884473 to normal time gives Tue, 20 Apr 2021 02:07:53 - a two second difference.

If the date and created values differ significantly - that may indicate that the message is untrustworthy. Or that there was a delay between the signing and the sending.

The spec says:

The Date header field value represents the timestamp of the HTTP message. However, the creation time of the signature itself is encoded in the created signature parameter. These two values can be different, depending on how the signature and the HTTP message are created and serialized. Applications processing signatures for valid time windows should use the created signature parameter for such calculations. An application could also put limits on how much skew there is between the Date field and the created signature parameter, in order to limit the application of a generated signature to different HTTP messages.

7.2.4. Choosing Signature Parameters and Derived Components over HTTP Fields

But, of course, it doesn't tell you how much skew is problematic. It's up to you how much skew you're prepared to accept.

So that's the difference between the sent time and the signed time. The next time to check is your own. As we've discussed, sometimes servers are slow sending things out. Would you accept a request that was signed five minutes ago? Five days ago? Five months ago? What amount of difference is dangerous?

Here's what various services and sages have to say:

Mastodon

The request contains a Date header. Compare it with current date and time within a reasonable time window to prevent replay attacks.

How to make friends and verify requests

What is "reasonable"? The source code suggests one hour.

Grishka

Time in the Date header must differ from the recipient server’s clock by no more than 30 seconds

A bare-minimum ActivityPub server from scratch

Evan Prodromou

static #maxDateDiff = 5 * 60 * 1000 // 5 minutes

activitypub-bot

SWICG

The standards don't give a concrete time window to use for this comparison. In practice, an hour plus a few minutes buffer in either direction may be a good value, to account for both clock skew and differences in time zone/daylight savings time configuration across systems.

How To Verify a Signature

Others

Without naming names, it looks like a bunch of popular servers don't check whether there's a significant difference between the date the request was signed and the date it was received.

Summary

Various documents and implementations recommend anything between 30 seconds to "a bit more than 60 minutes". Or they just ignore any date difference.

What's the right answer? What happens if the signed date is significantly different from the current date?

What are we trying to protect against?

Replay Attacks. Suppose someone is listening to the communications between the sending server and your server. They copy the message that is sent to you. Later they send it again!

At this point, you might be thinking "so what?" and… I'm inclined to agree with you!

What's the worst that could happen if you received the same message multiple times? Two things that I can think of.

Firstly, it might not be the same message. It is possible to send a new message but with old headers. An attacker could make someone post "I hate Taylor Swift" against their will and watch as legions of fans disembowel the victim.

Except, I don't think this is likely. The signature in the header contains a hash of the message being sent. If you are properly validating the signature, a changed message will have a different hash from the one in the original message. You don't need to check timestamps, you just need to check if the hashes match.

Secondly, idempotence. That's a fancy word for "pressing the button multiple times should only result in one action".

What happens if a user appears to send you multiple "like" messages for a single post? You only record one like.

What if they send multiple messages with the same content? Well, each will have a unique ID in the message - so you only post it once.

What if they send multiple anythings? I can't think of any ActivityPub action which would not be idempotent.

About the worst thing I can think of is this:

• Alice sends a message to you saying "I want to follow Bob".
• Mallory intercepts this message.
• You record Alice is now following Bob.
• Alice sends a message to you saying "I want to unfollow Bob".
• You record the severed relationship.
• Mallory replays the original follow message.
• You record Alice is now following Bob.

It's also possible the following could happen:

• Alice posts a message saying "I love The Beatles".
• You record Alice's message and display it on the timeline.
• Alice updates her post to say "I love the Rolling Stones".
• Mallory intercepts this message.
• You record Alice's updated message and display the new version on the timeline.
• Alice updates her post yet again to say "I love the Spice Girls".
• You record Alice's updated message and display the new version on the timeline.
• Mallory replays the original update message.
• You now display that Alice loves the Stones rather than Spice Girls.

Perhaps the same can happen with like/unlike, block/unblock, boost/unboost.

But none of that is significantly prevented by checking the date.

Ultimately, it is up to your sever to check the unique ID of each message and refuse to action any repeated messages. You may not want to trust the unique ID which is sent with the message. If that's the case, you can calculate your own - perhaps using a hash of the contents, the signature, or some other process which will generate an ID based on the message.

Putting it all together

Here's what you need to do to prevent replay attacks:

1. Independently calculate the hash of the message received.
2. Validate that your calculated hash matches the hash sent in the message's HTTP headers.
   • If not, this is a potential replay attack and the message must be ignored.
3. Verify that the signature received in the message's HTTP headers includes the message hash and is cryptographically valid.
   • If not, the signature is invalid and the message must be ignored.
4. Has the received message's unique ID already been processed?
   • If so, refuse to process it again.

I don't see what checking the timestamp of the HTTP signature has to do with anything. Someone who has access to the original messages and their headers could send them milliseconds after the original delivery.

I think it is probably pragmatic to give messages 60ish minutes grace before dropping them. Delays happen, but anything more significant than an hour might indicate a attack. But, equally, might just mean that the Internet is having a slow day.

If you are correctly checking signatures and hashes, I don't think you need to worry about skew between signature date and delivery date.

No! You're wrong and I can prove it!

Please tell me where I have erred! Stick a comment in the box or drop me an email. If I've made a massive or subtle mistake, I'd love to know what.

Alt...

Logo for ActivityPub.

I just added a new watchlist to the fediverse.party wiki, for CMS that have ActivityPub plugins;

https://codeberg.org/fediverse/fediparty/wiki/CMS+with+ActivityPub+plugins+-+watchlist.-

As always, if you see any gaps or errors, sing out!

#FediverseParty #ActivityPub #Plugins #CMS

RE: https://mastodon.social/@dansup/117246306213045632

I swore not to speak about #FediHood any more, but what #Pixelfed is doing is great news for #ActivityPub.
Pixelfed already sends the location as a Place object with latitude and longitude, so FediHood can read it and put markers on a map.
Local timelines used to mean one instance. Now they can mean people actually around you.

Daniel Supernault boosted

Daniel Supernault » 🌐 2026-09-10
@dansup@mastodon.social

Places, a unique Pixelfed feature that allows you to add an optional location to your posts to make them discoverable by place!

We are working to support custom places too!

#pixelfed

Alt...

Pixelfed Places feature

RE: https://mastodon.social/@dansup/117246306213045632

I swore not to speak about #FediHood any more, but what #Pixelfed is doing is great news for #ActivityPub.
Pixelfed already sends the location as a Place object with latitude and longitude, so FediHood can read it and put markers on a map.
Local timelines used to mean one instance. Now they can mean people actually around you.

Daniel Supernault boosted

Daniel Supernault » 🌐 2026-09-10
@dansup@mastodon.social

Places, a unique Pixelfed feature that allows you to add an optional location to your posts to make them discoverable by place!

We are working to support custom places too!

#pixelfed

Alt...

Pixelfed Places feature

Week in Fediverse 2026-09-11

Servers

- Hubzilla v11.4.1
- Bookwyrm v0.9.3
- Cookifed v0.1.0
- Ktistec v3.12.1
- Misskey v2026.9.0
- gathio v1.6.7
- NeoDB v0.18.2
- Appy v0.7.0
- PieFed v1.7.15
- Wafrn v2026.09.01

Clients

- Voyager v2.49.0
- Miria v4.0.1
- Aria v1.5.13

Tools and Plugins

- Enable Mastodon Apps v1.6.4 (WordPress plugin)

Articles

- Static ActivityPub Publishing

-----

#WeekInFediverse #Fediverse #ActivityPub

Previous edition: https://mitra.social/objects/01a06eb0-8683-70d3-bb1d-19ef2967e02b

Sharkey is generally no longer actively maintained. Much like IceShrimp, which shifted its focus from IceShrimp-js to IceShrimp.net, Sharkey is effectively in "maintenance mode only." This means it still receives critical security updates and required patches, but it generally no longer tracks upstream Misskey development.

Sharkey's latest release: 2025.4.7

Misskey's latest release: 2026.9.0

I had to laugh when, back on January 13, 2026, they titled a release "2025.4.5 — We'll catch up, we promise." The release right before that had been 6 months earlier. In all the time since, they've only pushed out 2 security updates. They are now well over a year behind Misskey's development.

If anyone has the time and skills, I hope someone builds a script to migrate Sharkey sites back to Misskey. Since Sharkey is a fork of Misskey (as was FireFish), it should be possible and is a smart precaution.

#Sharkey #Misskey #FireFish #OpenSource #Fediverse #ActivityPub

🆕 blog! “Scattered thoughts on social geolocation”

I want to be able to share my location with my friends on social media. Twitter (RIP) had a way to attach an optional location to a post. Facebook still lets me check in to venues. But neither ActivityPub (Mastodon) nor AT Protocol (BlueSky) allow me …

👀 Read more: https://shkspr.mobi/blog/2026/07/scattered-thoughts-on-social-geolocation/
⸻
#ActivityPub #BlueSky #fediverse #FourSquare #geolocation #json #openstandards #OpenStreetMap

The EFF is promoting the Fediverse in an online event next week!

We've put it on our community calendar: https://fediforum.org/events

#eff #fediverse #activitypub

FediForum Fall 2026 starts in four weeks, exactly.

Registrations and proposed topics are coming. Check some of what has been proposed so far on https://fediforum.org/2026-10/

#fediforum #opensocialweb #event #activitypub #atproto

Right after @berlinfediday is over, I am hosting another edition of
Berlin Federated Network Exploration Circle / #BFNEC
Sept 13th at 7pm at @offline

✸ @pukkamustard will talk about their work on ERIS and give us the backstory on their initiation of the fediverse's FEP process.

⁂ @f will discuss his work on @sutty, a platform aimed at giving organizations and collectives the means to publish and host more secure websites. He will also talk about how they recently added #ActivityPub federation.

Alt...

Berlin Federated Network Exploration Circle a cosy meeting of humans who want to discuss this strange networked world together September 13th, 2026 (7pm) at Offline ✸ pukkamustard will talk about their work on ERIS and give us the backstory on their initiation of the fediverse's FEP process. ❋ f will discuss his work on Sutty, a platform aimed at giving organizations and collectives the means to publish and host more secure websites. He will also talk about how they recently added ActivityPub federation. ⁂

Week in Fediverse 2026-09-04

Servers

- Ktistec v3.12.0
- Mastodon v4.7.1
- Vernissage v1.43.0
- snac v2.95
- ActivityPub for WordPress v9.3.0
- Owncast v0.3.0
- gathio v1.6.6
- NodeBB v4.15.2
- tootik v0.25.2
- NeoDB v0.18.0
- Bonfire v1.0.7

Clients

- PleromaFE v2.11.4
- Fedilab v3.43.3
- Tuba v0.11.1
- Pixelix v5.2.0
- Summit v1.85.0
- Shoot Web App v1.3.0

Tools and Plugins

- FediFetcher v8.2.0
- Poduptime v6.3.2
- Enable Mastodon Apps v1.6.3 (WordPress plugin)

For developers

- APx v0.27.0
- Library progress report - September 2026 (GoActivityPub)

Articles

- A reasonably practical guide to validating RFC 9421 HTTP Signatures for ActivityPub in PHP

-----

#WeekInFediverse #Fediverse #ActivityPub

Previous edition: https://mitra.social/objects/01a04a26-eede-72b0-a5e9-f244c3ff2142

🆕 blog! “A reasonably practical guide to validating RFC 9421 HTTP Signatures for ActivityPub in PHP”

If you're reading this, you've probably been hitting your head against a brick wall trying to parse and decipher the new HTTP Signatures sent by Mastodon and other Fediverse servers.

This is a…

👀 Read more: https://shkspr.mobi/blog/2026/09/a-reasonably-practical-guide-to-validating-rfc-9421-http-signatures-for-activitypub-in-php/
⸻
#ActivityBot #ActivityPub #mastodon #php #webdev

#Loops has entered #beta with #ActivityPub support, allowing users to connect with creators across the #fediverse. This means users can follow and interact with creators on platforms like #Mastodon and #Pixelfed, and vice versa. Loops has implemented several technical features to ensure smooth federation, including a shared inbox, HTTP signatures, and smart content representation. https://blog.joinloops.org/loops-joins-the-fediverse/?Fedizen.EU #Fedizen #Fediverse #ActivityPub #News

Hashtag following also allow URLs to RSS feeds of ActivityPub objects (like e.g. https://mastodon.social/tags/ThankYouTuesday).

Users can now configure a webhook to receive an HTTP POST for every notification. This can be useful for implementing bots that react to activities, like autorepliers, chatbots or interactive textual games (see snac(1) for more information).

The number of pending follow confirmations is shown next to the "people" link.

Faster performance metrics (contributed by dandelions).

Improved lowercasing in hashtags (contributed by postscriptum).

A search-by-url tweak for implementations that return 200 for invalid webfinger queries (e.g. piefed).

Mastodon API: added follow confirmation endpoints, fixed collisions in attachment file names.

Fixed potential crashes in attachment uploads.

https://comam.es/what-is-snac

If you find #snac useful, please consider buying grunfink a coffee or contributing via LiberaPay.

#snacAnnounces #FrugalFediverse

Notifications are now shown in a more compact way (i.e. all reactions are shown just above your post, instead of repeating the post ad nauseam for every reaction).

New command-line option unmute to, well, no-longer-mute an actor.

The private timeline now includes an approximate mark between new posts and "already seen" ones.

Fixed a spurious 404 error in the instance root URL for some configurations.

https://comam.es/what-is-snac

If you find #snac useful, please consider contributing via LiberaPay: https://liberapay.com/grunfink/

#snacAnnounces

This release has been inspired by the song The Answers to the Questions by #Christabell and #DavidLynch.