Historical context (slide 2)

The fediverse, a portmanteau of "federation" and "universe", is part of the IndieWeb and consists on a decentralized social network that started with GNU social. Nowadays there are various pieces of software, other than GNU social, in the fediverse, like Pleroma and Mastodon, (all of which can be installed on your own server).

For a full contextualization (including technical aspects) and the differences between Fediverse, ActivityWeb and The Free Network, refer to this blog post I wrote: https://blog.diogo.site/what-is-the-fediverse/.

Fundamental Networks Topology (slide 3)

Centralised Network - Belongs to a single central power point (a host). Connected to all satellite nodes.

Decentralised Network - Belongs to many different hosts. Each with their own satellite nodes.

Distributed Network - Contains neither a host or satellite nodes. They just contain these self determining end point systems which connect with any node they want.

The IndieWeb (slide 4)

A people-focused alternative to the "corporate web".

  • When you post something on the web, it should belong to you, not a corporation;
  • Your articles and status messages can go to all services, not just one, allowing you to engage with everyone;
  • You can post anything you want, in any format you want, with no one monitoring you.

About GNU social (slide 5)

GNU social is a free social networking platform. It helps people in a community, company or group to exchange short status updates, do polls, announce events, or other social activities (and you can add more!). Users can choose which people to "follow" and

receive only their friends' or colleagues' status messages. It provides a similar service to proprietary social network sites, but is much more awesome.

With a little work, status messages can be sent to mobile phones, instant messenger programs (using XMPP), and specially-designed desktop clients that support the Twitter API.

GNU social supports an open standard called OStatus https://www.w3.org/community/ostatus/ that lets users in different networks follow each other. It enables a distributed social network spread all across the Web.

GNU social was originally developed as "StatusNet" by StatusNet, Inc. with Evan Prodromou as lead developer.

Actor Types (slide 6)

Actor types are Object types that are capable of performing activities.

  • Application - Describes a software application (Bots)
  • Group - Represents a formal or informal collective of Actors (some federation controversy)
  • Organization - Represents an organization
  • Person - Represents an individual person (User)
  • Service - Represents a service of any kind (Tools, used Protocol,...)

Actor model (slide 7)

Actors

An actor is the primitive unit of computation. It’s the thing that receives a message and do some kind of computation based on it.

The idea is very similar to what we have in object-oriented languages: An object receives a message (a method call) and does something depending on which message it receives (which method we are calling).

One ant is no ant

And one actor is no actor. They come in systems. In the actor model everything is an actor and they need to have addresses so one actor can send a message to another.

Actors have mailboxes

Messages are sent asynchronously to an actor, that needs to store them somewhere while it’s processing another message. The mailbox is the place where these messages are stored

Further resources on the Actor Model

What's the difference between URI and URLs (slide 8)

Not all URIs are URLs because a URI could be a name instead of a locator (that happens a lot on OStatus). In theory, a URL can be trusted to be an URI but, that's not always the case.

Common example: In GNU social a user has the right of changing its nickname, therefore,

https://loadaverage.org/up201705417 -> https://loadaverage.org/diogo (this happened)

On the other hand, my id is the same, so:

https://loadaverage.org/index.php/user/386167 -> https://loadaverage.org/index.php/user/386167

It's important to keep in mind that we can only trust an URL if this is claimed to be an URI.

Two members of the audience were called.

One of the members was declared as being Chuck Norris. The other as being Tux.

Known facts:

- I'm a follower of Chuck Norris and Chuck Norris follows me.
- Tux follows me.

Interactions:

- I publish a note with the content: "The seminar was a success!"
  > Tux and Norris received this note
- Norris replies with the content: "Congrats!"
  > I received this note
- I reply Norris' note with: "Thx dude!"
  > Norris and Tux received this note

Result: Tux is confused because he doesn't know why I sent a "Thx dude!" note

With Forwarding from Inbox, my server would have forwarded Norris' note to Tux,
as Norris note was addressed to my followers collection as well.

Decentralization in the fediverse context (slide 9)

When local actors (actors in the same node) participate in discussions with external actors (from other nodes) or simply subscribe to external actors' content, their node push that content to the relevant other nodes and eventually makes it available to all the connected actors. That selective node-based distribution creates, inside the global network, a more or less extended local aggregation that is called the fediverse.

Forwarding from Inbox (example from the spec)

Alyssa makes a post about her having successfully presented a paper at a conference and sends it to her followers collection, which includes her friend Ben.

Ben replies to Alyssa's message congratulating her and includes her followers collection on the recipients.

However, Ben has no access to see the members of Alyssa's followers collection, so his server does not forward his messages to their inbox.

Without the following mechanism, if Alyssa were then to reply to Ben, her followers would see Alyssa replying to Ben without having ever seen Ben interacting.

This would be very confusing!

Back to presentation

OStatus Overview (slides 10 to 12)

OStatus combines in a natural and efficient way a set of different pieces allowing decentralized communications in the web:

  • ActivityStreams encodes the notices, activities and social events (originally 1.0, therefore in Atom or RSS)
  • PubSubHubbub sends, in real time, these feeds to its subscribers around the web;
  • Salmon notifies its users about replies to their posts;
  • WebFinger makes it easy to find other users in the fediverse.

Introductory video about PubSubHubBub by Google (the authors): https://www.youtube.com/watch?v=B5kHx0rGkec

