@hongminhee awesome! Thanks for the detective work. I'll catch us right up.
@hongminhee so, the good news is that I can use the Fedify CLI to do an authorized fetch for an actor, and the debug output shows that RFC 9421 signatures worked. 🥳 The bad news is that the follow test still doesn't work. 🫤 I'll keep trying and see what I can do.
@rick I think the problem is with the signatures. @hongminhee gave me a bug report and I'm working on it right now. I'll let you know when I have it live and tested. Thanks for your persistence!
@steve @trwnh @hongminhee ha! That was the notice that got me to become a maintainer. But I don't have the admin rights to change it!
@jasnell can you give admin rights on the activitystrea.ms repo so I can change the message and also push automatically?
@evan James archived the repo today, assumably in response to this question. I'm going to keep working from my personal fork, and I'll use that to push to npm. I think I can update the info in package.json on the topic, too. A change that's been waiting too long.
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!
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
@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
@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.
So, an interesting issue came up in the #Fedify repo that I’ve been thinking about: #629.
You know how every #fediverse server uses schema:PropertyValue in actor attachment for profile metadata fields (like “Website”, “GitHub”, etc.)? Turns out, strict #AS2 validators like browser.pub reject it, because the AS2 spec says attachment should only contain Object or Link—and PropertyValue is a schema.org type, not an Activity Streams 2.0 type.
The thing is, we can’t just drop the type like we did with Endpoints (#576), because Mastodon and others rely on seeing "type": "PropertyValue" to render profile fields. But at the same time, it’s technically not spec-compliant.
I’m leaning towards writing a #FEP to formalize this existing practice rather than trying to invent a new type (like toot:PropertyValue extending Object), which would be a nightmare to migrate across the whole fediverse.
What do you all think? Has anyone else run into this? Would love to hear thoughts from implementers and spec folks.
#fedidev #ActivityPub #ActivityStreams #ActivityStreams2 #AS2 #PropertyValue
@hongminhee +1 for formalizing the existing practice in a FEP.
PropertyValue is covered in FEP-fb2a, but it proposes an alternative representation which implementers must support:
https://codeberg.org/fediverse/fep/src/branch/main/fep/fb2a/fep-fb2a.md
@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
@hongminhee It only includes the standard AP context. Do you have a workaround for that as well?