ActivityPub is at an interesting place. Since its intial adoption by Mastodon in 2017, the standard has become all but ubiquitous across the Fediverse. In less than seven years, it has become the most-used protocol across the entire network.

According to FediDB, the ActivityPub side of the Fediverse is now used by nearly 10 million people, across more than 27,000 servers. FediDB also tracks 48 different platforms leveraging ActivityPub in some way. With Threads actively doing work their own implementation, these stats are likely to skyrocket, in more ways than one.

This kind of growth is a really positive sign for the network, as it suggests that widespread adoption of the Fediverse might actually be feasible. In order to get there, though, a number of developers have looked at ActivityPub and wondered: what could we do to make this better?

Table of Contents

• What does ActivityPub need?
  
  • ActivityPub’s Protocol
  • ActivityPub’s Ecosystem

  
  

• Ongoing Efforts
  
  • FediDevs
  • Fediverse Enhancement Proposals
  • Social Web Incubator Community Group (SocialCG)

  
  

• Towards ActivityPub 2.0

What does ActivityPub need?

While the Fediverse has seen an explosion of features involving chat, multimedia, live streaming, groups, events, and more, some people would say that the network suffers from a few glaring omissions.

In light of some of the developments taken on by Nostr and Bluesky, ActivityPub can feel downright limited in terms of what platforms in the Fediverse can do today:

• Bluesky makes server migration dead simple for users, leading to a process that feels seamless and non-intrusive.
• Bluesky offers a stackable moderation system that allows people to subscribe to labeling services and help each other curate and filter the network.
• Nostr benefits from a relay system that eschews the need for dedicated instances entirely, instead relying on keys for identity.
• While a little more on the cryptocurrency side of things, Nostr incorporates direct payments into the network, allowing creators to compensate each other.

This isn’t a proclamation that ActivityPub is inherently bad, so much as these other projects can offer advantages that most existing implementations lack.

There are a lot of big ideas on how to improve the situation, and it boils down to two problem areas:

1. The ActivityPub protocol specification
2. The ecosystem built around ActivityPub.

ActivityPub’s Protocol

The ActivityPub protocol is the heart and soul of most Fediverse platforms these days. As a specification, it stipulates methods and behaviors for implementations to follow. Unfortunately, critics have pointed to the fact that the spec can feel too flexible in defining some behaviors, but too loose in defining others.

“The spec is incomplete,” writes Ilja, a regular contributor to Akkoma, “if someone makes a followers-only post and someone replies, then the ‘Mastodon way’ is to address the reply to the followers of the account who replies. The proper way to handle this, is by addressing the followers collection of the OP, and let OP forward the Activity to its followers. But we don’t do that because we don’t know how to do forwarding.”

Another headache that exists for implementors right now comes from most ActivityPub platforms needing to rely on undefined behavior. The following pieces are heavily relied on, but don’t exist in the spec:

• Webfinger – Webfinger is a common tool and data format for looking up resources at an address. If you’ve ever copied and pasted a URL into search to pull in a remote post, Webfinger is what powers it!
• Privacy Scopes – in standard ActivityPub, servers make use of to and cc fields to determine which people a post gets sent to. These fields can address individual Actors, or a Collection of Actors. However, there isn’t really a specification on how scopes ought to work: Quiet Public, Followers-Only, Private Mention and Local-Only are all examples of privacy scopes that not only define a grouping of people, but also behavior for posts themselves.
• Account Migration – Mastodon kind of set the standard for moving accounts from one server to another: your old profile Authenticates your new one, and a relationship is established. After the primary account is set, the old account gets marked with a Tombstone object that redirects to the new profile.
• Moderation Tooling – federated reports, instance blocks, management of blocklists and permission levels, individual user moderation, etc. This is a rapidly evolving space that depends heavily on collaboration.

However, they’re absolutely required for a working platform to exist in the Fediverse. This leads to implementors to do a lot of extra work to figure out how things work today, and how to correctly use them.

ActivityPub’s Ecosystem

The ecosystem built around ActivityPub suffers from problems, too. Despite aspirations to provide a common protocol between very different kinds of platforms, the Fediverse still predominantly looks and works like Mastodon.

There are three reasons for this:

