How Musk Made Vivaldi Build A Mastodon Server... In A Fortnight (Official Mastodon / Fediverse Development Thread)

bnew

Veteran
Joined
Nov 1, 2015
Messages
41,835
Reputation
7,092
Daps
129,891

ActivityPub support​

Summary​

The end goal of this proposal is to build interoperability features into GitLab so that it’s possible on one instance of GitLab to open a merge request to a project hosted on an other instance, merging all willing instances in a global network.

To achieve that, we propose to use ActivityPub, the w3c standard used by the Fediverse. This will allow us to build upon a robust and battle-tested protocol, and it will open GitLab to a wider community.

Before starting implementing cross-instance merge requests, we want to start with smaller steps, helping us to build up domain knowledge about ActivityPub and creating the underlying architecture that will support the more advanced features. For that reason, we propose to start with implementing social features, allowing people on the Fediverse to subscribe to activities on GitLab, for example to be notified on their social network of choice when their favorite project hosted on GitLab makes a new release. As a bonus, this is an opportunity to make GitLab more social and grow its audience.


Description of the related tech and terms​

Feel free to jump to Motivation if you already know what ActivityPub and the Fediverse are.

Among the push for decentralization of the web, several projects tried different protocols with different ideals behind their reasoning. Some examples:



One gained traction recently: ActivityPub, better known for the colloquial Fediverse built on top of it, through applications like Mastodon (which could be described as some sort of decentralized Facebook) or Lemmy (which could be described as some sort of decentralized Reddit).

ActivityPub has several advantages that makes it attractive to implementers and could explain its current success:


  • It’s built on top of HTTP. You don’t need to install new software or to tinker with TCP/UDP to implement ActivityPub, if you have a webserver or an application that provides an HTTP API (like a rails application), you already have everything you need.
  • It’s built on top of JSON. All communications are basically JSON objects, which web developers are already used to, which simplifies adoption.
  • It’s a W3C standard and already has multiple implementations. Being piloted by the W3C is a guarantee of stability and quality work. They have profusely demonstrated in the past through their work on HTML, CSS or other web standards that we can build on top of their work without the fear of it becoming deprecated or irrelevant after a few years.



The Fediverse​

The core idea behind Mastodon and Lemmy is called the Fediverse. Rather than full decentralization, those applications rely on federation, in the sense that there still are servers and clients. It’s not P2P like SSB, Dat and IPFS, but instead a galaxy of servers chatting with each other instead of having central servers controlled by a single entity.

The user signs up to one of those servers (called instances), and they can then interact with users either on this instance, or on other ones. From the perspective of the user, they access a global network, and not only their instance. They see the articles posted on other instances, they can comment on them, upvote them, etc.

What happens behind the scenes: their instance knows where the user they reply to is hosted. It contacts that other instance to let them know there is a message for them - somewhat similar to SMTP. Similarly, when a user subscribes to a feed, their instance informs the instance where the feed is hosted of this subscription. That target instance then posts back messages when new activities are created. This allows for a push model, rather than a constant poll model like RSS. Of course, what was just described is the happy path; there is moderation, validation and fault tolerance happening all the way.



ActivityPub​

Behind the Fediverse is the ActivityPub protocol. It’s a HTTP API attempting to be as general a social network implementation as possible, while giving options to be extendable.

The basic idea is that an actor sends and receives activities. Activities are structured JSON messages with well-defined properties, but are extensible to cover any need. An actor is defined by four endpoints, which are contacted with the application/ld+json; profile="https://www.w3.org/ns/activitystreams" HTTP Accept header:


  • GET /inbox: used by the actor to find new activities intended for them.
  • POST /inbox: used by instances to push new activities intended for the actor.
  • GET /outbox: used by anyone to read the activities created by the actor.
  • POST /outbox: used by the actor to publish new activities.


Among those, Mastodon and Lemmy only use POST /inbox and GET /outbox, which are the minimum needed to implement federation:


  • Instances push new activities for the actor on the inbox.
  • Reading the outbox allows reading the feed of an actor.


