I think if there's one thing I'd say to #ActivityPub developers, it's this: it seems like it's going to be easier to just parse Activity Streams 2.0 data as plain JSON, but it's not. You have to keep track of too many variations. Use a JSON-LD library instead. For JavaScript, try activitystrea.ms:
@trwnh "more actively maintained"?
The code is long-term but it was built by one author of AS2 and maintained by the other. It works well, and I use it in production systems all the time.
I'm pretty sure @hongminhee has made a similar package, although I'm not sure it's distributed independently.
@evan@cosocial.ca @trwnh@mastodon.social I’m maintaining the @fedify/vocab package which depends on the jsonld package from Digital Bazaar. It’s written in 100% TypeScript, and has worked well on production services!
@julian@activitypub.space yeah, i know 🥲
I have a lot of things I wanna do on Misskey/Sharkey - give me a few more months and this will be totally transformed =)
@evan@cosocial.ca
📢 @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
@julian @Profpatsch oh, yeah, definitely. It's really our only way to authenticate requests right now.
@smallcircles @julian I think we might have different ideas about what the ActivityPub API task force is for.
To me, it's about making it possible for clients to use different servers, and different implementations of the API. That's going to include the social API defined in the ActivityPub standard, but it will also encompass things like rate limits, authentication, caching, CORS, and so on.
How that all gets documented will probably be in one or more community group reports.
The extent to which the default profile becomes a 'straightjacket' impact scope, applicability, and usability. I guess its alright as long as there's sufficient flexibility and extensibility taken into account. Guess the "sufficient" does the heavy lifting here.
@smallcircles @julian I think that's always a tension in standards! How do you make it explicit enough that developers can build interoperable software, but extensible enough that they can try new things?
I think one pattern that works well is some base-level standards assumed, and easy ways for extensions to be discoverable and negotiable. If your preferred extension isn't available from the software on the other side of the line, you fall back to the base-level standard.
> Rate limits are a common part of APIs.
Yes, of API *implementations*, and they may become part of the public interface of these implementation. Whether they should be part of an open standard protocol specification is a different matter imho. Perhaps in a separate implementation guide, suggesting recommended practices.
Or perhaps there may be some way to formulate a generic mechanism in the protocol specification that makes rate limits an extension point, without pinning to a particular method, esp. if it is only a de facto standard.
(Other example. The fediverse is still pinned to an expired draft of HTTP signatures.)
OTOH if the goal of the task force is to mostly just provide implementation guidance, and maybe a reference impl, then I guess examples of rate limiting may be provided.
@smallcircles @julian the point of the API task force is to make using the API across servers possible. That's why we're doing the OAuth work. I think rate limiting is part of the basic profile; it's one of the things you need to support to use the API across different servers.
@julian There are 3 main clusters.
They're linked here for the ActivityPub API task force, but they also apply for the federation protocol:
https://github.com/swicg/activitypub-api/issues/4#issuecomment-4083573914
Anyway, here's my thought: make collection pages real, stable objects, with fixed contents and real modification dates. Return only references, not embedded objects. Do filtering, though. And make pages big -- 100 items or more.
@evan mastodon’s approaches is interesting in this regard, it returns embedded objects for local items, and references for remote objects. Best of both
@django it's good in some ways, but they still don't return Last-Modified headers.
@hongminhee so, I guess this is true, but maybe also the craft changes?
I am old enough to remember when it was common to embed blocks of assembly language in your C code to optimize particular functions or loops. As high level languages grew, that familiarity with hardware architecture has mostly disappeared, but we've developed other skills instead.
When I read @jesse or @simon 's posts about exploring collaboration with LLMs, I see curiosity, creativity and joy in the craft.
@evan@cosocial.ca Totally agree, and I think that’s actually the point the essay is trying to make. The split isn’t “LLM users vs. craft lovers” but something more like “people with room to choose how they use the tools vs. people who don’t have that room.”
@mitchellh@hachyderm.io is a good example. He’s clearly using LLMs as a craftsperson. So am I, I think. But both of us are in situations where we’re not being measured against a colleague’s output every quarter. The workplace dynamic is what compresses all of that curiosity and exploration into pure throughput.
The craft probably does survive, just not evenly distributed.
@hongminhee Fantastic article. 👏 👏
I think there's one possible ray of light for the "code as craft" people - at least a subset of them. To me the craft'ers can enjoy coding for various reasons - the demo-scene folks, the "get it into the smallest amount of code" folks, the aesthetic folks.
But another camp is the "make it easy to understand and extend" folks - and that's pretty much where I fall. People like me, who like arranging things neatly, have had a great advantage for the last few decades, because tidy code is good for industry. There's a reason @mfowler 's Refactoring book is such a big seller.
What I'd argue we don't know for sure yet, is whether readable code as a valuable thing for the industry, is dead. The LLM extremists would probably say it is. But that only works if the only form of validation of code is going to be external (testing & observability, basically). I argue that if humans will still be required to "review" (whatever that ends up meaning) at least some code, then readable code is going to be advantageous.
Even if LLMs can produce readable code we still need human judgment, but for me judgment skills will come from doing, and not just reviewing. In other words, there'll still be an economic case for "developing by hand".
If I'm wrong, and external validation does become sufficient for judging code, then all bets are off. But in that situation I don't think the LLMs will end up writing code as we know it anyway - why would they? They will write whatever uses the least tokens and gets to a valid result most cheaply. Which could be in assembler.
@smallcircles @hongminhee @evan @steve browser.pub is incorrect here -- having a range of Object or Link doesn't mean that schema PropertyValue is not allowed. it means that the value is inferred to be an Object or a Link *in addition to* a PropertyValue. there is no problem as long as there are no conflicting statements being made.
cc @js