6 ms·

Introduction to ActivityPub (2021)

155 points by srameshc 3y ago

Ciantic 3y ago
I presume this is here partly because Threads is in the news. To me interesting part will be what subset Threads will support? 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.
- shagie 3y ago
  https://www.w3.org/TR/activitystreams-vocabulary/#extendedtypes https://www.w3.org/TR/activitystreams-vocabulary/#extendedty... > 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.
- anileated 3y ago
  It seems logical if Threads focused on client-to-server interoperation first, since in theory that would allow more people to use third-party clients but not third-party servers so Meta gets a hold of all the unencrypted messages.
  - thejohnconway 3y ago
    I’m pretty sure they are going to do the opposite, support server-to-server, and never support client-to-server. They have been meeting with the maintainers of Mastodon and admins of large instances. Their stated goal is to allow migration off without losing your social graph (this is obviously a lie about motivation, but that’s not what I’m taking about here). This is all about server-to-server implementation. 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.
    - Lt_Riza_Hawkeye 3y ago
      Yes, plus if they support client-server then kill it later, they risk the same kind of backlash that happened to Twitter and Reddit when they killed third party clients. But if they only support server-server when they kill it, they can just send an email to all the geeks telling them "import your account into threads by X date!" and most "normal" users will never notice
      - thejohnconway 3y ago
        Supporting server-to-server ActivityPub is slightly risky for them as it gives people an alternative, and there will always be outward bleed. On the other hand I think it takes a lot of pressure off potential legal troubles around being a monopoly (which they must be worried about if they actually manage to kill Twitter). 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.
