@adb thank you friend!
@dubious_dragon I think so.
@jakebrake @mayintoronto Hey, Jake. Your concerns are justified! It's never a bad idea to look at projects carefully.
tags.pub is one of the oldest projects on the ActivityPub network. It was one of the test implementations of ActivityPub. It's been dormant for years; we've been lucky enough to get to implement this with funding from the Sovereign Tech Agency.
The service is opt-in, either by user or by server (and users can opt out if their server opted in). Nobody has to use it.
Our Fediverse & Social Web track has been accepted for @COSCUP@floss.social 2026 (Taipei, Aug 8–9)! We’ll have a full day—six hours—to fill with talks on the #fediverse, #ActivityPub, and the open social web.
The CFP for speakers isn’t open yet, but we’ll announce it here when it is. Stay tuned!
#SocialWeb #COSCUP #fedidev
@hongminhee @COSCUP STAYING ABSOLUTELY TUNED
I'm chairing a breakout session on Reviving the #ActivityPub Social API at the W3C breakout day in a few minutes!
https://www.w3.org/events/meetings/fd048dc6-4486-4e21-a639-545523e4ca60/
📢 @w3c Breakouts Day 2026!
🗓️ Join us tomorrow - 25 March 2026, 13:00–14:00 UTC
The #ActivityPub specification defines a social API and a federation protocol. Mastodon and compatible platforms implement the latter but not the former.
Join @evan's session to discuss the social #API, its value in the distributed social ecosystem, and the efforts to revive its use.
▶️ https://www.w3.org/events/meetings/fd048dc6-4486-4e21-a639-545523e4ca60/
The "Reviving the #ActivityPub Social API" breakout session starts in 30 minutes!
@w3c @evan
@smallcircles OK, great. Let's try to keep the conversations there instead of here, so everyone can participate.
@smallcircles I'm not sure. It's pretty important for me to track user stories as issues -- that's been the best way to get things done in task forces so far.
@julian @Profpatsch oh, yeah, definitely. It's really our only way to authenticate requests right now.
@hongminhee oh, I'm so happy. I've seen too many implementations that assume the key id is a fragment, and just load that as the actor.
And I saw one that loaded the actor of the received activity and verified the signature against the actor's key, ignoring the keyID entirely!
I knew you would do it right! Thanks for the reassurance