Introduction to ActivityPub (2021)
socialhub.activitypub.rocks
socialhub.activitypub.rocks
For instance, ActivityPub specs start like this:
"It provides a client-to-server API for creating, updating and deleting content, as well as a federated server-to-server API for delivering notifications and content."
However, that client-to-server API is not even implemented by Mastodon. It's unlikely Threads will support it either, leaving those who want to make own clients in the cold.
Then there is stuff like outbox, which contains past messages, but for instance, Mastodon does not fetch old messages at all, causing a subpar experience: "Older posts from other servers are not displayed" when browsing profiles.
If Threads don't see the need to support outbox either, it makes browsing Threads content from your own small server an infuriating experience.
> Support for specific extended vocabulary types is expected to vary, with implementations only selecting the extended types and properties that make sense within the specific context and requirements of those applications. However, to avoid possible interoperability issues, implementations must avoid using extension types or properties that unduly overlap with or duplicate the extended vocabulary defined here.
So, they are going to be part of the server-to-server Fediverse, and keep all of the juicy app data from Threads users to themselves.
I predict if they manage to be the overwhelmingly dominant platform in the Fediverse, they’ll keep it working. If they see another big competitor jumping in and taking a lot of users (or hell, if Mastodon starts to eat their lunch), I’m not so sure.
I'm toying around with my own and that's interesting. I'd love to support it but if no one else supports it no clients will support it either. Granted eventually i expect i'd want some client-server API so i may as well use ActivityPubs. Nonetheless the lack of adoption feels odd.
It's infuriating how little support activitypub outboxes have. It seems like the perfect way to make small instances work well.
I am not convinced of the reasoning, and, in my opinion it's actually working against the idea of "federation", and even against the whole paradigm the internet is built upon: as a UserAgent you should retrieve content when the user requests it.
Maybe we need some kind of protocol that can spread the load where popular messages are duplicated across the network instead of being stuck on one node that can get overwhelmed.
The irony and tragedy of the Internet is BitTorrent solved Internet Scale at the protocol level, but is at odds with how content companies, ISPs, and Silicon Valley want to organize themselves.
If you cram every social interaction a network has in a massive common distributed store (which is what using a bittorrent like protocol would entail) you have every node requiring to consume gigabytes over gigabytes of content, despite being interested in a fraction of a fraction of it.
I don't know if nostr or scuttlebutt resolve this issue, but if they don't ... how do you imagine a mobile app for keeping in touch with your grandma, requiring gigabytes of data transfer and storage would work?
At this point people saying bittorrent is a solution for social networks are basically just the guys who know about hammers and seeing nothing but nails.
I say irony because we had all these scaling problems two decades ago during the peak P2P years, including federation and implicit DDoSing, and BitTorrent emerged as the lasting protocol because it could handle the scaling issues.
I say tragedy because for this to work you do need some openness, which puts people at risk of content companies trolling for you, ISPs dropping you, and is completely antithetical to the control Silicon Valley demands over its users and data.
There were some plans at one point for another project which would deal with music and would host the media on IPFS. Sadly I've never seen any progress on it, despite the idea sounding very good.
That way, you solve for the potential hosting issues of smaller hosts not being able to handle the load in case of viral posts etc, all without the clients having to know anything about the implementation details.
We've run back than Napster and later eDonkey on those boxes just fine…
You mean like any proper P2P protocol?
Add to this multi-cast on internet level, and everybody could actually operate something like YouTube on their internet router…
But of course economic interests of some (already ultra rich) minority will prevent that forever, even we could have it just right now form the technical standpoint.
I created an ActivityPub service which (coincidentally) uses a similar storage idea as HN - raw files on disk - and it runs orders of magnitude faster than a similar sized Mastodon server would. Sadly it's not as fast as HN, but I'm getting it there. :D
There should two proper introductions, one non-technical (but not patronising one) that would explain in clear terms and maybe a few diagrams and mockups what type of experience is supported. Also a more technical one that clarifies among others what is exactly the status quo of the various implementations of the protocol.
Being decentralized and a collection of disparate, opinionated and shoestring budget efforts means that there is a penalty in terms of good exposition and documentation.
For better or worse the grace period is over for the fediverse. The stakes have been raised.
Everyone do whatever they want to and try to support Mastodon custom `toot:` namespace which cannot be resolved and has to be hardcoded.
curl -X GET -H "Accept:application/ld+json" https://www.w3.org/ns/activitystreams
https://github.com/mastodon/joinmastodon/issues/148#issuecom...
Some of the namespaces used by the JSON-LD spec itself (https://www.w3.org/TR/json-ld11/#conformance) don't resolve either. For example:
$ curl -X GET -H "Accept:application/ld+json" https://www.w3.org/ns/prov -L
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>406 Not Acceptable</title>
Examples at https://docs.joinmastodon.org/spec/activitypub/#featured and this new information give better understanding of the spec. (I find it quite confusing anyway to be honest).
Or maybe the forums will move to Lemmy as it matures.
The AP specification is a joke. It's a typical W3C mess of documents referencing documents referencing documents that reference yet other documents, and you have no idea which of those you have to read, and in what order. For example, ActivityPub requires you to understand ActivityStreams and often mentions JSON LD, but you don't really need to understand much about JSON LD to understand the AP spec. Even worse still, some parts of the spec sound just as authoritative as everything else while being completely useless. For example, the client-to-server part isn't actually implemented by any of the major implementations, and if what you want to do is write a Mastodon-compatible client, you need to look at a completely different, unspecified API, which the major implementations implement in similar but slightly different ways, often violating the assumptions that some clients made. Yet other parts of the protocol are underspecified; to understand how signatures are handled, for example, you basically need to read the source code of one of the implementations. Things are so bad that people had to write ActivityPub specification reading guides[1].
Leaving the specification aside, the protocol as implemented has a bunch of other issues. If you want to make your website ActivityPub enabled, to publish news like you would on an RSS feed for example, you can't just chuck a JSON file on a CDN and call it a day, you actually need to keep track of a list of subscribers and proactively push out updates to interested servers, which is complicated from an infrastructure standpoint, has GDPR implications, doesn't play well with existing CDN / caching infrastructure and headless CMS solutions, and is an overall pain in the ass to implement. The protocol still doesn't have a satisfactory migration solution, migrating between Mastodon instances is a difficult process with lots of steps, and you can only migrate (most of) your followers, but not your post history. If your instance shuts down for any reason or your admin decides to ban you, you lose everything and you can't migrate any more. Your instance admins can decide not only what content you're allowed to post, but also what content from other instances you're allowed to see. Most admins abuse that power liberally, making it impossible to follow people from any instance that isn't leftist enough, and those that don't are often shunned, cut out themselves or forced into submission. The community is very cult-like, has a "you're either completely with us or against us" mentality, and if you're against us, we will do everything in our power to shun you and make your content invisible to the rest of the fediverse.
If your admin decides to suspend an instance, your follower/following relationships with that instance are gone forever. Neither migrating away nor your admin deciding to un-suspend the instance will fix that. If you could find a vulnerability that allowed you to control a majority of fediverse instances, and such a vulnerability existed[2], you could basically destroy the network with a bunch of well-placed defederation requests, and no restoring from backups would ever fix that.