#fedify — Public Fediverse posts

Drafting a proposal to add API support in #Fedify for the ActivityPub Media Upload extension, the SocialCG-incubated #C2S companion that lets clients upload media via a dedicated endpoints.uploadMedia endpoint, separate from the outbox.

The sketched API mirrors the outbox listeners shipped in Fedify 2.2: setMediaUploader(path, callback) paired with .authorize(). Return a vocab.Object for 201 Created, or a URL for 202 Accepted.

This is still an early design draft. Feedback on the shape, semantics, and edge cases is very welcome:

https://github.com/fedify-dev/fedify/issues/754

#ActivityPub #Fedify #fediverse #fedidev

If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:

https://pr-731-0.fedify.pages.dev/tutorial/content-sharing

If you'd like to give feedback after reading it, please leave a comment on the following PR:

https://github.com/fedify-dev/fedify/pull/731

#Fedify #fedidev #ActivityPub #Nuxt #Pixelfed

If you'd like to preview the #tutorial I'm writing on building a small #threadiverse software with #Fedify, here it is:

https://pr-710.fedify.pages.dev/tutorial/threadiverse

If you'd like to give feedback after reading it, please leave a comment on the following PR:

https://github.com/fedify-dev/fedify/pull/710

Writing a #Fedify tutorial on creating #threadiverse software…

I wish #git, #forges could go #fediverse.
It would help so much. I would then not have to create bundles of accounts just to raise and issue or a pr. That would also help me explore and get a lot of things in one place, theoretically speaking.
#wishlist #freedomtech #fedify

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

Just had to add a workaround to #Fedify for http://joinmastodon.org/ns, a JSON-LD context URL that has never actually served a JSON-LD document. Mastodon has always inlined the term definitions, but some implementations put it as a bare URL in their @context, so Fedify's JSON-LD processor tries to fetch it and gets a 404 Not Found. Now Fedify ships a bundled copy of a context that never existed in the first place.

https://github.com/fedify-dev/fedify/pull/631

#fedidev #ActivityPub #JSONLD

If you see this post, please interact with it with a reply or like, I will then be able to retrieve your interaction to my blog/AP fedify instance and then I will test replying to your reply to demo threaded reply backfilled to my site
You can also comment using IndieAuth/indieweb if your site support it !

🔗 https://rmendes.net/notes/2026/03/15/fbb7d

I wish I could use IndiePass to connect to my Fedify/Indiekit ActivityPub server so to have a unified publishing/reading experience for both Indieweb and ActivityPub

right now I have this but only on the browser

🔗 https://rmendes.net/notes/2026/02/27/624ea

Started laying out a rough plan for implementing FEP-ef61: Portable Objects in #Fedify—server-independent #ActivityPub identities backed by #DIDs, multi-server replication, and client-side signing. It's going to be a long road (13 tasks across 5 phases, with a few open questions that need answering before we even begin), but I think it's worth doing right.

https://github.com/fedify-dev/fedify/issues/288#issuecomment-3971459585

#fedidev #fediverse #PortableObjects

I have deeply mixed feelings about #ActivityPub's adoption of JSON-LD, as someone who's spent way too long dealing with it while building #Fedify.

Part of me wishes it had never happened. A lot of developers jump into ActivityPub development without really understanding JSON-LD, and honestly, can you blame them? The result is a growing number of implementations producing technically invalid JSON-LD. It works, sort of, because everyone's just pattern-matching against what Mastodon does, but it's not correct. And even developers who do take the time to understand JSON-LD often end up hardcoding their documents anyway, because proper JSON-LD processor libraries simply don't exist for many languages. No safety net, no validation, just vibes and hoping you got the @context right. Naturally, mistakes creep in.

But then the other part of me thinks: well, we're stuck with JSON-LD now. There's no going back. So wouldn't it be nice if people actually used it properly? Process the documents, normalize them, do the compaction and expansion dance the way the spec intended. That's what Fedify does.

Here's the part that really gets to me, though. Because Fedify actually processes JSON-LD correctly, it's more likely to break when talking to implementations that produce malformed documents. From the end user's perspective, Fedify looks like the fragile one. “Why can't I follow this person?” Well, because their server is emitting garbage JSON-LD that happens to work with implementations that just treat it as a regular JSON blob. Every time I get one of these bug reports, I feel a certain injustice. Like being the only person in the group project who actually read the assignment.

To be fair, there are real practical reasons why most people don't bother with proper JSON-LD processing. Implementing a full processor is genuinely a lot of work. It leans on the entire Linked Data stack, which is bigger than most people expect going in. And the performance cost isn't trivial either. Fedify uses some tricks to keep things fast, and I'll be honest, that code isn't my proudest work.

Anyway, none of this is going anywhere. Just me grumbling into the void. If you're building an ActivityPub implementation, maybe consider using a JSON-LD processor if one's available for your language. And if you're not going to, at least test your output against implementations that do.

#JSONLD #fedidev

素晴らしい :clapping:

新しい分散/連合型SNS「Pulsate」を開発している - /dev/sdR2 https://laminne.hatenablog.jp/entry/2025/01/17/190000

#Fediverse #Hono #Fedify