Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Most use cases of ActivityPub would be better off as Atom or RSS feeds

beesbuzz.biz

Post reply on HN
Print view View original

11–20 of 50 posts

Re: Most use cases of ActivityPub would be better off as Atom or RSS feeds

#11

Post by vorpalhex »

This reads pretty distinctly like "Get off my lawn you damned kids with your attempts at decentralization!". ActivityPub is a pretty new protocol and what it looks like in the wild is still evolving - but it's clear it's filling different voids then RSS.

Sure, you could probably force most of these cases with some hacked up RSS implementation, and I can also use a longsword to mow my lawn. I'm personally very excited to see what ActivityPub brings with it and projects like PeerTube show that it's an extremely capable protocol even if we're still learning how to best use it and implement it.

Re: Most use cases of ActivityPub would be better off as Atom or RSS feeds

#12

Post by dragonwriter »

viswanathdurbha wrote: post #10

I like the W3C WebSub standard (formerly known as PubSubHubbub) which uses RSS/Atom underneath to syndicate content. The only catch is that it requires a publicly visible URL for callback. This is great for services like Feedly but may not work for individual subscribers who just want to use a client application and not run a server with public facing URL. But maybe, this is better than running a Mastodon server beca…

> I like the W3C WebSub standard (formerly known as PubSubHubbub) which uses RSS/Atom underneath to syndicate content.

While you can use Atom/RSS with WebSub, WebSub doesn't expressly use any particular syndication format (it can distribute any content directly, not just Atom/RSS feeds) and hasn't, IIRC, since one of the PubsubHubbub drafts (I think 0.3, but maybe 0.4.)

Re: Most use cases of ActivityPub would be better off as Atom or RSS feeds

#13

Post by AdrianSetter »

vorpalhex wrote: post #11

This reads pretty distinctly like "Get off my lawn you damned kids with your attempts at decentralization!". ActivityPub is a pretty new protocol and what it looks like in the wild is still evolving - but it's clear it's filling different voids then RSS. Sure, you could probably force most of these cases with some hacked up RSS implementation, and I can also use a longsword to mow my lawn. I'm personally very excited…

Most of the grief regarding ActivityPub vs RSS is that they are enough similar that a migration path could have been made where RSS gets an upgrade and could maybe be a bit compatible with ActivityPub rather than just ignoring RSS and creating ActivityPub without a clear upgrade path.

Re: Most use cases of ActivityPub would be better off as Atom or RSS feeds

#16

Post by willvarfar »

vorpalhex wrote: post #11

This reads pretty distinctly like "Get off my lawn you damned kids with your attempts at decentralization!". ActivityPub is a pretty new protocol and what it looks like in the wild is still evolving - but it's clear it's filling different voids then RSS. Sure, you could probably force most of these cases with some hacked up RSS implementation, and I can also use a longsword to mow my lawn. I'm personally very excited…

I've lost too much time messing around with rdf. Recently I was scraping some activitypub feeds and I was actually thinking "why the fk can't this just be an RSS feed?"

Re: Most use cases of ActivityPub would be better off as Atom or RSS feeds

#19

Post by comesee »

Yeah, I've long thought that the syndication that happens via server-server communication could be replaced with a smarter client. As far as UI goes, Twitter seems more like a browsable network, e.g. @ IDs, follower/follows lists, and those features seem to be key, not the specific transport. Would like to see something like Mastodon but based on RSS.

Re: Most use cases of ActivityPub would be better off as Atom or RSS feeds

#20

Post by _wmd »

lazyjones wrote: post #18

It doesn‘t seem very smart to download a whole RSS feed for users who tweet 5 times a day every time they do it, it‘s 9000 entries after 5 years. Incremental updates are fine and scale.

Push architectures are no panacea, they create problems all of their own. For example in an unregulated landscape like the Internet, it becomes difficult to impossible to control the flow of updates to any individual peer. Options are unsubscribing or dropping updates, resulting in data loss.

The equivalent scenario in polling land produces a better result: an oversubscribed producer that begins dropping requests will typically just cause a transient delay, as clients retry at a later time.

RSS feeds commonly don't include their full history - certainly this is true of the biggest providers like Blogspot.

Finally a good client will know to adjust its polling delay according to the traffic of a particular feed. This is a Pull-based systems of course suffer from latency, but they require vastly less centralized state and coordination than a push based system, and suffer from much less painful failure modes

Most exciting of all (in my opinion), is that pull-based designs can exist on top of all the infrastructure that already existed, rather than requiring dedicated active network components all of their own -- that's a whole lot of crap code we can avoid rewriting over and over again for the next decade.

Post reply on HN