Most endpoints of Pinboard v1 API were implemented. We've left out some such as tag delete (as one can't really delete one in GNU social), among others that don't really fit. We have tested our implementation against Pinkt and we will soon be contacting the maintainer so the functionality of using a different API_TARGET is included with this app (as it was all we had to change to have this working).

Discussion regarding how bookmarks are better expressed in terms of ActivityStreams 2.0 is also developing in SocialHub.

We have started with FEP-8485 Unbound Actor, aiming at a ValueFlows based relationship between any kind of actors.

And this was discussed, re-thought, re-designed, and went through various iterations on SocialHub Thread Decentralised Group.

It wasn't until we had finished implementing the federation of Groups, polishing our Notification system, and defined how we wanted to represent all of this internally for GNU social v3, that we fresh started with all these ideas in mind and came with the simpler FEP-2100 Unbound Group and Organization.

Which instead builds on top of the already existing logic for Following. Of course, this FEP assumes how GNU social (and Lemmy, Friendrica, and Lotide) understands groups (and organisations). But we believe that, now that implementations are using these ideas and strategies, after a few more testing time, everything should become reasonably specified and formalized. Being this FEP already a step and contribution in that direction.

This FEP was implemented in GS via a plugin.

And it's because we love the project history and nature of being easily extensible and capable of communicating with the most diverse platforms that we insist on implementing robust and expressive specifications.

Want the notes mentioning you showing up on your toasts, then just code a quick script and GNU social will definitely not be the one holding you back. We can think of this old GNU social <-> Arduino bridge.

Webhooks is thus one more natural step on this direction.

This was achieved by strategically introducing the Blog Plugin.

Related discussion concerning compatibility with Friendica: Lemmy issue #2144.

Both GNU social and Lemmy have created test fixtures and the respective tests to ensure that this now existing compatibility isn't loss. More fixtures are in the plans.

Various improvements and changes in our Notification component derived from this development. GNU social and Lemmy have also agreed on expressing and understanding unlisted Likes in a manner analogous to how we handle Notes. But GNU social still has to implement support for that form of Like.

It is already possible to create organization actors,

and too have self tags on groups, which then aid on discoverability.

Accompanying it came the possibility of a plugin feature a shell script for setting pre-requirements that can be automatically executed by GNU social's installer.

There was also an upgrade of the core authentication stack that made it more simple and flexible.

Finally, the plugin was tested with AndStatus, related discussion available at: AndStatus #549.

GNU social now supports that initiative with the Web Monetization plugin.

With this, we also introduce an ActivityPub (FEP-8c3f) GS extension gs:webmonetizationWallet. This enables actors to support other actors with Web Monetization in the fediverse.

It looks like this:

Own profile

In the profile of other actors

We also take screenshots of all pages and compare them with the previous, allowing us to spot (possibly) unintended changes in the UI.

The way we do this is by using a docker image derived from node, with pa11y-ci installed, which doesn't have an entrypoint. This then allows us to spin up a webserver, PHP and Redis containers, mimiking a staging environment. pa11y-ci uses a JSON config file to tell it what to do, and handles visiting all pages with the given resolution, logging in and registering any accesibility violations found.

Note that most of these errors are actually the same.

The saved screenshots are then used to detect changes, with ImageMagik's compare, to generate a report on visual changes.

We were already striving for making GNU social accesible, which is clear from the really low number of violations found, but there's always room for improvement :)

This structure has the following implication:

Collection -> OrderedCollection
|-> Notes (known as Feed)
|-> Actors (known as Circle)
|-> Other Object (known as Collection of ...)
  |-> Attachments: AttachmentCollection
  |-> Tags: TagCollection

And it allow us to centralise the scope system in the core, ensuring that no actor will have access to notes or other objects that shouldn't be able to see.

Finally, with this, a plugin such as Note Type Feed Filter can be useful in every note collection (feed).

It also allows plugins such as ActivityPub to translate every collection automatically.

We also introduced the Circle component, which has a UI similar to the Attachments Collections, and enables circle mentions with @#circle_name.

Notes Filter and Sorting Options

Actors Filter and Sorting Options

The Search Component

Results

Note Options

Actor Options

ActivityPub Examples

We haven't implemented federation of Groups yet, but group tags and discussion on how unbounded groups can be federated via ActivityPub has already started.

Concerning federation of traditional groups, we will port our logic from v2 and translate following the same rules as AndStatus because they work, as yvolk beautifully stated :)

Finally, also note that the group actors now have "self-tags", as the other actors, which was a milestone.