1. Lack of a Test Suite – ActivityPub was first adopted by Mastodon, which acted as rocket fuel for mass adoption of the standard. However, the lack of an independent testing suite for implementors left builders to instead test against Mastodon, making it a de facto standard.
2. Bespoke Client APIs – In addition to a server-to-server federation protocol, ActivityPub offers a secondary spec for client-server relationship. Mastodon ended up pushing it’s own API that was arguably easier to use, but just about every platform in the space could have instead been a client, instead of building their own stacks, APIs, and federation extensions.
3. Duplication of Effort – A very weird phenomenon in this space is that implementors don’t just build something once. As of this writing, there are approximately six different Group Actor implementations, all of which are built slightly differently, made by different people, and meant to solve different problems.

None of these things are necessarily earth-shattering problems per se, but we’ve ended up with an ecosystem where a lot of effort gets duplicated, people are implementing entire platforms from scratch, and everyone is also using Mastodon as a compatibility benchmark.

Ongoing Efforts

The important thing to remember is that this is far from a hopeless situation. As of this writing, there are some incredibly smart people trying to figure out how to fill in the gaps.

“The most important thing about ActivityPub is that it’s extensible,” says ActivityPub co-author Evan Prodromou, “that’s a strength; it means we can really quickly get new distributed social applications running on the network.”

These groups all intersect in a variety of ways, and each one of them is attempting to attack specific problem areas. They’re constantly comparing notes, holding deep discussions, and investigating what enhancements the whole Fediverse might benefit from.

FediDevs

The Fediverse Developer Network is a newer effort that aims to make development more approachable to implementors and newcomers alike. Their goal? Get people in a room together.

“How do we build this stuff to be compatible with other people’s projects, while also lifting the lowest common denominator for everybody?” says FediDevs founder Johannes Ernst, ” It probably starts with making it easier for developers to find each other and compare notes.”

According to Johannes, FediDevs incorporates three big ideas:

1. Developers in the Fediverse ought to have an easy way to find where everyone else is at, and catch up on what’s happening.
2. New developers need a resource library of best practices, emerging concepts, and documentation to prepare for connecting their apps to a global federated network.
3. There needs to be a place to publish guides and tools that make everyone’s lives easier.

FediDevs has already beared fruit through a project called FediTest, a test suite intended to provide different “test profiles” so that builders can see how their own work might interact with other platforms.

diode.zone/videos/embed/df0ac4…

Even though FediTest is still very young, the promise of such an effort is clear: people could stop relying on a specific platform for compatibility testing, and instead use a more flexible, agnostic solution that accounts how lots of different projects do things.

Fediverse Enhancement Proposals

The Fediverse Enhancement Proposals project is a comprehensive effort to distill some of the network’s best ideas into standardized documents that explain how they should work. The effort is an initiative of the SocialHub developer community, and serves as a testbed for their ideas.

FEP is very much in the spirit of XMPP Extension Protocols or Nostr Implementation Possibilities, suggesting ways that existing systems could be extended. Check out some of these ideas:

• FEP-1b12: Group federation – Specifies how a federated group or forum could work. Originally, this was proposed by Nutomic from the Lemmy project, and now Lemmy, Kbin, and Friendica all support this as a standard.
• FEP-5624: Per-object reply control policies – Some centralized platforms have a way to disable comments or replies on a status. What would it take to make this work in a federated model?
• FEP-5feb: Search indexing consent for actors – People on Mastodon can opt-in to being discovered by the Search function. How might we extend this to other Fediverse platforms?
• FEP-c390: Identity Proofs – How might a Fediverse Identity prove its authenticity, while also verifying associated links and accounts?
• FEP-ef61: Portable Objects – How might we separate user data from an instance, so that the user can move it if they need to migrate somewhere else?
• FEP-61cf: The OpenWebAuth Protocol – Derived from the Hubzilla Project’s technology. Wouldn’t it be great if you could use your Fediverse identity across the network? No matter what server URL you land on, permissions can be unlocked for you to perform basic interactions and see private content.

The repository contains a treasure trove of ideas, ranging from immediately obvious needs to larger, more abstract concepts about how the network could work one day. Many of these submissions are still in a DRAFT status for the moment, but a few of the FINAL entries are actively being used. The project is already helping the network develop further.

Social Web Incubator Community Group (SocialCG)

The SocialCG is an implementor’s group that focuses on best practices for those building on ActivityPub. A big focus for the group involves running case studies for different conventions are approached within the Fediverse. Here are a few ongoing studies:

