Hi everyone, I’m going to share the concept and implementation of AcitivityPub at an annual open source conference (COSCUP 2023) in Taiwan. Among other things, I would like to introduce the history of AcitivityPub and its origins, so that the audience can understand that free social media is a long term effort.
I made the following simple timeline (it is still a draft).
In this diagram, the open source protocols are listed at the top, and the main applications are listed at the bottom. For the open source protocols, I use version 1.0 as the time stamp. For the application part, I have listed the approximate start time.
My understanding is that OStatus was the most well-known early free social media protocol, adopted by StatusNet and gradually replaced by the Pump API, which can be considered as the successor of OStatus. At the same time, at the source, OStatus, Activity Streams 1.0 and Pump API are all origins of ActivityPub.
In the application part, GNU-social and Pump.io are the successors of StatusNet, and Mastodon also used OStatus in the early days, but then completely switched to ActivityPub.
I would like to know everyone’s opinion on this discourse and timeline. Because there is not much information, my organization is likely to be problematic. I would also like to ask if there are any applications or protocols related to the origin of ActivityPub that I have missed in this historical overview.
Thank you very much for your reply. I agree with your statement. In fact, I originally wanted to present ActivityPub from a more internal perspective of community and value, to avoid it being misunderstood as just a technical protocol. But unfortunately, I couldn’t find much information. Many active activists mentioned just a few words, but it was too hard for me, a newbie, to sort out. I am reading your articles and trying to understand them.
In the meantime more people are welcome to contribute to this topic. I’m also trying to understand the socio-political implications behind the shift from OStatus, Activity Streams 1.0, ActivityPump to ActivityPub.
It has an interesting history of being an" accidental" openweb reboot, it exists because the #dotcons turned up at the #wc3 meeting and did not find anything useful for them so left the “weirdos” to get on with building a #4opens aproch. The “weirdos” manage to hold things together long enough to get the #activertypub standard through the open but burocratic process and pushed it out to the world.
Sadly the last few years we have fallen into the normal “libertarian cats” path, and it’s looking like this openweb reboot will be devoured… not a BAD outcome as they are eating a piece of openweb that will become a part of the needed shift in #mainstreaming.
But it’s not an outcome meany of us like, who wonted to building real alts.
The #mainstreaming needs composting rather than reforming
This is interesting because it provides insights into the dynamics and challenges of the openweb movement. It highlights the tension between #mainstreaming platforms and grassroots efforts, showcasing the passion and dedication of communities working towards an open and decentralized web. The accidental nature of the ActivityPub reboot adds an element of serendipity to the story, emphasizing the power of #DIY culture and the resource constraints faced by openweb technologies. The recent shift towards a “libertarian cats” path and the potential consumption of the openweb reboot raise important questions about the future of alternative platforms and the need for continued resistance against “common sense” #mainstreaming.
something that people implementing fediverse servers and clients frequently mention is that the de-facto activitypub standard is what has been implemented in the mastodon api. the precise differences don’t seem to be documented
OStatus had no support for privacy and limited conversations; although in the last years of OStatus Evan added support for DMs – but only if the recipients were on the same instance (like the early OStatus groups). They didn’t federate.
There were some later changes around 2011 to allow “targeted pubsubhubbub” but by then things had changed and OStatus was already on its way out. AS2 incorporated “targeted PuSH” natively via its addressing fields.
The shift from AS1 however was mostly because JSON is a lot easier to deal with as a serialisation format than XML and in 2011/2012 a large part of the technical world tossed XML and moved to JSON. ActivityPump used a very early draft of what is now AS2, combined with basically the C2S part of what is now ActivityPub. Servers exchanged messages via OAuth2 using an extension to generate OAuth2 tokens dynamically. Everybody exchanged messages via JSON over OAuth2.
ActivityPub basically added the S2S bits to ActivityPump so that existing communication servers could use ActivityPub without requiring OAuth2 - which was already turning into a compatibility nightmare and has only gotten worse since then. I believe this is also when the “public inbox” was added to address the fact that AS2 only had a concept of privacy and had no concept of something being ‘public’ or available to the public stream.
Signatures is/are where ActivityPub failed everybody. LD Signatures were always a disaster, and Eugen dug up an early draft of http-signatures which we’re still using even though it is now technically obsolete. LD signatures were retained purely for third-party signatures.
The Mastodon API has absolutely nothing to do with ActivityPub. It’s just a representation of Mastodon’s internal data models. My software doesn’t use it because we have radically different internal data models; even though we provide a very complete ActivityPub implementation. Instead we support ActivityPub C2S because it’s generic - it isn’t a vendor specific implementation like the Mastodon API is.
I concur with your sentiment on ActivityPub’s shortcomings concerning signatures. My original conception revolved around a “semantic inbox” inspired by FOAF principles. The aim was to implement a web-like email system where data could be posted via HTTP, and the user would have an inbox of items to manage.
This idea was incorporated into Solid (originally FOAF+SSL) and, due to various influences, was included as a linked data notification inbox. From the beginning, the intention was for the data sent to the inbox to be signed. However, it’s taken over two decades to design a universally accepted canonicalization and signing system for linked data, and the process is still ongoing.
In Solid, I had envisaged including signed payments as part of the social web, but this never materialized. Nevertheless, such signing has been successfully implemented in nostr.
LD Signatures branched off from the same group (WebID) but ultimately took a separate path.
Signatures can be intricately complex or remarkably simple, with a spectrum of variations in between. Emphasizing developer experience (devX), I believe that a straightforward “sig” field in a simple JSON blob, preferably with minimal or no nesting, is an effective approach.
I suggest considering the inclusion of open microblogging, which could be viewed as a precursor in this context. Although a decent project, open microblogging attained a substantial prominence in the open social web landscape, potentially due to effective lobbying efforts. There was initially a drive to rival Facebook and its application ecosystem, encompassing open social. However, these endeavors seemed to be relegated due to the strong promotion of open microblogging. To this day, the lack of a robust open social graph and a viable competitor to Facebook is still apparent.
It could be argued that OStatus may have inadvertently delayed our progress by around a decade. However, I believe it was the combined influence of Open Microblogging and an emphasis on micro blogging in general that have eclipsed other use cases in the open social web.
You might find it beneficial to explore linked data, FOAF, FOAF+SSL, the foaf-protocols mailing list, and Solid (social linked data). AS 1.0 evolved into AS 2.0, adopting linked data after AS 1.0’s moderate success. This change was driven largely by IBM, within the W3C social web working group.
FOAF (Friend of a Friend) gained traction around 2004 when the open social web began to flourish, and its creator eventually developed schema.org. The fundamental idea is the web as a social, interconnected graph of data. Enhancing the web slightly could allow for a browsable network of profiles. This could then anchor various applications, including inboxes/outboxes, profiles, followers, friends, activities, and more.
Regrettably, the OStatus and FOAF (linked data) branches became competitors rather than collaborators. This has resulted in two parallel, yet incompatible efforts. ActivityPub partially adopted linked data in a somewhat confusing manner, leading to considerable overhead with limited advantages. We are still attempting to navigate through these complications today.
One thing we don’t touch on is that most of this thried is inside the #geekproblem of #4closed thinking. This “common sense” is likely a part of the problem we should be talking about, but can’t.
We mix up open and closed, we mix up media with personal. We develop inside this mess and push noise over signal to not have to think about this.
Not blaming anyone, it’s just were we are.
Ideas to move tech Dev away from this mess please?
We have good #UX encrypted #FOSS chat, one on one and group. We have working #OMN (open media networks) in our ActivertyPub codebases and networks. We are in a relatively good place compared to ten years ago.
What we don’t currently have in this subject is an understanding of the different paths of media and private communication. They are different paths, yes the #mainstreaming has made a social mess by mixing these up, we don’t have to, and we should not.
Hope people can understand how this fits into the history of ActivertyPub, to give you a hint it’s CLEARLY on the #OMN path, this is a good path.
Yes, indeed. Sometimes closed masquerades as open. Sometimes centralized masquerades as decentralized. As the Fediverse grows in user base, it becomes increasingly appealing for proprietary interests to channel these users towards their gatekeeping structures, using specification changes, FEPs, or venture capital. Currently, we lack measures to resist this.
