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

Kind of a weird #Fediverse question: do any platforms in this space offer an API for user account registration?

One hypothetical idea I’ve been kicking around is the notion of “pre-registration” for the Fediverse. Basically, a person fills out their profile, imports data archives from other networks, and maybe even finds their mutuals somehow. When they’re done, their account gets created on a random vetted instance, data gets backfilled, and follow requests get sent out to the mutual contacts they’ve found.

I think it’s a good idea, and possibly a good showcase for both the #ActivityPub C2S API and possibly LOLA. However, I don’t think any particular platform supports all of the required pieces yet.

Alt...

A mockup of an app, showing my name and face, as well as different social networks to connect to for data import.

Alt...

Next step in the mockup for a Facebook import, allowing me to pick and choose what data is most important to me.

Alt...

A final stage mockup showing a recommended server with its name, domain, and rules. Obviously needs a touch up, but the idea is that everything is spelled out to the person about where they're going.

Because we changed our domain, our #ActivityPub #ThreatIntel federation also changed! You can follow @threatintel for all posts in our forum's Threat Intel category.

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

Is "Quiet Public" a #GotoSocial thing, or is it #ActivityPub? #tech #mastodon

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. ⁂

Public Messaging Platforms

‣ Simple: Plain old website with #RSS feeds

‣ Emergency Alerts: #CAP (Common Alerting Protocol) + delivery backends like #CellBroadcast

‣ Microblogging: #Mastodon (AP)

‣ Long form content: #WordPress + AP plugin

‣ Video hosting: #Peertube (AP)

Notes:
• AP: #ActivityPub
• This is only a small sample of the options available.
• These platforms are in use globally for this purpose.

@goku12

For #ActivityPub applications people may refer to the three deligthful #fediverse curated lists I maintain. See the ToC in the top-level list at:

https://delightful.coding.social

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

Fixed a bug in the notification page that made snac hang forever while trying to read abnormally big files.

Improved support for text-only web browsers: it's now possible to configure a set of web browser user-agent strings that will receive simpler HTML in the private timeline web UI. Basically, it consists in avoiding details / summary HTML tags as much as possible.

Added some fixes to media proxy code.

Fixed EmojiReact code to allow any emoticon defined in emojis.json, not only those with colon-wrapped identifiers.

Fixed a bug in notification filtering (paging was sometimes incorrect).

Added a notification filter for Webmentions.

Mastodon API: Don't return reactions count as string (contributed by mkljczk), implemented GET /v1/media (contributed by clairemont).

Fixed bug in documentation examples (contributed by Sprite_tm).

Updated Ukrainian and Russian translations (contributed by wincentbalin and koru).

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

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

#snacAnnounces #FrugalFediverse

#FediHood now supports #Lemmy through #ActivityPub. You can subscribe/unsubscribe from groups, read threaded discussions with their upvote scores, and reply or upvote yourself (through the fav button).

This is the first step: FediHood will also automatically split messages into city, region and country groups that everyone on the fediverse using groups will be able to interact with.

I recently discovered that Jorge Aguilera (@jorge) gave a 1 hour introduction to #ActivityPub in Spanish called "ActivityPub: El Protocolo que Impulsa el Fediverso" at Commit Conf in Madrid and the whole thing was recorded:
https://koliseo.com/commit/2026/agenda/1?selected=JNIEz5zgefpMwrJMRpl7 #fedidev #fediverso

Alt...

a screenshot showing Jorge Aguilera talking about Webfinger

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.