Notices by marcin mikołajczak (mkljczk@pl.fediverse.pl)

I’d like to ask for some feedback on a project I’ve been working on for a while. It is a JS library for interacting with the Mastodon client API, focused on supporting additional features provided by alternative implementations of the API like Pleroma, GoToSocial and Mitra (eg. reactions, chats, bookmark folders). It attempts to abstract out the implementation details, so when two backends use different APIs to support the same feature, your code doesn’t need separate code to handle them.

The problem the library attempts to show is related to the way Fediverse backends other than Mastodon, which decide to adopt the most widely used client API (and forks of Mastodon) deal with extending it. We end up having at least three different ways to change your password, two APIs for emoji reactions, Akkoma implemented translations before Mastodon and has not yet adopted the more widely used API, for quote posts, depending on the backend the quote property might be stored in a pleroma object or directly in the status entity… I could go on and on listing. There are several different ways backends specify feature availability and you still have to fall back to parsing version strings sometimes. The newly introduced api_versions property in Mastodon instance object, which could help solving this problem, is effectively hostile towards alternative implementations and barely duplicates the information already stored in the version string (it’s literally a single integer incremented every time some change to the API is made). Making clients that support anything beyond the official Mastodon API might be complicated.

For pl-api, I’m maintaining a set of feature definitions (the concept and some code was inherited from Soapbox) which tells you, basing on all the available ways of feature detection, whether a feature is available. You can check if client.features.changePassword is true and then just call client.settings.changePassword that will call the appropriate endpoint. It currently includes feature definitions for 16 different software (this includes forks like Akkoma or Hometown) and falls back to a basic feature set for unknown software.

Also, pl-api uses Valibot to parse remote responses, which validates the data, provides fallbacks and guarantees type safety.

I’ve never made a library like this before, so I’d like to ask if it’s actually something that makes sense for others to use. I’m already using it in my own projects, most importantly pl-fe, a web Fediverse frontend I use daily. I would like to make a v1.0.0 release of the library soon. I hope this will help with adopting non-Mastodon features by other Fediverse clients.

It’s published in npm and the source code is available on GitHub and Codeberg.

inb4 I know it’s a terrible and meaningless name. I don’t care about branding. I prefer to work on code.

ok, i just implemented support for Bite activity for Pleroma basing on AP extension by @mia

it’s on my personal branch of Pleroma, but here you can get just the single commit (here’s one for Akkoma). it works with my personal front-end pl-fe and Luka by @prefetcher

no tests for now, i guess i’ll write them tomorrow

Are there any servers implementing MastoAPI planning to make use of /api/v2/instance#api_versions?

RT: https://pl.fediverse.pl/objects/4f167294-410d-4cc3-ba80-91e777d865fc

The instance object includes the list, like