I feel need to address some points of the authors (I realize it's a hot take so it's meant to be biased):<p>> But what does this buy us? For the most part it means that every piece of content everyone writes needs to be replicated to every point in the federation mesh to be useful.<p>This is because ActivityPub is tied to RDF and linked data concepts. This isn't specific to ActivityPub, just a criticism of the linked data web. As we will see later, the author doesn't quite understand that linked data can be fetched only on demand and represented otherwise as only an IRI, reducing data replication to a minimum. It depends on the specific ActivityPub implementation.<p>> This isn’t creating a distributed network, this is creating a whole bunch of massive points of failure.<p>This is a pretty ungenerous characterization. It's a distributed system where robustness is not a part of the protocol. It needs to be solved elsewhere, so innovation is needed.<p>> Meanwhile, what does this buy you? Immediacy of updates? Okay, does it really matter how quickly you see someone’s new content, if it’s worth seeing?<p>I think this is another ungenerous characterization. It buys a federated set of communities and applications that can exchange linked data in real time.<p>> For example, user-agents and RSS providers can use the If-Modified-Since: header to only get the feed updates if the content has changed since the last fetch.<p>ActivityPub also has a diffing system of data in place with Update activities too.<p>> Oh, and ActivityPub stuff generally also means that all attachments and other content also get replicated.<p>This is not true and is entirely implementation specific. If Mastodon creates local caches of federated data, that's it's design choice. Other applications can always fetch-on-demand and go back to the Pull Model.<p>That being said, static sites are not served by ActivityPub so that portion of criticism is definitely spot on.
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.<p>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.
I'm not an ActivityPub user, but this post remindeds me of the initial comments to "Show HN: Dropbox" [1].<p>"For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem."<p>1: <a href="https://news.ycombinator.com/item?id=8863" rel="nofollow">https://news.ycombinator.com/item?id=8863</a>
I agree with those statements.<p>That is why we are using Atom on top of Pubsub in XMPP to built social networking features. The sub-layer is changing (Atom is embeded into Pubsub XML on top of TCP real time streams, XMPP) but in the end the content is not "transformed" but just "transported".<p>Atom already provides most of what ActivityPub provides regarding the description of the content (rich content, attachments, external links, comments, reply-to...).<p>You just need to put it on top of a layer that specifies how this content can be accessed, subscribed and delivered. In our case it's XMPP Pubsub but it can also be pure HTTP requests. Good thing is that moving from one to another is pretty easy.<p>This is a static page generated from Atom articles published on a XMPP Pubsub feed from TechCrunch RSS/Atom feeds <a href="https://nl.movim.eu/?node/news.movim.eu/TechCrunch" rel="nofollow">https://nl.movim.eu/?node/news.movim.eu/TechCrunch</a>, we can even generate back an Atom feed from it easily. On a similar way you can handle personal "blogs" <a href="https://nl.movim.eu/?blog/edhelas@movim.eu" rel="nofollow">https://nl.movim.eu/?blog/edhelas@movim.eu</a> with likes, shares and comments :)<p>The XMPP Standard Fundation is working for more than 10 years now on integrating those concepts together and glueing existing standards to deliver social-features next to IM features and so on...<p>You don't have to create "new standards that will cover everything else" (see <a href="https://xkcd.com/927/" rel="nofollow">https://xkcd.com/927/</a>) if you can just glue the existing ones together.
The author doesn't see the difference between ActivityPub as a specification and implementations of ActivityPub that make some implementation choices of their own. No one forces the AP clients or implementations to build local caches, no one forces them to replicate everything on their own.
That's weird that you have to download from a whole other instance, I would have thought the client requests what it needs when it needs it, and points to some sort of UUID to another instance that can be queried later by a client.<p>I'm really lovestruck by the capabilities of ActivityPub and I want to work on a federated Tumblr alternative, but I just have not found the time with all the personal stuff I have going on currently, but ideally you wouldn't store everything on your instance (unless you rather cache it, now THAT makes perfect sense to me) you would let a browser request certain things via AJAX and maybe your instance could tell the other instance, hey guy you keep asking me for this waaay too often, can you cache it for me? kthxbai and those who don't do it would be considered broken instances and possibly rejected? Not sure I feel like the protocol is still way too young. Also not sure about the security implications but let's assume that sane SSL cryptomagic is a requirement for blogging instances (or just all of them).
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 because we can still have the benefits of a simple Atom format and protocol.
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.
Some weeks ago I replaced my long-closed Twitter and Facebook accounts with an RSS feed: <a href="https://rinzewind.org/shared.xml" rel="nofollow">https://rinzewind.org/shared.xml</a>. Given that 99 % of what I was doing there was share articles, this works pretty much the same (and it's troll-free!)
It seems like you would want to support RSS, Atom, and ActivityPub to allow both news readers and newer things like Mastodon to work?<p>Maybe RSS could be dropped? Are there news readers that support RSS but not Atom?
Forget RSS/atom, use microformats2 h-feed.<p><a href="https://indieweb.org/sidefile-antipattern" rel="nofollow">https://indieweb.org/sidefile-antipattern</a><p>And there is existing tech for the popular reply-like-repost UX for this, based on webmention.
I actually dream about bringing Atom (as far as I understand it's better than RSS but RSS just seems a better brand-name for this, in fact in many cases when you click on a link that says RSS you'll get Atom) back, expanding it with social functionality like likes, reposts and comments, implementing it better (auto-generated feeds on many sites are pretty crappy) and popularizing generic feed readers so non-geeks would be able to interact with others' self-hosted blogs (like my blog built on GitHub Pages) as easy and fun as it they do with Facebook, Instagram etc.
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.