The max_id, since_id, and min_id parameters in #Mastodon's Timeline API assume that the post ID is a sortable number. (Is this correct?) #Hollo, the #ActivityPub implementation I'm building, uses UUIDs for post IDs internally, so I'm stuck on how to implement a Mastodon-compatible API.
If you're a #fedidev working on an #ActivityPub/Mastodon-compatible server, don't forget that the WebFinger JRD media type is "application/jrd+json" and not "application/json". The early @feditest test results show this is a common mistake.
#Fedify, an #ActivityPub server framework, has released version 0.8.0! Here are the highlights of this version:
• fedify lookup: a command to look up any ActivityStreams objects (including actors); see also https://todon.eu/@hongminhee/112341925069749583
• fedify inbox: a command to spin up an ephemeral ActivityPub server so that you can debug and test the activities you send; see also https://todon.eu/@hongminhee/112354353470490915
• followers collection synchronization mechanism
• improved overall performance
• fixed several bugs
Upcoming live fireside chat about the Free and Open Source Software Sustainability Fund. Learn how to apply for FOSS grants to sustain your established open source project.
as I alluded to yesterday, I actually wrote something about the problem with #fediverse link embeds, how they potentially DDoS servers, and how we can (kinda) fix it.
#Fedify's tutorial, which previously assumed you were using #Deno, can now be followed using #Node.js and #Bun! (What is Fedify? It's an ActivityPub server framework.)
However, they are written for Fedify 0.8.0, which hasn't been released yet. You can test it with the pre-release version, 0.8.0-dev.164, though.
I really like these support tables on the FunFedi website. Seeing the support grid and example responses is very helpful.
I know a lot of devs are jumping from chat room to chat room, looking for someone to reply back in their timelines, etc. to get help when a specific platform isn't working quite right.
The amount of Mastodon forks that mostly just change the UI, and the amount of UI bullshit Gargron creates, increasingly make me think that what's needed is to separate UI and AP more.
Adopt an API (ideally: not the Mastodon API, realistically: probably the Mastodon API) that as many projects as possible agree on and build separate projects, for handling ActivityPub and for handling web UI.
A lot of users never see Mastodon's web UI anyway, they use mobile clients, many of them third-party clients. The next logical step is to decouple UI and core development entirely.
The fedify inbox command, which will be shipped in the next #Fedify release, is a tool that creates an ephemeral #ActivityPub server so that you can debug and test the activities you send.