3 ms·

>but one of the first things I thought when trying to grok it was "how does this improve on RSS?". there's a lot of discussion that doesn't answer this questio

>but one of the first things I thought when trying to grok it was "how does this improve on RSS?". there's a lot of discussion that doesn't answer this question so let me do it quickly: a homeserver can POST updates to other homeservers that have followers on them, instead of relying those remote servers polling the one that originates the content. This is the main thing that ActivityPub brings over RSS, making it a different type of protocol entirely: updates can be pushed between servers

chriswarbo 3y ago
Storage can be decoupled from location/host using protocols like BitTorrent or IPFS. Many years ago I pushed my site to IPFS, including its RSS and ATOM feeds. That worked great for static content, but I never found a decent mechanism for pointing a URL to the latest version. I tried IPNS, and added a "DNS link", but it was super flaky. I'm currently pondering whether the GNU Name System would be better suited...
camgunz 3y ago
> there's a lot of discussion that doesn't answer this question so let me do it quickly: Yes, love it, OK > a homeserver can POST updates to other homeservers that have followers on them, instead of relying those remote servers polling the one that originates the content. This is definitely a difference but there are a couple of reasons I'm not sure I'd call it strictly an improvement. The first is that it feels like it would have been pretty easy to have ActivityPub allow everything to filter by a (created and/or updated) date. People don't like pull protocols, but hey guess what any Mastodon client (JavaScript or otherwise) is doing. Pulling isn't as bad as its reputation would suggest, plus we're great at serving/caching this stuff now. Like, one of the main benefits of HTTP is that it basically has encryption and caching built in. Pulling would have been fine for probably everything--and you can imagine designing the protocol to make it even more efficient than something like POSTing every new update to every federated server w/ a follower (batching would be a big win here). Second, the ActivityPub spec is pretty cagey on retries ("[federated servers] SHOULD additionally retry delivery to recipients if it fails due to network error"). Who knows if the existing servers implement some strategy, but the spec has no guidance AFAIK. Also, is a recipient server being down/erroring a network error? Also, nothing says POSTs have to be sent immediately. These aren't niche concerns; you can imagine a server being under heavy load or experiencing some network problems and reacting by limiting the number of update POSTs it sends. SMTP [0] on the other hand says you should wait 30 minutes and try over 4-5 days. We can quibble about the values or w/e, but a federated sync protocol should have more to say about sync than "POST updates, retry if it fails". Anyway, all of that is to say that I think ActivityPub probably would have been a lot simpler, faster, consistent (clients basically have to be pull because phones) and robust if server-to-server interactions were pull and not push. [0]: https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.4.1 https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.4....
- philsnow 3y ago
  > the ActivityPub spec is pretty cagey on retries ("[federated servers] SHOULD additionally retry delivery to recipients if it fails due to network error"). Who knows if the existing servers implement some strategy, but the spec has no guidance AFAIK. Also, is a recipient server being down/erroring a network error? Also, nothing says POSTs have to be sent immediately. I don't know much about ActivityPub; do you know whether updates from individual topics / subscriptions contain sequence numbers? If a recipient server receives updates 12, 13, and 14 on topic ABC, but then has a network blip and drops update number 15-17, and then successfully receives 18, it could know that it's missing some (and presumably poll for the dropped ones). Likewise, if a receiving server notices that it hasn't received any updates on one topic for a week when before it had been receiving multiple per day, it could proactively poll the sending server.
  - camgunz 3y ago
    Hmm, I see where you're going here but not that I can see. It looks like it's basically id + date. Spec FWIW: https://www.w3.org/TR/activitypub/ https://www.w3.org/TR/activitypub/

chriswarbo 3y ago

Storage can be decoupled from location/host using protocols like BitTorrent or IPFS. Many years ago I pushed my site to IPFS, including its RSS and ATOM feeds. That worked great for static content, but I never found a decent mechanism for pointing a URL to the latest version. I tried IPNS, and added a "DNS link", but it was super flaky. I'm currently pondering whether the GNU Name System would be better suited...

camgunz 3y ago

> there's a lot of discussion that doesn't answer this question so let me do it quickly: Yes, love it, OK > a homeserver can POST updates to other homeservers that have followers on them, instead of relying those remote servers polling the one that originates the content. This is definitely a difference but there are a couple of reasons I'm not sure I'd call it strictly an improvement. The first is that it feels like it would have been pretty easy to have ActivityPub allow everything to filter by a (created and/or updated) date. People don't like pull protocols, but hey guess what any Mastodon client (JavaScript or otherwise) is doing. Pulling isn't as bad as its reputation would suggest, plus we're great at serving/caching this stuff now. Like, one of the main benefits of HTTP is that it basically has encryption and caching built in. Pulling would have been fine for probably everything--and you can imagine designing the protocol to make it even more efficient than something like POSTing every new update to every federated server w/ a follower (batching would be a big win here). Second, the ActivityPub spec is pretty cagey on retries ("[federated servers] SHOULD additionally retry delivery to recipients if it fails due to network error"). Who knows if the existing servers implement some strategy, but the spec has no guidance AFAIK. Also, is a recipient server being down/erroring a network error? Also, nothing says POSTs have to be sent immediately. These aren't niche concerns; you can imagine a server being under heavy load or experiencing some network problems and reacting by limiting the number of update POSTs it sends. SMTP [0] on the other hand says you should wait 30 minutes and try over 4-5 days. We can quibble about the values or w/e, but a federated sync protocol should have more to say about sync than "POST updates, retry if it fails". Anyway, all of that is to say that I think ActivityPub probably would have been a lot simpler, faster, consistent (clients basically have to be pull because phones) and robust if server-to-server interactions were pull and not push. [0]: https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.4.1 https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.4....

philsnow 3y ago
> the ActivityPub spec is pretty cagey on retries ("[federated servers] SHOULD additionally retry delivery to recipients if it fails due to network error"). Who knows if the existing servers implement some strategy, but the spec has no guidance AFAIK. Also, is a recipient server being down/erroring a network error? Also, nothing says POSTs have to be sent immediately. I don't know much about ActivityPub; do you know whether updates from individual topics / subscriptions contain sequence numbers? If a recipient server receives updates 12, 13, and 14 on topic ABC, but then has a network blip and drops update number 15-17, and then successfully receives 18, it could know that it's missing some (and presumably poll for the dropped ones). Likewise, if a receiving server notices that it hasn't received any updates on one topic for a week when before it had been receiving multiple per day, it could proactively poll the sending server.
- camgunz 3y ago
  Hmm, I see where you're going here but not that I can see. It looks like it's basically id + date. Spec FWIW: https://www.w3.org/TR/activitypub/ https://www.w3.org/TR/activitypub/