• HTTP Signatures – An examination of how systems like Mastodon use cryptographic signatures as identity proofs on actors and their activities.
• ActivityPub-Webfinger – Studying the how and why so many ActivityPub systems rely on Webfinger to fetch remote data.
• Testing – A monumental collaboration between dozens of people, this is an ongoing study of existing ActivityPub Testing Suite tools, and insights on how exactly a standard test suite could be built.
• Data Portability – researching existing cases for moving data, activities, objects, and Actors across the network.

Towards ActivityPub 2.0

So, what does all of this add up to? Is it possible to bring all of this work into an updated version of the ActivityPub Protocol standard?

“I think there will be a working group chartered at the W3C to make backwards-compatible changes,” Evan Prodromou explains, “especially clarifying difficult text, and possibly recommending profiles for other standards…”

Despite the importance of the W3C and standardization, though, Evan also believes that there’s value to the fast-paced development of emerging projects with new ideas.

“…the innovation is always going to be at the edge, with new extensions.”

I, for one, agree with him. There’s some amazing developments happening in the space, and the future is looking bright.

The post The Efforts to Extend ActivityPub appeared first on We Distribute.

Even if you’ve been a part of the Fediverse for a long time, you’d be excused if you had never heard of Nomadic Identity. Within the confines of Mastodon, it’s a relatively unknown concept. But, for some of us, it’s something of a pipe dream: decentralized identity management with remote access control. On paper, that doesn’t sound too exciting, but it’s a huge concept. Even more exciting: the guy who designed it is bringing it to ActivityPub.

What the Heck is Nomadic Identity?

Nomadic Identity is a concept pioneered by Mike Macgirvin, a longtime builder in the Fediverse. If you’ve ever used Friendica, Hubzilla, or Streams, you’ve used software written by this guy.

wedistribute.org/2017/10/got-z…

Got Zot — Mike Macgirvin on building your own apps and protocols
An interview with the brilliant mind behind the Zot protocol, MagicAuth, and Nomadic Identity.

One of the big problems in federated social systems involves permissions, identity, and data. We can sum this up in three parts:

1. Permission Management – If I visit a friend’s site to interact with something, there typically isn’t a way for me to do anything while I’m over there. I have to go back to my server.
2. Identity Management – Okay, I have a way to validate that I’m really me. What do I have as a fallback if that fails?
3. Data Portability – What happens to my stuff if my server goes down? Can I move to another servers and get my statuses, messages, and interactions back? Could I even just do it temporarily, to keep my followers, while my server gets sorted out?

From the end user’s side of the house, everything boils down to how their identities are coupled to their instances. ActivityPub-based systems like Mastodon do a pretty decent job with letting people migrate from one server to another, letting users pull in remote statuses from a URL, and letting users decide who is allowed to see or reply to their posts. It’s a far better situation than what came before ActivityPub.

At the end of the day, though, what is currently provided in the ActivityPub side of the network is somewhat limited, compared to what the Zot protocol brings to the table with Nomadic Identity. Let’s dive into the three different components: OpenWebAuth, Channel Relays, and Data Migration.

OpenWebAuth

OpenWebAuth used to be called “Magic Auth”, because of how seamless the experience is. Instead of only being able to manage things from your social dashboard, you can jump from one part of the Fediverse to another, and your permissions will be granted automatically. It all happens in the browser.

The way this works is relatively simple: your browser accesses a token inside of a cookie. That token references your Digital Identity in the Fediverse, verifies it, and a handshake is performed. Afterwards, anything you were given permission to access unlocks and becomes visible on the page.

spectra.video/videos/embed/98b…
A really old video of Hubzilla doing it. I’m navigating from my site to Andrew’s.
OpenWebAuth solves one of the most frustrating UX problems the Fediverse currently has: dealing with remote content that you discovered somewhere else.

Channel Relays

Channel Relays are the second major piece of the puzzle here. Using a common ID, you can associate separate accounts across the network with one another. Each relay is verified through an Authorization process, and then each relay is tethered to one another like so:

Using your credentials, you can log into any one of these three relays, and post to your followers. If the server my work account is on suddenly goes down, I can still log in to my family account or blog, and keep interacting like nothing happened. I’m still in contact with my followers, and if I want, my relay accounts can replicate statuses posted from elsewhere.