- unshavedyak 3y ago
  Is that client-server API robust enough to .. care? Why don't other (any other?) FOSS implementations support it? 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.
  - mariusor 3y ago
    There are other projects that support the client to server part of the specification (see my profile for an example in the FedBOX project, and from the more mainstream ones there's Pleroma AFAIR). Generally developers justify not adding it to their implementations with the fact that is not specified in sufficient detail. Personally I think it's mostly laziness and a lack of imagination - but I'm biased.
- RobotToaster 3y ago
  >Then there is stuff like outbox, which contains past messages, but for instance, Mastodon does not fetch old messages at all It's infuriating how little support activitypub outboxes have. It seems like the perfect way to make small instances work well.
  - mariusor 3y ago
    I think the justification Eugen (Mastodon's main developer) gave for not loading a user's past activities is that it would actually harm smaller instances when a user goes viral and the whole network hammers their servers for their content. 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.
    - worrycue 3y ago
      > I think the justification Eugen (Mastodon's main developer) gave for not loading a user's past activities is that it would actually harm smaller instances when a user goes viral and the whole network hammers their servers for their content. 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.
      - ComodoHacker 3y ago
        Maybe we don't need to value virality so much.
        mariusor 3y ago
        I doubt "valuing virality" is the real problem. But when you're exposed to a universal network whose numbers increase every day, there are moments when it happens no matter if you want it or not. The "slashdot effect" has been coined maybe 25 years ago, so it's obviously not a new thing. :P
- tedunangst 3y ago
  The client server protocol lacks support for many basic operations, like search. It's a late addition to the spec, because somebody felt a server protocol shouldn't be released without a client protocol. Swap the polarity of the inbox and outbox, and presto you've got a client protocol. Except clients don't want to talk to servers the same way servers talk to other servers.
- srameshc 3y ago
  I posted this not because of 'Thereads' but because I have been trying to implement ActivityPub and somehow I missed this document in my previous searches. I want to implement ActivityPub support for my blog in some form so like RSS, anyone subscribes can listen to it.
  - laurex 3y ago
    This will be helpful for you https://github.com/dariusk/rss-to-activitypub https://github.com/dariusk/rss-to-activitypub
deleted 3y ago
[deleted]
nologic01 3y ago
This reads more like a collection of links and resources rather than an introduction. 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.
- konart 3y ago
  >one that clarifies among others what is exactly the status quo Everyone do whatever they want to and try to support Mastodon custom `toot:` namespace which cannot be resolved and has to be hardcoded.
  - progval 3y ago
    Does it? Mastodon writes "toot":"http://joinmastodon.org/ns# http://joinmastodon.org/ns#" in its objects' "@context" as required by JSON-LD. What's wrong with it?
    - mariusor 3y ago
      The fact that it resolves to a 404 page?
    - konart 3y ago
      The thing is you should be able to send a request and get back the content of this context for dereferencing like so: curl -X GET -H "Accept:application/ld+json" https://www.w3.org/ns/activitystreams Mastodon does not provide this data, so this is a fake namespase https://github.com/mastodon/joinmastodon/issues/148#issuecomment-1114174935 https://github.com/mastodon/joinmastodon/issues/148#issuecom... https://github.com/go-fed/activity/issues/152 https://github.com/go-fed/activity/issues/152
idlewords 3y ago
[flagged]
matricaria 3y ago
I think it’s sad that Discourse is not federated as it broadly used in open source software. Maybe this will be added in the future? Or maybe the forums will move to Lemmy as it matures.
- mariusor 3y ago
  They did add support a short while back: https://github.com/discourse/discourse-activity-pub https://github.com/discourse/discourse-activity-pub.
mezobeli 3y ago
Try Nostr
miki123211 3y ago
AP is a really terrible protocol, but it'll probably dominate this space in the long-term because of the "worse is better" effect. 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.

155 points by srameshc 3y ago

I presume this is here partly because Threads is in the news. To me interesting part will be what subset Threads will support? 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.

shagie 3y ago
https://www.w3.org/TR/activitystreams-vocabulary/#extendedtypes https://www.w3.org/TR/activitystreams-vocabulary/#extendedty... > 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.
anileated 3y ago
It seems logical if Threads focused on client-to-server interoperation first, since in theory that would allow more people to use third-party clients but not third-party servers so Meta gets a hold of all the unencrypted messages.
- thejohnconway 3y ago
  I’m pretty sure they are going to do the opposite, support server-to-server, and never support client-to-server. They have been meeting with the maintainers of Mastodon and admins of large instances. Their stated goal is to allow migration off without losing your social graph (this is obviously a lie about motivation, but that’s not what I’m taking about here). This is all about server-to-server implementation. 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.
  - Lt_Riza_Hawkeye 3y ago
    Yes, plus if they support client-server then kill it later, they risk the same kind of backlash that happened to Twitter and Reddit when they killed third party clients. But if they only support server-server when they kill it, they can just send an email to all the geeks telling them "import your account into threads by X date!" and most "normal" users will never notice
    - thejohnconway 3y ago
      Supporting server-to-server ActivityPub is slightly risky for them as it gives people an alternative, and there will always be outward bleed. On the other hand I think it takes a lot of pressure off potential legal troubles around being a monopoly (which they must be worried about if they actually manage to kill Twitter). 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.
unshavedyak 3y ago
Is that client-server API robust enough to .. care? Why don't other (any other?) FOSS implementations support it? 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.
- mariusor 3y ago
  There are other projects that support the client to server part of the specification (see my profile for an example in the FedBOX project, and from the more mainstream ones there's Pleroma AFAIR). Generally developers justify not adding it to their implementations with the fact that is not specified in sufficient detail. Personally I think it's mostly laziness and a lack of imagination - but I'm biased.
RobotToaster 3y ago
>Then there is stuff like outbox, which contains past messages, but for instance, Mastodon does not fetch old messages at all It's infuriating how little support activitypub outboxes have. It seems like the perfect way to make small instances work well.
- mariusor 3y ago
  I think the justification Eugen (Mastodon's main developer) gave for not loading a user's past activities is that it would actually harm smaller instances when a user goes viral and the whole network hammers their servers for their content. 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.
  - worrycue 3y ago
    > I think the justification Eugen (Mastodon's main developer) gave for not loading a user's past activities is that it would actually harm smaller instances when a user goes viral and the whole network hammers their servers for their content. 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.
    - ComodoHacker 3y ago
      Maybe we don't need to value virality so much.
      - mariusor 3y ago
        I doubt "valuing virality" is the real problem. But when you're exposed to a universal network whose numbers increase every day, there are moments when it happens no matter if you want it or not. The "slashdot effect" has been coined maybe 25 years ago, so it's obviously not a new thing. :P
tedunangst 3y ago
The client server protocol lacks support for many basic operations, like search. It's a late addition to the spec, because somebody felt a server protocol shouldn't be released without a client protocol. Swap the polarity of the inbox and outbox, and presto you've got a client protocol. Except clients don't want to talk to servers the same way servers talk to other servers.
srameshc 3y ago
I posted this not because of 'Thereads' but because I have been trying to implement ActivityPub and somehow I missed this document in my previous searches. I want to implement ActivityPub support for my blog in some form so like RSS, anyone subscribes can listen to it.
- laurex 3y ago
  This will be helpful for you https://github.com/dariusk/rss-to-activitypub https://github.com/dariusk/rss-to-activitypub

deleted 3y ago

[deleted]

nologic01 3y ago

This reads more like a collection of links and resources rather than an introduction. 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.

konart 3y ago
>one that clarifies among others what is exactly the status quo Everyone do whatever they want to and try to support Mastodon custom `toot:` namespace which cannot be resolved and has to be hardcoded.
- progval 3y ago
  Does it? Mastodon writes "toot":"http://joinmastodon.org/ns# http://joinmastodon.org/ns#" in its objects' "@context" as required by JSON-LD. What's wrong with it?
  - mariusor 3y ago
    The fact that it resolves to a 404 page?
  - konart 3y ago
    The thing is you should be able to send a request and get back the content of this context for dereferencing like so: curl -X GET -H "Accept:application/ld+json" https://www.w3.org/ns/activitystreams Mastodon does not provide this data, so this is a fake namespase https://github.com/mastodon/joinmastodon/issues/148#issuecomment-1114174935 https://github.com/mastodon/joinmastodon/issues/148#issuecom... https://github.com/go-fed/activity/issues/152 https://github.com/go-fed/activity/issues/152

idlewords 3y ago

[flagged]

matricaria 3y ago

I think it’s sad that Discourse is not federated as it broadly used in open source software. Maybe this will be added in the future? Or maybe the forums will move to Lemmy as it matures.

mariusor 3y ago
They did add support a short while back: https://github.com/discourse/discourse-activity-pub https://github.com/discourse/discourse-activity-pub.

mezobeli 3y ago

Try Nostr

miki123211 3y ago

AP is a really terrible protocol, but it'll probably dominate this space in the long-term because of the "worse is better" effect. 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.