Additionally, Mastodon and Lemmy implement a GET / endpoint (with the mentioned Accept header). This endpoint responds with general information about the actor, like name and URL of the inbox and outbox. While not required by the standard, it makes discovery easier.

While a person is the main use case for an actor, an actor does not necessarily map to a person. Anything can be an actor: a topic, a subreddit, a group, an event. For GitLab, anything with activities (in the sense of what GitLab means by “activity”) can be an ActivityPub actor. This includes items like projects, groups, and releases. In those more abstract examples, an actor can be thought of as an actionable feed.

ActivityPub by itself does not cover everything that is needed to implement the Fediverse. Most notably, these are left for the implementers to figure out:


  • Finding a way to deal with spam. Spam is handled by authorizing or blocking (“defederating”) other instances.
  • Discovering new instances.
  • Performing network-wide searches.


Motivation​

Why would a social media protocol be useful for GitLab? People want a single, global GitLab network to interact between various projects, without having to register on each of their hosts.

Several very popular discussions around this have already happened:



The ideal workflow would be:

  1. Alice registers to her favorite GitLab instance, like gitlab.example.org.
  2. She looks for a project on a given topic, and sees Bob’s project, even though Bob is on gitlab.com.
  3. Alice selects Fork, and the gitlab.com/Bob/project.git is forked to gitlab.example.org/Alice/project.git.
  4. She makes her edits, and opens a merge request, which appears in Bob’s project on gitlab.com.
  5. Alice and Bob discuss the merge request, each one from their own GitLab instance.
  6. Bob can send additional commits, which are picked up by Alice’s instance.
  7. When Bob accepts the merge request, his instance picks up the code from Alice’s instance.


In this process, ActivityPub would help in:


  • Letting Bob know a fork happened.
  • Sending the merge request to Bob.
  • Enabling Alice and Bob to discuss the merge request.
  • Letting Alice know the code was merged.


It does not help in these cases, which need specific implementations:


  • Implementing a network-wide search.
  • Implementing cross-instance forks. (Not needed, thanks to Git.)


Why use ActivityPub here rather than implementing cross-instance merge requests in a custom way? Two reasons:

  1. Building on top of a standard helps reach beyond GitLab. While the workflow presented above only mentions GitLab, building on top of a W3C standard means other forges can follow GitLab there, and build a massive Fediverse of code sharing.
  2. An opportunity to make GitLab more social. To prepare the architecture for the workflow above, smaller steps can be taken, allowing people to subscribe to activity feeds from their Fediverse social network. Anything that has a RSS feed could become an ActivityPub feed. People on Mastodon could follow their favorite developer, project, or topic from GitLab and see the news in their feed on Mastodon, hopefully raising engagement with GitLab.



Goals​


  • allowing to share interesting events on ActivityPub based social media
  • allowing to open an issue and discuss it from one instance to an other
  • allowing to fork a project from one instance to an other
  • allowing to open a merge request, discuss it and merge it from one instance to an other
  • allowing to perform a network wide search?



Non-Goals​


  • federation of private resources
  • allowing to perform a network wide search?


Proposal​

The idea of this implementation path is not to take the fastest route to the feature with the most value added (cross-instance merge requests), but to go on with the smallest useful step at each iteration, making sure each step brings something immediately useful.

  1. Implement ActivityPub for social following. After this, the Fediverse can follow activities on GitLab instances.
    1. ActivityPub to subscribe to project releases.
    2. ActivityPub to subscribe to project creation in topics.
    3. ActivityPub to subscribe to project activities.
    4. ActivityPub to subscribe to group activities.
    5. ActivityPub to subscribe to user activities.

  2. Implement cross-instance forks to enable forking a project from an other instance.
  3. Implement ActivityPub for cross-instance discussions to enable discussing issues and merge requests from another instance:
    1. In issues.
    2. In merge requests.

  4. Implement ActivityPub to submit cross-instance merge requests to enable submitting merge requests to other instances.
  5. Implement cross-instance search to enable discovering projects on other instances.