A few clear benefits emerge from this:

• Network Resilience
• Censorship Resistance
• Ease of Migration

In fact, this mechanism is so good, it feeds directly into the next use-case: Data Migration.

Data Migration

So, we already have two pieces: multiple identities can be connected together across a network, logging into one can allow you to post from another, and a person can decide, at any time, which account will serve as their primary.

Because all of these things are set up, the act of moving your stuff becomes relatively trivial. All of your accounts are aware of each other. If you switch to a new primary, you can trigger an update to all of your existing conversation threads and comments to switch the author, and replicate the data on your end. Thanks to the way that Nomadic Identity is set up, those verified parts of your identity can perform those kinds of actions, whereas no other account can.

Why is This Important?

As we continue to think about how to further develop the Fediverse and give people more robust tools capable of doing more things, we have to consider the plumbing that holds it all together. Identity Management is one of those pieces of plumbing that’s surprisingly shaky, and requires serious consideration.

Digital Identities aren’t something unique to the fediverse and it’s not something Mastodon could stop if they wanted to. Nomadic identity is coming to the internet. The only question is who is going to own your identity. VISA/Mastercard, your government, Google, Microsoft, or you.
Mike Macgirvin

As Threads, Tumblr, and other big social networks come into the space, developers need to think about the stakes. The user migration flow is decent for moving from one server to another, but it’s relatively brittle, and currently only updates a reference from one account to another. The network lacks meaningful ways for people to pull their posts, messages, and media from the place they left.

The biggest takeaway here is that these are mature, time-tested mechanisms that could add extra layers of user agency and control to the Fediverse.

What’s Next?

Mike is already doing the work of figuring out how to retrofit these concepts onto ActivityPub. It’s likely that we’ll see additional Fediverse Enhancement Proposals to accommodate certain needs. For implementers, there are a few existing FEPs in the DRAFT stage that come recommended:

• FEP-ef61: Portable Objects
• FEP-521a: Representing actor’s public keys
• FEP-8b32: Object Integrity Proofs
• FEP-61cf: The OpenWebAuth Protocol

The post Oh, Zot! Nomadic Identity is Coming to ActivityPub appeared first on We Distribute.

It was bound to happen sooner or later. At least the person behind the reigns already makes great apps. That’s right: Daniel Supernault, creator of Pixelfed, is building a new social video app called Loops.

Introducing Loops, a fediverse TikTok platform.

Explore and share short videos on the fediverse using your Pixelfed or Mastodon account.

Available Soon.

loops.video/platform/fediverse…

Follow @loops for early access to the beta and updates.

#loops #pixelfed #pixelfedLoops

— pixelfed (@)2024-03-16T10:24:19.984Z

Not much is known about the app yet beyond what Dansup has said online. According to him, videos are only a maximum of 30 seconds in length, and that the Loops experience will be a separate app/platform from Pixelfed itself. Apparently, Loops is intended to recapture some of the experience of the beloved but short-lived Vine app. In Dansup’s own words, Loops is a revival of an older Pixelfed project, a dedicated UI for looping video.

The developer also stated an intention to assist and mentor the developer behind the similar Goldfish platform, which is intentionally designed to be more like Tiktok rather than Vine. Evidently, both apps are intended to be compatible with one another, as well as other video platforms in the Fediverse, such as PeerTube or Vidzy.

Honestly, I’m stoked about Loops, and can’t wait to beta test it. Maybe we could test it right alongside Dan’s other app, Sup?

The post Pixelfed introduces Loops, a Short-Form Video App appeared first on We Distribute.

Daniel Supernault

2024-03-16 08:23:09

Loops are for short duration videos (max 30 seconds) and is a separate app/platform from Pixelfed.

We're also working with @stux and his #Goldfish project so the fediverse will have many options to choose from.

Loops is more like Vine, simple and short, for longer videos we think Goldfish and/or PeerTube can meet your needs.

This is the amazing thing about the fediverse, instead of competing with Goldfish, I'm mentoring/helping them.

In the fediverse, we all win, no matter the platform.

🚀

The Bonfire project made a splash earlier this month by announcing the launch of the Open Science Network, an initiative to build a federated and open academic commons. Their blog post opens with a stirring call-to-action:

The scientific method must be liberated. In an era marked by misinformation, mass surveillance and political propaganda, corporate monopolies and platforms hinder scientific innovation and knowledge sharing.

