Notices by Marcin Mikołajczak (mkljczk@pl.fediverse.pl), page 2

Na stronie Sejmu pojawił się tekst interpelacji posłanki @polamatysiak w sprawie obecności administracji publicznej w mediach społecznościowych, neutralności technologicznej oraz suwerenności cyfrowej, która powstała przy moim wsparciu merytorycznym.

Interpelacja porusza kwestie obecności profili jednostek administracji publicznej na komercyjnych platformach społecznościowych, takich jak Facebook, Twitter czy YouTube. Już na początku poprzedniej dekady zwracano uwagę na brak podstawy prawnej dla ich istnienia, a także na reklamowy wręcz charakter eksponowania linków do tych portali na rządowych portalach (oczywiście pisał o tym VaGla). Jednocześnie przy tworzeniu prawa uwzględnia się fakt istnienia tych profili, czego przykładem jest dotycząca podmiotów publicznych Ustawa o dostępności cyfrowej. Z rządowego serwisu możemy dowiedzieć się:

Artykuł 6. ustawy został stworzony z myślą przede wszystkim o publikowaniu treści na portalach społecznościowych, takich jak Twitter, Facebook, Instagram, LinkedIn, Youtube, Vimeo itp.

W związku z tym interpelacja zawiera pytanie o plany stworzenia ram prawnych regulujących funkcjonowanie tych profili. Może to być także punkt wyjścia do dalszych dyskusji, np. o nadużywaniu możliwości blokady przez administrację publiczną, sytuacjach, gdy profil intensywnie promowany przez instytucje państwowe zostaje „prywatyzowany” po zmianie władzy, czy wykorzystywania tych profili, a także możliwości płatnej promocji, do de facto kampanii politycznych.

Treść interpelacji zwraca uwagę na problem faworyzowania wybranych platform społecznościowych oraz publikowania przez administrację niektórych treści wyłącznie na nich. Jednocześnie proponuje rozwiązanie, które łączy wygodę dostępu do informacji w preferowanej przez obywateli formie z zasadą neutralności technologicznej. Taką jest możliwość uruchamiania przez instytucje publiczne serwerów rozwiązań wykorzystujących protokół ActivityPub. Jako przykłady takich wdrożeń wymienia Holandię, Niemcy, Francję i — nie mogło jej zabraknąć — gminę Stary Sącz.

Sytuacja, w której standard ActivityPub znajduje zastosowanie nie tylko w niezależnych projektach, lecz także w rozwiązaniach firm takich jak Meta (Threads), Automattic (WordPress.com) czy Flipboard, może zmienić postrzeganie korzystania z komercyjnych platform społecznościowych przez instytucje publiczne. Może sprawić, że poleganie na łasce (lub kruchym ego) ich właścicieli będzie postrzegane tak, jakby urząd państwowy podał jako oficjalny adres e-mail konto na Gmailu.

Mam nadzieję, że ta interpelacja oraz odpowiedź na nią przyczynią się do skierowania debaty o neutralności technologicznej i suwerenności cyfrowej w komunikacji między rządem a obywatelami na właściwe tory. Dziękuję Poli za zainteresowaniem tematu i uznanie mnie za właściwą osobę do podjęcia go :)

gdzie domyślnie wyłączone są uzależniające funkcjonalności, takie jak […] infinite scrolling

Mastodon wciąż ma domyślnie włączony infinite scrolling, bez możliwości wyłączenia. A szkoda, bo zaimplementowałam to u siebie i bardzo to lubię

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