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. See the examples below to have an idea.

To extend an Activity properties you do:

public function onActivityPubValidateActivityStreamsTwoData(string $type_name, array &$validators): bool {
    if ($type_name === '{Type}') {
        $validators['attribute'] = myValidator::class;
    }
    return Event::next;
}

The Validator should be of the form:

class myValidator extends Plugin\ActivityPub\Util\ModelValidator
{
    /**
     * Validate Attribute's value
     *
     * @param mixed $value from JSON's attribute
     * @param mixed $container A {Type}
     * @return bool
     * @throws Exception
     */
    public function validate($value, $container): bool
    {
        // Validate that container is a {Type}
        Util::subclassOf($container, Type\Extended\Object\{Type}::class, true);

        return {Validation Result};

To act on received activities do:

public function onActivityPubNew{Type}(&$obj): bool {

To add information to Activities being federated by ActivityPub do:

public function ActivityPubAddActivityStreamsTwoData(string $type_name, &$type): bool {

To implement an ActivityStreams 2.0 representation do:

public function onActivityPubActivityStreamsTwoResponse(string $route, arrray $vars, ?TypeResponse &$response = null): bool {
        if ($route === '{Object route}') {
                $response = ModelResponse::handle($vars[{Object}]);
                return Event::stop;
        }
        return Event::next;
}

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.

>WIKI Milestone entry

GNU social v2 has tags and lists. It allows you to: - search for an #hashtag and see a stream of notes tagged with it; - make lists of actors and mention them with @#list_name - self tag and enter a list of people in your instance with the same self tag

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.

What's new with v3?

Federated self tags

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.

Tag Wrangling

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.

Related Tags

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.

Improved Tag feeds

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.

Mute Self Tags and Note Tags

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.

... All right, all right, it's not just it.

Here's what comes with it:

• Filter the streams with only the languages you know
• Federate the language for a more inclusive free network
• Make Tag Wrangling possible an transversal to languages

Here's how it looks:

What does this mean?

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.

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.

Understanding the organisation chosen

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.

Situation Report

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).

Next steps

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.

We hope you like it!

The prime directive

Modern looking, consistent and accessible UI across all browsers. Non-JS version as the primary focus, JS is optional and should be regarded as such.

The Web is 95% typography, the art and technique of arranging type to make text more readable and pleasing. To achieve this, a textual hierarchy is fundamental, text should present a clear, readable structure to the reader. In much of the same fashion, the way we perceive Web pages relies upon the same fundamentals. As such, by focusing on the markup, we hope to achieve an accessible, fast and polished structure by which any browser and screen reader relies upon.

Features

• Accessible
  • Easy to use keyboard only navigation
  • Feedback on focused elements
  • Keyboard shortcuts to access main regions
  • Vi-like shortcuts
  • Screen reader tested
  • Notifies the user when focusing on key elements, such as the feed, notes and actions
  • Brief description of navigation links
  • Using semantic HTML whenever possible
  • Special care given for styling solutions that could break accessibility
  • Colors and type sizes in accordance to W3C contrast guidelines
  • Chosen specifically blue-ish and grey-ish hues for faster page loading perception
• Fast, the content provided to the user really is just markup and some CSS rules
  • Optionally there will be some small use cases where JS makes sense (it's the only thing modern browsers understand e.e)
  • For example, cropping your avatar before uploading a new one.
  • This is the only example until now.
• Dark and light default themes available (according to your system theme)
• Graceful degradation for unsupported HTML elements
• Achieving modern user interface patterns without JS
• Various layout engines tested and work as they should
  • Qt WebEngine (Qutebrowser, Falkon, Otter Browser, etc...)
  • WebkitGTK (Epiphany, Midori, etc...)
  • Gecko (Firefox and derivatives)
  • Goanna (Palemoon, Basilisk, etc...)
  • Internet Explorer

Video

Keyboard tests

The git history is clear (we believe), but it can be challenging and obscure to outsiders and non-technical people.

With the introduction of this blog made with bashblog, we hope to make all the progress more visible and easier of following :)

It has a RSS feed so, don't forget to subscribe!

StoreRemoteMedia fetches remote files when they are Linked to in a note. I.e., when the major mime type isn't text. It triggers thumbnail generation.

Embed attempts to generate a page preview from open graph and oembed. I.e., acts when the major mime type is text.

We've changed so much with GNU social v3 that, regarding SRM there was no possible port, just a complete rewrite. Both plugins became smaller and easier to understand while promoting the same functionality with more stability.

It's always important to start with the original code as that allows us to review past decisions and understand all the corner cases previously considered.

Sadly, what motivated us to re-design the attachment system were the non-considered corner cases. In particular:

• Remove title from attachment, as it's part of the relation between attachment and note.
• Remove actor from attachment, many actors may publish the same attachment.
• Remove is_local from attachment, as it's part of the relation between attachment and note.
• Remove remote_url from attachment, different urls can return the same attachment.
• Attachment now has a reference counter
• Add entity GSActorToAttachment
• Add entity GSActorToRemoteURL
• Add entity RemoteURL
• Add entity RemoteURLToNote
• Add entity RemoteURLToAttachment
• AttachmentToNote now has a title attribute

Key commits:

• 32ad5dbd74 - [ENTITY] Split Attachment in various new entities
• c381e58d33 - [ENTITY] Refactor RemoteURL entities to Link

The structural changes and how it compares to v2 is detailed in our wiki.

Some relevant observations:

• Link is now part of GNU social Data Representation terms. It represents any remote URL being shared in a note.
• There's only one fixed directory for GSFiles.

Its controller handles upload, update and removal.

Important change from v2: Avatars are now regular attachments.

GNU social now has its documentation available in https://docs.gnusocial.rocks/. It features four different books. These are automatically generated from the source using mdBook.

Only the development book is in an elaborated state, the other books are holding for more ready code.

And two of them are new:

• The Developer is both intended to guide third-party plugin developers and to make it easier of contributing to the code.
• The Designer is the most recent of the four and came from a necessity of keeping some standardization between templates and ensuring the same principles are kept in mind when designing new themes.

And two of them are updates from existing documentation:

• The User one is adapted from the existing GNU social documentation for users that was provided in v2.
• The Administrator one is adapted from the "Unofficial GNU social docs" by Thomask who asked us to make it official.

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.