MastoAPI Enhancement Proposals? I'd like to hear some opinions about the idea.
fedidev
Today @mkljczk introduced a proposal for MAEPs (Mastodon API Enhancement Proposals) which would be similar to the FEP process but for converging on API schema for servers that are not Mastodon but who are using the Mastodon client API
https://codeberg.org/fediverse-pl/maep/issues/1
#fedidev #fediverse #MAEPs
came across a thread by @LiquidParasyte about things they are coming across that need work or are broken on @Bonfire
https://indieweb.studio/post/01KJ0T79KGJRWHYTKWJJF4254R
#fedidev #bonfire
I've seen an ongoing debate between "Note" versus "Article" in ActivityPub / ActivityStreams.
When is something a "Note"‽
When is something an "Article"‽
Personally — I would probably have made the distinction this way.
An "Article" has a title.
A "Note" doesn't have a title.
(In ActivityPub / ActivityStreams, a 'title' seems to tend to get represented in the "name" field.)
Hi #fediverse and #ActivityPub developers!
I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.
Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!
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
When I first started working with #ActivityPub, before #Fedify existed, it felt like writing web apps in Perl and CGI in the late '90s. Interesting, even exciting—but never comfortable. That era where your business logic and your protocol plumbing were just… the same thing:
print "HTTP/1.1 200 OK"print "Content-Type: text/html"printprint "Hello, world!"
Decades of web development have given us layers of abstraction we now take for granted. Nobody hand-parses application/x-www-form-urlencoded query strings anymore. Nobody writes their own JSON codec, or manually constructs HTTP request/response messages. These things just aren't your problem when you're building an app.
ActivityPub development still feels like they are your problem. What do you do when the https://www.w3.org/ns/activitystreams#actor property comes in as a string instead of an array? What about when https://www.w3.org/ns/activitystreams#object is an embedded entity rather than a URI? How exactly do you implement HTTP Signatures? And wait—what's Linked Data Signatures, and do you need that too?
The real issue isn't that ActivityPub is complicated per se. It's that you can't get away with understanding it at a high level. You have to know it the way an implementor knows it—every edge case, every inconsistency in how different servers serialize JSON-LD, every signature scheme that exists in the wild. That's a lot to learn before you can even start thinking about your actual app. And when developers understandably cut corners on the protocol to focus on their product, it quietly becomes an interoperability problem for the whole ecosystem.
What I want ActivityPub development to feel like: you spend a day understanding the big picture, and then you just… build your app. That was the goal when I started Fedify, and honestly, we're not fully there yet. But it's where I want to get.