diff --git a/v3/assets/a11y/report.png b/v3/assets/a11y/report.png
new file mode 100644
index 0000000..d73e634
Binary files /dev/null and b/v3/assets/a11y/report.png differ
diff --git a/v3/assets/a11y/violations.png b/v3/assets/a11y/violations.png
new file mode 100644
index 0000000..5480d12
Binary files /dev/null and b/v3/assets/a11y/violations.png differ
diff --git a/v3/feed.rss b/v3/feed.rss
index 99f8d00..b18c7e9 100644
--- a/v3/feed.rss
+++ b/v3/feed.rss
@@ -2,139 +2,177 @@
We use pa11y-ci
to run our accesibility testing on all GNU social
+pages. The process of setting this up was a bit of a ride, but the
+results are quite useful:
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 :)
+We also take screenshots of all pages and compare them with the +previous, allowing us to spot (possibly) unintended changes in the UI.
-Finally, also note that the group actors now have "self-tags", as the other actors, which was a milestone.
+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 :)
-]]>https://gnusocial.rocks/v3/updates-local-groups.html -With this feature, an actor has more ways to express itself to the community as a whole. This activity is federated using Mastodon's featured collection extension.
+The primary use of GNU social is to access the free network, be it ActivityWeb (ActivityPub) or Fediverse (OStatus).
+ +Contrary to the original plan, we have merged The Free Network Module, WebFinger and LRDD into a single component named FreeNetwork. Likewise, ActivityPub and ActivityStreams 2.0 was kept the same plugin instead of separated.
+ +The FreeNetwork component adds WebFinger (RFC7033) lookup and implements Link-based Resource Descriptor Discovery (LRDD) based on RFC6415, Web Host Metadata. It takes and produces both Extensible Resource Descriptor (XRD) and JSON (JavaSript Object Notation). Furthermore, and different from v2, every federation protocol will use the same distribution queue maintained by this component instead of holding its own.
+ +We originally intended to have data modelling plugins that would extend the GS's "language". We then understood that it added more complexity than we wanted without any considerable advantage because we cannot dissociate data reception handling of the protocol itself.
+ +ActivityPub already translates between activity and entity and allows plugins to extend it (thus serving a similar purpose to data modelling and representation plugins).
+ +GNU social v3 now supports mentions, which is a process that starts in the Posting component. The processing of local mentions naturally finds its entire handling here.
+ +For remote ActivityPub mentions, ActivityPub handles it aided by the FreeNetwork component).
+ +We still have to port OStatus (and ActivityStreams 1.0) and implement the distribution by FreeNetwork, although the base work is done. Regarding ActivityPub, although some of it already works, expanding the existing plugins to supplement ActivityPub, and full validation isn't ready yet. We will most likely finish the implementation of the whole federation stack in the next week.
+ + + + + + + + + + + + + + + + + + + + + + + + + -Source -
-]]>Actors are now able to set their own colours, through a brand new plugin: "Oomox". +Those accustomed to customising their own desktop should know where the name comes from ;)
- +The Oomox plugin main class catches the "PopulateProfileSettingsTabs" event upon visiting user panel.
--
+public function onPopulateProfileSettingsTabs(Request $request, array &$tabs): bool
+{
+ $tabs[] = [
+ 'title' => 'Light theme colours',
+ 'desc' => 'Change the theme colours.',
+ 'controller' => C\Oomox::oomoxSettingsLight($request),
+ ];
+
+ $tabs[] = [
+ 'title' => 'Dark theme colours',
+ 'desc' => 'Change the theme colours.',
+ 'controller' => C\Oomox::oomoxSettingsDark($request),
+ ];
+
+ return Event::next;
+}
+
+
+As made evident by the code, two new tabs are added to profile settings, light and dark theme colours. +Since the page styling follows the system theme, actors may want to style each theme differently, therefore they are treated separately.
+ +The actor's defined colours are then saved in the respective entity and cached. +Finally, the colour preferences are used to render the corresponding CSS file which defines the various colour variables used:
+ +public function oomoxCSS(): Response
+{
+ $user = Common::ensureLoggedIn();
+
+ $oomox_table = PluginOomox::getEntity($user);
+ if (is_null($oomox_table)) {
+ throw new ClientException(_m('No custom colours defined', 404));
+ }
+
+ $content = Formatting::twigRenderFile('/oomox/root_override.css.twig', ['oomox' => $oomox_table]);
+ return new Response($content, status: 200, headers: ['content-type' => 'text/css']);
+}
+
+
+Please note, upon rendering for the first time, page render may be blocked until the resulting file is served. Nonetheless, subsequent page renders +won't experience the issue again. That is, if the file is cached by the browser.
+ +Tabs added using the "PopulateProfileSettingsTabs" event: +
+ +Changing the dark theme colours! +
+ +The result of given changes, please note it's no longer a 'dark' theme. +Given a valid colour, it's the actor's responsibility whether or not the colours make sense. So, go wild! +
- -]]>-
- - - - - - - - -]]>GNU social now supports that initiative with the Web Monetization plugin.
- -With this, we also introduce an ActivityPub (FEP pending) GS extension
-gs:webmonetizationWallet
. This enables actors to support other actors with Web
-Monetization in the fediverse.
It looks like this:
- -This milestone could be just this, what's different from any other ActivityPub -plugin? How is it better than v2's?
- -It's better in how it's organised and extensible, check the EVENTS.md for examples.
- --- - -Due to the high density of technical aspects, we decided to keep this blog -post more on the light side and focus on explaining the new functionalities. -Check our Wiki Milestone entry for all the juicy details.
+Only the development book is in an elaborated state, the other books are +holding for more ready code.
GNU social v2 has tags and lists. It allows you to:
+And two of them are new:
#hashtag
and see a stream of notes tagged with it;@#list_name
It is limited with regards to federation of self tags and the @#list_name
can't
-target remote actors even when they are inside your list.
And two of them are updates from existing documentation:
+ +Together with the documentation we've introduced a +wiki. Its purpose is to walk-through decisions, +convention, terminology. It's where we document the reasoning the development team went +through before implementing more sophisticated functionalities.
+ +Finally, when the documentation doesn't explain, and to ensure the whole code +is properly tested, we have the +tests. And the coverage is available here. At the time of writing the coverage has 98.76% code lines tested.
+ + + -We now federate self tags and lists, so that constraint from v2 was moved out of -the way.
-In the future, the use of these tags can allow you to find people, -groups and even individual notes that have a tag you're interested in. We only -mean filtering, not magic recommendation algorithms.
-Proposed by @licho in Tue, 02 Jun 2019 17:52:07 GMT:
---I like the tag wrangling feature of AO3, which I think would help for cases of synonymous tags like #introduction and #introductions
-https://archiveofourown.org/wrangling_guidelines/11
-Is it feasible for !gnusocial ? Or would it cause problems?
-
The answer is yes and will be released with v3. With the addition of -Languages in notes and actors there was little excuse not to be feasible.
--
-Whenever you post a note containing tags, you can choose whether to
-make those tags canonical. This means that, for instance, the tags
-#run
and #running
become the 'same', meaning that when you click on
-the link for the #run
tag, you'll also see notes tagged #running. You
-can opt out of the behaviour by unchecking the "Make note tags
-canonical". An identical process occurs for people tags.
Internally, this transformation is accomplished by splitting the tag -into words and stemming each word.
-In a tag feed, you can see tags that are often used together with the -one you're seeing. This can be useful, for instance, for finding other -content you'd be interested in.
--
-When you click on a tag, be it a note tag or a person tag, you'll see -a feed of notes/people with that tag. You can also edit the feeds you -see in your left panel, so you can follow a given tag.
-- -
-If you don't like seeing a given tag in your feeds, for whatever -reason, you can choose to mute it. You can mute a note tag or a person -tag, in which case you wouldn't see any notes from people with that -tag.
@@ -402,8 +380,143 @@ tag. -]]>... All right, all right, it's not just it.
+ +First, the user panel section where the desired preferences are selected: +
+ +Upon sending the previous form, the user is redirected to order their selection: +
+ +Finally, when posting the language with the highest priority is selected by default.
+ +However, by accessing "Additional options", another language may be selected. The resulting
+note will have the html lang
attribute according to it.
The posting widget itself: +
+ +We can now show you the notes you can read, but for groups, this mean that you +can access umbrella groups and filter the feeds to see what's in your language +and even region.
+ +For too long the fediverse struggled with languages, this step makes it easier +for actual internationalization of the free network.
+ ++
+ + + + + + + +]]>+
+ + + + + + + + +]]>We use pa11y-ci
to run our accesibility testing on all GNU social
+pages. The process of setting this up was a bit of a ride, but the
+results are quite useful:
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 :)
+ + + +