Scientists, researchers, academics and their affiliated organisations must have control over the tools and medium they use to publish, review, share, study and discuss their work.
Bonfire Project

The platform itself is another one of Bonfire’s Flavors, with features specific to collaboration, publication, and public discussion. The Open Science flavor is currently a prototype, but it’s carefully being built with feedback from members of scientific research cooperatives.

The ultimate goal is to build something that suits the day-to-day needs of that specific community, while building novel features to make their lives earlier.

Features of Open Science

The Open Science Network site describes a handful of features that sets their effort apart from Bonfire Classic or even Mastodon. I could talk about the features and show off some slick screenshots, but I want to also talk about how these things can work together for a heightened user experience.

ORCID Integration

I think this is the first indication that the Bonfire devs really know their audience. ORCID is a single sign-on offering used by researchers and academics alike, and Open Science instantly allows people to use it.

ORCID is interesting, because it’s not just a login system, but an identity system that ties into a person’s published works. What this means is that it’s possible for Open Science to pull in published papers and research, sort them by publication, and share them to others in a digital space.

From there, it’s possible to discover other published works from people you follow, or pieces of research shared by people on the timeline. The Bonfire Project indicates that this could be a way for researchers to easily establish their professional work, while also having easy access to other sources of study.

Open Science also allows people to avoid a cluttered timeline filled with engagement bait, instead offering tools for people to subscribe to publications, research groups, and topics relevant to them. With this model, the whole space can open up for teams conducting research, to talk shop and share ideas.

Collaborative Peer Review

Another big aspect of research is the ability to exchange notes and ideas between peers in a community.

One area where this really shines in Open Science involves how research can be shared between peers. Researchers can either upload or import their work, which can be read through a built-in PDF reader. People can easily parse through the contents, and the document itself becomes a conversation thread for feedback and suggestions.

The Future Looks Bright

The release of Open Science by the Bonfire project is significant for several reasons. First and foremost, it is the first effort of its kind to attempt leveraging ActivityPub for academic use. It’s also a clear showcase of Bonfire’s modular architecture, composing a series of modules into a coherent distribution.

Most of all, it’s a validation of one of the project’s key pilot programs, where a system is built for a specific group of people, and tailored to their feedback. The idea that researchers and academics could directly benefit from this system, while also pushing Fediverse technology forward, is frankly awesome.

The post Bonfire Launches Open Science Network for Academics and Researchers appeared first on We Distribute.

The Fediverse’s favorite unconference, FediForum, is happening on March 18th and 19th. It’s a wonderful opportunity for community members, developers, designers, and builders to come together to share what they’ve been working on, and how to deal with various challenges in the space. Attendees are encouraged to break out into discussions, share their insights, and consider other perspectives.

Themes for FediForum March 2024

Judging from the list of proposed subjects, it’s easy to spot a few recurring themes:

• Trust & Safety – Tooling, Moderator Resources, Moderation and Governance, Regulatory Challenges
• Demos – NodeBB, Distributed.Press, PieFed, ActivityPods, Sora
• Standards – Interoperability, Protocol Extensions, Different flavors of ActivityPub like RDFpub
• Identity – DIDs, Ownership, Identity Re-use across services, identity attestation/verification

Live Coverage

We want to try to do something different for this FediForum: treat it like an Apple WWDC event. We’re going to attempt live coverage of the talks, demos, and events during the two-day unconference. The goal is to provide an insight into major developments happening across the Fediverse, with an emphasis on ideas and initiatives to help make the network better.

We’re currently experimenting with some tools to make it possible, but we think that there will be a lot of big presentations that need to be covered. Keep an eye on our site next week during the conference!

Tickets are Still Available!

You can still hop over to the FediForum site and order tickets to attend. The following pricing tiers are below:

• General Ticket – $40
• Almost Free Ticket – $199
• Contributor Ticket – $100
• Platform Employee Ticket – $250

If you have the funds to spare, we highly encourage going with the $100 Contributor Ticket. This helps offset the cost of $1.99 Almost Free Tickets for attendees that might not be able to attend otherwise.

Get Tickets

We can’t wait to see what everyone has to share next week! Join us if you’re able, and check in on We Distribute next week for live coverage of event discussions.

The post Don’t Forget: FediForum is Coming Soon! appeared first on We Distribute.