28 posts · Last used Jun 30
Today the W3C standards organization announced a new working group to advance the ActivityPub and Activity Streams standards. The Social Web Foundation, as a W3C member organization, will be participating in the group. The working group’s goal is to release a backwards-compatible iteration of each specification in Q3 of 2026.
Activity Streams was released in 2017, and ActivityPub was released in early 2018. Since that time, the experience of hundreds of implementers and millions of users has shown places that the specifications are confusing or unclear, or missing features. Some problems have been documented with errata, but others require more work. The Next Version tag in the ActivityPub GitHub issue repository gives some good examples of topics to be considered. The new Social Web Working Group will provide revisions of these documents to make them easier to use for implementers.
ActivityPub is an actively used protocol with millions of users and billions of notes, images, video and audio files published. Standards work on ActivityPub will necessarily be evolutionary, not revolutionary, and will incorporate backwards compatibility. Developers can confidently keep working on ActivityPub today without worrying about breaking changes in the future.
The Social Web Working Group will work closely with the Social Web Community Group, the organization that has been stewarding ActivityPub and its extensions since 2018. The Community Group will remain the focal point for innovative developments extending ActivityPub into different areas like geosocial applications or threaded forums, while the Working Group will concentrate on the core documents.
One Community Group document that will be moving into the Working Group is LOLA, the live data portability spec that originated in the CG’s Data Portability Task Force. LOLA lets users move from one ActivityPub server to another while retaining all their social connections, their content, and their reactions. It’s a great improvement for data portability on the social web.
The Social Web Working Group will consist of representatives of W3C member organizations and invited experts from the standards and development community. The group will be chaired by Darius Kazemi, longtime contributor to the ActivityPub developer community. Meetings and proceedings will be public, and developers can review the work happening in the ActivityPub GitHub repository.
Thanks to everyone who’s done the work getting this charter to completion; especially @dmitri@social.coop, the SocialCG chair who drove the charter editing and review process. Now, the work begins!
Ciekawa rozmowa rozwinęła się wokół tags.pub w wątku pod adresem: https://lgbtqia.space/@alice/116824281370893420
Niektórzy ludzie są bardzo zdenerwowani, że serwis tags.pub opiera się na domyślanej zgodzie, czyli trzeba się wypisać (opt-out), żeby nie wchodzić w interakcje z tym botem.
Przeycztałem zasady tag.pub (https://tags.pub/) i widzę potrzebę zaistnienia takiego serwisu (bo jest to częściowe rozwiązywanie problemu rozczłonkowania Fediwersum - czyli w praktyce zwykłego użytkownika: mało widać, co się faktycznie dzieje na Fedi). Ale z drugiej strony jest to dość inwazyjny serwis. No i niektórzy chcą lub potrzebuję lub muszą być ukryci w swojej kryjówce i... mają do tego prawo (bez bycia zmuszanym do ręcznego wypisywania się z serwisu, do którego się przecież nie zapisywali).
Twórca kontrargumentuje tak:
if you are being boosted by tags.pub bots, there are one of three reasons:
Unlike other relay services, tags.pub notifies you that you are being boosted, and gives you the option to opt-out.
Czyli rozumiem, że np. moja instancja dlatego jest objęta działaniem tags.pub, bo nasz administrator (@xaphanpl@101010.pl) ustawił drugą lub trzecią opcję z powyższych trzech. Nie rozumiem do końca, jak to działa, ale wygląda na to, że trudno pogodzić masowe automatyczne boostowanie hasztagów i oczekiwanie użytkowników Fedi, że nie będą zalewani niechcianymi działaniami botów.
🎶
