@julian@activitypub.space When I asked @reiver@mastodon.social last time, he said he’d make sure FediCon 2026 doesn’t overlap with COSCUP 2026, but I’m not sure how it’ll turn out.
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!
@jaz@toot.wales Great, the CFP for the track is now open!
https://hackers.pub/@fedidevkr/2026/fediverse-social-web-track-at-coscup-2026-cfp
The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8–9) is now open! If you’re working on #ActivityPub, the #fediverse, or anything in the open social web space, we’d love to hear from you. The deadline is May 9. #COSCUP is free to attend.
👉 https://hackers.pub/@fedidevkr/2026/fediverse-social-web-track-at-coscup-2026-cfp
(Boosts appreciated!)
#SocialWeb #fedidev
@COSCUP@floss.social 2026（台北、8月8–9日）にて、Fediverse & Social Webトラックが採択されました！#フェディバース、#ActivityPub、オープンなソーシャルウェブをテーマに、丸一日・計6時間のトラックを予定しています。
発表者向けのCFPはまだ始まっていませんが、公開され次第お知らせします。お楽しみに！
#Fediverse #SocialWeb #COSCUP #ActivityPub #fedidev
@COSCUP@floss.social 2026(臺北, 8月 8–9日)에서 저희 Fediverse & Social Web 트랙이 承認되었습니다! #聯合宇宙, #ActivityPub, 오픈 소셜 웹을 主題로 하루 終日, 總 6時間을 進行할 豫定입니다.
發表者 募集 CFP는 아직 열리지 않았지만, 始作되는 대로 바로 公知하겠습니다. 期待해 주세요!
#페디버스 #연합우주 #SocialWeb #COSCUP #fedidev
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 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
@brettm@swarm.coiloptic.org Could I see the problematic JSON-LD document?
@julian@activitypub.space