It’s open to discussion if this last step should be included at all. Currently, in most Fediverse apps, when you want to display a resource from an instance that your instance does not know about (typically a user you want to follow), you paste the URL of the resource in the search box of your instance, and it fetches and displays the remote resource, now actionable from your instance. We plan to do that at first.

The question is : do we keep it at that? This UX has severe frictions, especially for users not used to Fediverse UX patterns (which is probably most GitLab users). On the other hand, distributed search is a subject complicated enough to deserve its own blueprint (although it’s not as complicated as it used to be, now that decentralization protocols and applications worked on it for a while).
 

bnew

Veteran
Joined
Nov 1, 2015
Messages
41,835
Reputation
7,092
Daps
129,891

Meta just showed off Threads’ fediverse integration for the very first time​


During the FediForum conference, Meta demonstrated what it might look like to toggle on fediverse sharing and post across multiple platforms.​

By Emma Roth, a news writer who covers the streaming wars, consumer tech, crypto, social media, and much more. Previously, she was a writer and editor at MUO.

Mar 19, 2024, 6:34 PM EDT
25 Comments

An image showing the Threads logo

Illustration: The Verge

Threads is coming to the fediverse — and we just got our first official look at how that might work from Meta itself. During the FediForum conference on Tuesday, Meta’s Peter Cottle showed off a brief demo of how users will eventually be able to connect their accounts and posts to the fediverse. The integration will let users share their posts across different platforms through Threads, letting them reach multiple audiences at once. Meta is just one of the many platforms aiming to join the fediverse, a group of decentralized social networks aiming to become interoperable with one another.

As you can see in the video below, which FediForum shared with The Verge, Cottle can navigate to his Threads account settings and toggle on an option called “fediverse sharing.” Meta will then show a pop-up explaining what exactly the fediverse is, along with some disclaimers Meta will flag to users so they know what they’re getting into.



First, Meta notes that users will need to have a public profile to toggle on the feature, something Instagram head Adam Mosseri has already mentioned. Users in the current alpha test also can’t view replies to their posts and can only see the likes they get. Cottle says Meta is working “super hard” on changing that.

Additionally, Meta warns that Threads can’t “guarantee” that a post gets deleted on other linked platforms if a user decides to delete it on Threads. In other words, your post may still be visible on, say, a linked Mastodon server, even if you decide to delete it with Threads.

“I think this is a downside of the protocol that we use today, but I think it’s important to let people know that if you post something and another server grabs a copy, we can’t necessarily enforce it,” Cottle says.

Once fediverse sharing is enabled, users will be able to post to other services that interoperate through ActivityPub. Cottle says Threads will “wait five minutes” before sending posts out into the fediverse, during which users have a chance to edit or delete their post. If a Threads user has fediverse sharing enabled, their profiles will display a “pill” icon that other users can click into to copy their fediverse usernames.

Cottle demonstrated the process of using Threads to post to the fediverse, and you can already see how his post federated out to Mastodon.

“I know there’s a ton of skepticism about Meta entering the fediverse — it’s completely understandable,” Cottle says. “I do want to kind of make a plea that I think everyone on the team has really good intentions. We really want to be a good member of the community and give people the ability to experience what the fediverse is.”

The FediForum is an online event that gives developers the opportunity to show off what they’re working on in the fediverse. “It’s good for them, and it’s good for the rest of us to see what they’re up to,” Johannes Ernst, one of FediForum’s co-founders, tells The Verge. “They’re being transparent about what they’re building and why.”

Threads started testing an ActivityPub integration last year, and Mosseri suggested last December that Threads’ plans for the fediverse could take “the better part of a year” to pan out. Earlier this month, Threads gave Evan Prodromou, one of the creators of the ActivityPub protocol, the ability to post on both Threads and Mastodon. Threads also plans on letting users follow non-Threads fediverse accounts and letting creators take their followers with them to another platform.
 
Top