@noracodes the most important thing to understand regarding push/pull on the fediverse is that we don't have GREAT auth mechanisms across servers, which makes it hard to ensure that the people pulling are actually the people who should have access to the posts. this basically means pull-only solutions would only work with public content and not anything with a limited audience.
ignoring theory and just focusing on what is practically featured in mastodon today, pull isn't implemented at all, you have to do push
edits should produce pushes of an edit activity though; remember activitypub federares activities, not posts, and an activity can be whatever you want it to be
@Lady
> we don't have GREAT auth mechanisms across servers, which makes it hard to ensure that the people pulling are actually the people who should have access to the posts
That is patently untrue. The most common auth mechanism between servers on the fediverse, HTTP signatures, allows the user that pulls to be authenticated against a server specifically, based on their public key IRI.
@mariusor @noracodes HTTP signatures do allow for signed pulls, but there is no standardized mechanism for specifying which user is making the pull (which isn't a problem for pushes; it’s in the payload). without knowing which user is making the request, it's impossible to know how to respond correctly (and obviously you don't want user A to be able to sign a request by user B).
mastodon could probably hack a de-facto solution to get around this (maybe it already does; it's been a while since i looked at the HTTP signatures code) but it wouldn't be standardized; the bigger issue though is definitely the fact that there is no real motivation to do so. it's one thing to go through all the posts a user has made and filter them by “does X have access?” but an outbox should properly also include favourites and other kinds of actions the user has made, which sounds expensive to me :P .
footnote: HTTP signatures is not a GREAT auth mechanism regardless, on account of the fact it is currently undergoing IETF standardization and the current HTTPbis draft is very different from the one mastodon implements. that's not really an argument for or against them for this use-case, but it is annoying.
@mariusor @noracodes there is a lot more handshaking which needs to happen with pulls also because replay attacks are much more dangerous. if someone replays a push then the server just gets notified of a status twice. but if someone replays a GET then they could have access to all the content that other user saw.
@Lady
I have a couple of comments:
Mastodon is not the fediverse, I would urge any developer that wants to build things on the fediverse to add compatibility with it only _after_ working as a compliant Activitypub implementation.
GET requests (pulls) can support HTTP signatures just fine, and if the signature contains the request Date header, they can mitigate replay attacks. (at least I can't think of a way to circumvent it)
PS. My project[1] uses the Authorization header of a GET request to identify if the a specified Actor has permissions to view items in the Outbox/Inbox they're trying to load. By default it only displays items that have the Public namespace in their addressing.
@mariusor @noracodes it's possible to mitigate this in current (HTTPbis) HTTP signatures, and maybe in the draft mastodon implements too, but to my knowledge mastodon currently does not have the logic needed to defend against somebody replaying somebody else's properly-signed request or similar related issues