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
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.
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.
#Fedify is an #ActivityPub server framework in #TypeScript & #JavaScript. It aims to eliminate the complexity and redundant boilerplate code when building a federated server app, so that you can focus on your business logic and user experience.
The key features it provides currently are:
• Type-safe objects for Activity Vocabulary (including some vendor-specific extensions)
• #WebFinger client and server
• HTTP Signatures
• Middleware for handling webhooks
• #NodeInfo protocol
If you're curious, take a look at the Fedify website! There's comprehensive docs, a demo, a tutorial, example code, and more:
#Fedify, an #ActivityPub server framework, has released version 0.7.0! Here are the key changes in this version:
• Access control for actors, collections, and more via authorized fetch (i.e., secure mode)
• Generalized object dispatcher
• Logging with #LogTape for easier debugging
Hello fedi. i am trying to solve the "fetch all replies" problem once and for all that makes the fedi feel a lot more desolate and with a lot more reply guys in it than it should be. this is take two, where before i had it triggered by a button, but now i think it should happen on the server-side whenever you expand a post. can anyone help me out figure out how to make this more efficient by only fetching posts that the server doesn't already have? i am not sure what the best strategy would be, and if anyone with experience doing efficient rails and SQL stuff could give me some pointers that would be gr8. the patch is actually extremely simple it just needs a few nice things to make it not DDoS everyone.
I'm working on "Remote Likes" and "Remote Shares" that help you jump back to your own home server to post when you find something cool on another website.
Imagine those "Share on Facebook" buttons, without all the ick.
I know it needs some work (that's what FEPs are for, yea?) so please read, comment, and help me get this over the finish line.
My short yak shaving journey is over. Lacking a decent logging library, so I created #LogTape and started logging in #Fedify using it, which should make inbox/outbox debugging easier starting with Fedify 0.7.0. ✌️
Since #FediForum, the demo of Emissary has been wiggling around in my brain. This article from @deadsuperhero of @hello walks through the process of using the framework to create just about any federated object you can imagine. 😱
I love seeing these smaller activitypub creations popping up in various programming languages. Makes me think documentation on the basics is getting better, and with Evan's ActivityPub book coming out soon, even more so. Exciting, y'all!
Today I'm working on putting authorized fetch (aka secure mode) into #Fedify. The protocol implementation is complete, it's just a matter of polishing the API and docs. It appears that it will be finalized sometime tomorrow. Authorized fetch will be one of the major improvements in Fedify 0.7.0.
When an #ActivityPub server implements authorized fetch (aka secure mode), how does it associate the keyId in an HTTP request with the actual actor? I know major implementations (like Mastodon) use a fragment appended to the actor IRI as a keyId, but in theory a keyId could be any IRI that seems unrelated to the actor IRI, right? Should I maintain a table of actor–keyIds somewhere in the server?
Version 0.6.0 of #Fedify, an #ActivityPub server framework, has been released! Here are the major changes:
• The docs website has been migrated from Lume to VitePress, is more beautiful, and is finally searchable with ^K/⌘K!
• To improve interoperability with servers that have authorized fetch turned on, also known as secure mode, Fedify has changed to use the authenticated document loader by default in as many cases as possible.
• New @fedify/fedify/x/hono module to help integrate with the Hono web framework has been introduced.
• Added small fixes to help with debugging activity delivery.
Got a #report about a user saying things that were upsetting people, noticed it was from another instance, realized that I had access to the actual account that had sent it. Not sure what this is or why, didn't even realize #ActivityPub supported signed reports (I'd honestly like to get more), but obviously that's a risky thing if they didn't know it was happening and didn't know why.
I'm writing a section in the #Fedify docs on the pragmatic side of the Activity Vocabulary APIs, and I want to list how each API is used and how it is displayed in the major implementations.