Activity Streams 2.0 (slide 13)

Little "a" activity streams : are a UI paradigm for displaying recent activity within a context. Activities are typically displayed in reverse chronological order and consist of relatively simple statements such as "John uploaded a new photo" or "12 people liked Sally's post".

Big "A" Activity Streams : is a data format for encoding and transferring activity/event metadata. The first version of the specification was published in 2011 by the independent Activity Streams Working Group and is based on extending Atom. The current (2.0+) version of the spec is JSON-based.

\pagebreak

Thoughts on JSON-ld

    JSON will always be second to XML in awesomeness anywayz...
    -- Mikael Nordfeldth

and

    My brain hurts when they try to do in json (JSON-LD) what has
    existed and worked in XML for ages.
    -- Mikael Nordfeldth

There was a small war and resistance on GNU social's side about the adoption of JSON. But they can play nice together. Our strategy was to keep XML for data definitions and to use JSON for data interchange.

If all those protocols allow the same why is ActivityPub being so widely adopted instead of the already existing ones?

It was essentially a matter of presentation.

ActivityPub does solve some technical problems of the already existing alternatives. But, despite its problems and trade-offs (because it isn't perfect either), "ActivityPub is to HTTP what HTTP was to TCP/IP" (in the words of Riley Taylor) whereas older protocols, like OStatus, were shared as a sophisticated (and overkill) solution to build a federated Twitter clone. This fact together with the simplicity claimed to be part of ActivityPub implementation lead to its large and fast adoption.

A Tour of ActivityStreams (slides 13 to 14)

Activity Vocabulary (slides 14 to 15)

The vocabulary is defined in two parts:

  • A Core set properties describing the generalized structure of an Actvity; and
  • An Extended set of properties that cover specific types of Activities and Artifacts common to many social Web application systems.

Core Types

  • Object - A simble, non-specific object
  • Link
  • Activity - Subtype of Object that describes some form of action
  • Instransitive Activity - Subtype of Activity representing intransitive actions
  • Collection - Subtype of Object that represents ordered or unordered sets of Object or Link instances
  • OrderedCollection - Subtype of Collection in which members of the logical collection are assumed to always be strictly ordered
  • CollectionPage - Used to represent distinct subsets of items from a Collection
  • OrderedCollectionPage - Used to represent ordered subsets of items from an OrderedCollection

Activity Types

  • Accept - Indicates that the actor accepts or acknowledges the object
  • Announce - Typically a note repost (indicates that the actor is calling the target's attention to the object)
  • Create - Indicates that the actor has created the object
  • Delete - Indicates that the actor has deleted the object
  • Follow - Indicates that the actor subscribed the object
  • Like - Indicates that the actor likes, recommends or endorses the object
  • Dislike - Indicates that the actor dislikes the object (DON'T CONFUSE WITH UNDO LIKE)
  • Note - Represents a short written work typically less than a single paragraph in length
  • Reject - Indicates that the actor is rejecting the object
  • ... this goes on and on ...

Using the Fediverse (slide 21)

There isn't a single culture

Of course, despite your best or worst efforts, you wouldn’t be able to do more than skew the culture of your part of the Fediverse: there’s no unified culture to the Fediverse, due to the distributed way in which instances network.

A lot of people come to the Fediverse because they’ve become untenably frustrated with their experience on legacy social media, like Twitter or Facebook.

Moving to the Fediverse is a really great solution to that frustration! Some platforms, like Friendica, are similar to Facebook. Others, like GNU social, are like Twitter.

So before you post, think about the problems you remember from the platforms you came from, and give some thought to if you might be recreating the culture that led to those problems here.

People have multiple interests

Some pieces of software like mastodon don't support groups, this lead to a huge number of mastodon instances that are interest-strict, there is a technology-only instance, music-only, etc.

We don't find this ideal as it limits the variety of posts in the user's feed. Furthermore, it leads the user to create different accounts in different instances, which defies the whole purpose of federation.

GNU social's solution for this issue was to implements groups. Groups are not that different of hashtags other than in concept and usage. You can subscribe to a !group but not to an #hashtag. Hashtags are idealized for momentaneous episodes while groups are more of a long-term thing.

Focus on Your Self

The culture that will have the strongest effect on your sense of identity is the one you build inside your head, and that’s determined mostly by what you’re exposed to.

Make the culture of the Fediverse something you want to be exposed to - follow people who will bring you to that goal, boost and write posts that fulfill that goal, and disregard the rest.

Implementing ActivityPub - Architecture (slide 22)

ActivityPub enables a decentralized social web, where a network of servers interact with each other on behalf of individual users/clients, very much like email operates at a macro level.

On an ActivityPub compliant server, individual user accounts have an inbox and an outbox that accept HTTP GET and POST requests via API endpoints. They usually live somewhere like https://example.social/users/diogo/inbox and https://example.social/users/diogo/outbox, but they can really be anywhere as long as they are at a valid URI.

Individual users are represented by an Actor object, which is just a JSON-LD file that gives information like username and where the inbox and outbox are located so you can talk to the Actor. Every message sent on behalf of an Actor has the link to the Actor’s JSON-LD file so anyone receiving the message can look up all the relevant information and start interacting with them.

Software Engineering concepts and ActivityPub are described with detail in the slides

Some further details are available in my implementation tech report: https://gnusocial.rocks/soc/2018/