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.

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

@nomadbynature i’m serious about allowing FSF-approved brainrot only. next i’ll get him to switch to a federated TikTok alternative

The instance object includes the list, like

Soapbox has this workaround as well, it was made before Mitra implemented /api/v1/apps.

Removed it https://codeberg.org/mkljczk/pl-fe/commit/e5728edb4ebbebcec8e6a599ec440e522ab59715

my favorite was Soapbox, but its developer quit Fediverse (there is now a fork called Mangane)

I don’t think Mangane would care about implementing Mitra-specific features. I tried to improve compatibility with Mitra in my fork of Soapbox (it needs a better name) but didn’t really test it