I feel need to address some points of the authors (I realize it's a hot take so it's meant to be biased):
> 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.
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.
> This isn’t creating a distributed network, this is creating a whole bunch of massive points of failure.
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.
> 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?
I think this is another ungenerous characterization. It buys a federated set of communities and applications that can exchange linked data in real time.
> 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.
ActivityPub also has a diffing system of data in place with Update activities too.
> Oh, and ActivityPub stuff generally also means that all attachments and other content also get replicated.
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.
That being said, static sites are not served by ActivityPub so that portion of criticism is definitely spot on.
For me, a key negative witb ActivityPub is the complexity. The RSS/Atom spec is pretty simple, and it fairly easy to see how it could be extended to allow for similar functionality. What are the disadvantages to an RSS based system?
RSS is poorly specified, and cannot handle any feedback.
Atom is well-specified, and has provisions for feedback. But what user agents / popular libraries / whatever else actually uses the feedback (commenting) features? Which servers that serve Atom feeds support that, too, and how well?
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.
These are not "hacked up RSS"; they're just RSS (well, more often Atom or JSON Feed) combined with other technologies like webmentions. These are all, like ActivityPub, IETF recommendations/standards. I've mentioned Micro.blog before, but it's worth mentioning again: it's a centralized server producing a Twitter-esque timeline, but the sources of posts might be individual blogs using any number of different blogging engines. When I post articles to my WordPress site, people can reply on Micro.blog and have those replies show up both in their timelines and as actual comments on my blog. (And in fact, behind the scenes, a "hosted" Micro.blog site is actually using all the same technologies, with Jekyll as the blog engine.)
As much as I like many things about Mastodon, I'm not convinced that it's a superior philosophy to Micro.blog's; the dark cloud to federation's silver lining is that the admins of any instance that your social graph connects to (that is, you follow someone on that instance and/or vice-versa) can break those connections without warning and with no recourse to you, beyond moving to another instance and hoping it doesn't happen again.
And, speaking more generally, I think the author definitely has some points that shouldn't be dismissed out of hand: it's possible that ActivityPub might indeed be better than other feed protocols at solving certain problems, but it's worth looking at each use case and asking if that's really true in this case. PeerTube might be one that ActivityPub excels at and that feeds don't, for instance. (I don't see anything about PeerTube's implementation that proves what it's doing with ActivityPub couldn't be done just as easily with, say, JSON Feed, but I haven't dug into that.)
The micro.blog way of doing it is really confusing, if I post something on my blog it shows up in micro.blog and then people can comment there and it shows up on my blog (in theory, in practice it never did for me, I never got a webmention from there), but now I want to answer on one of those comments and I have no idea how. If I do it as a comment post on my blog it never reaches those people from micro.blog, so the only way to do it is to externalize commenting to micro.blog and thus not being able to own my own content anymore, which is what micro.blog was advertising for all the time. Same with "likes", etc.
I think the main draw of Mastadon is that it's an intentional experience, with blessed clients, discovery, etc etc. I'm unlikely to read anyone's blog if it's not put in front of me somehow. Furthermore, all I need to do to interact is install the client; I don't need my own site to do it.
Overall I think your argument is very strong if you can provide a comparable experience to mastadon. If not, then it's not clear why the benefits are worth it.
Micro.blog proves it's possible to provide a comparable experience--in some ways I prefer it, although that has much more to do with its aesthetics and nascent culture than any underlying technology. At any rate, if your blog is hosted on Mastodon itself, you don't even have to know it's a blog, per se--you can just use it exactly like Twitter.
The catch right now is that Micro.blog is a paid service. I don't see any reason why someone couldn't set up something very similar built on the same tech--other than, of course, the willingness to put in the time and money. :)
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?"
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.
I'm not an ActivityPub user, but this post remindeds me of the initial comments to "Show HN: Dropbox" [1].
"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."
Kind of true of all [new] technology though. Will it be a Betamax or a Blu Ray? I think the point of the article is trying to make the case that maybe you don't need the extra complexity of ActivityPub for your project.
Also, that user was completely right re: Dropbox, but they missed the market value of packaging all that for you in a few clicks install, on any platform with 99% uptime (also, I believe that user has noted in other threads they recognize their mistake in making the argument that Dropbox wasn't a value-add). On the other hand, it seems to my uneducated opinion on ActivityPub, that it is trading extra complexity for...push?
> It's funny how often that comment—which I made as a 22-year-old undergrad—resurfaces. Someone even reached out to me 2 weeks ago because they wanted to use it in an article as an example of "the disconnect between the way users and engineers see software"!
> I like to think that I've gained a lot of perspective over the last 11 years; it's pretty clear to me that point #1 was short-sighted and exhibited a lot of tunnel vision. Looking back, though, I still think that thread was a reasonable exchange. My 2nd and 3rd points were fair, and I conceded much of point 1 to you after your reply (which was very high quality).
> Obviously, we have the benefit of hindsight now in seeing how well you were able to execute. Kudos on that!
That comment was true then and is even more true now. rsync, unison, and git over SSH provide a far superior solution for more use cases (many of which Dropbox cannot support) than Dropbox does, without any of Dropbox's risks to privacy.
And how many easy to use, one-click install, git over ssh with port-forwarding and key generation packages are there to download out there? There's two levels of software - easy to use and complicated. They both can accomplish the same goal with different levels of privacy.
There is no such software, because what you are asking for is for the software to "one-click install" read your mind. Dropbox cannot cover customized use cases, and it does not accomplish the same goal. My use of the commands mentioned cannot be replicated by Dropbox. The facts that Dropbox does not provide adequate privacy, and is proprietary software, also prevent it from accomplishing certain goals (namely that I want my data to remain private, and that I would like to avoid using proprietary software).
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".
Atom already provides most of what ActivityPub provides regarding the description of the content (rich content, attachments, external links, comments, reply-to...).
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.
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...
You don't have to create "new standards that will cover everything else" (see https://xkcd.com/927/) 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.
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).
A problem with opportunistic caching would be degraded user experience for the first user that sees some specific piece of content, since they'd have to wait (potentially for seconds) for their instance to fetch the content from the origin instance.
pleroma's media proxy is works just like that and the user experience is fine. actually, i've run instances that don't have caching configured and it still works fine (if a bit unfriendly to other instances).
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.
> 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.)
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: https://rinzewind.org/shared.xml. Given that 99 % of what I was doing there was share articles, this works pretty much the same (and it's troll-free!)
> Maybe RSS could be dropped? Are there news readers that support RSS but not Atom?
Unfortunately yes. Gnus has not gotten Atom support yet (people keep using external programs to translate). Also far too many feeds still output RSS instead of Atom. RSS is a horrible format and there is no reason today to use it instead of Atom.
Are there any feed clients that support h-feed? I’m legitimately asking. I was looking for a h-feed capable client (like a traditional feed reader with h-feed support) only a few days ago and came up with none.
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.
> expanding it with social functionality like likes, reposts and comments
One of the problems I had with blog comments is spam. Blogger would queue up moderated comments and send you an email about them. The idea occurred to me that that was redundant and it would be better to cut out the middleman - you are getting email notifications about comments needing moderation, and email already had long established and much better spam filtering. Why not have people submit comments via email? That way you can also reply to people privately. This is also convenient for people who read their feeds via RSS-to-email or in newsreaders/email clients like Thunderbird and Gnus.
Another aspect of comments via email is that it is much more like a letter to the editor. Your blog posts are articles, and you can choose to update them with corrections and comments that people send in, instead of trying to manage a half-baked message board that is the standard LiveJournal/Blogger/Wordpress/Disqus comments section.
I think an easy and valuable way to get non-geeks to use web page feeds more is to provide the option to sign up for the feed via email, by offering a "newsletter" option.
I upvoted your response as your ideas are very reasonable but as for me, I don't like e-mail for a number of reasons, both psychologically subjective and technical.
The first things the e-mail ecosystem is to do to become more adequate to the modern day world are to deprecate all the codepages but UTF-8 for any part of a message (header included), eliminate the overquoting tradition (including full text of the message the message is a response to) and introduce an efficient thread tracing mechanism instead, establish a more reasonable signature culture (i.e. people and software to stop including redundant and useless information in the bottom of every message) and make Markdown a core part of the standard (while HTML should better be deprecated).
Those are all very good ideas for email. Part of it could be dealt with in RFCs, part of it by changing default email client behavior.
I also agree that email should be a personal preference. I think that DFeed[1][2] shows how open discussion systems should be built. DFeed provides a unified discussion system that is simultaneously accessible through email, NNTP, a web interface, and Atom feeds. That would be a really nice way to offer a comment discussion system on a blog.
What you're describing sounds a lot like the indieweb movement. Worth checking out although they're getting significantly less momentum than activity-pub or any other number of protocol-first social networking projects.
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 <5 line function, and something Google Reader was implementing a decade ago.
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.
P2P and self hosted stuff is what I want out of the internet, not SaaS style platforms. People's cable modems are almost always on so it's reasonable for them to have some almost-always-on services behind them, but circumstances make it difficult to build viable P2P tech:
- It's tough to monetize since true p2p software can just get pirated. You can't gatekeep to make sure people pay.
- The shortage of IPv4 with the help of buggy insecure operating systems made closed-to-the-outside NAT standard, making peers inaccessible without manual configuration or some helper technology.
- Data hungry government and corporations see independent communication channels as an obstacle to their goals. (See the recent story about five eyes pushing for backdoored crypto in Australia.)
I've always felt that NAT ruined the internet. It made it basically improbable that someone might host something at home like the internet was made for.
If you care about this, the best thing to do is to start using IPv6, and insisting on IPv6 support in any interactions with service providers (SaaSS, hosting, data providers, etc.) that you have.
I feel need to address some points of the authors (I realize it's a hot take so it's meant to be biased):
> 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.
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.
> This isn’t creating a distributed network, this is creating a whole bunch of massive points of failure.
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.
> 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?
I think this is another ungenerous characterization. It buys a federated set of communities and applications that can exchange linked data in real time.
> 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.
ActivityPub also has a diffing system of data in place with Update activities too.
> Oh, and ActivityPub stuff generally also means that all attachments and other content also get replicated.
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.
That being said, static sites are not served by ActivityPub so that portion of criticism is definitely spot on.
For me, a key negative witb ActivityPub is the complexity. The RSS/Atom spec is pretty simple, and it fairly easy to see how it could be extended to allow for similar functionality. What are the disadvantages to an RSS based system?
RSS is poorly specified, and cannot handle any feedback.
Atom is well-specified, and has provisions for feedback. But what user agents / popular libraries / whatever else actually uses the feedback (commenting) features? Which servers that serve Atom feeds support that, too, and how well?
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.
Well, an alternative reading of this is "maybe we can solve some of the same problems with IndieWeb principles instead of ActivityPub."
https://www.indieweb.org
These are not "hacked up RSS"; they're just RSS (well, more often Atom or JSON Feed) combined with other technologies like webmentions. These are all, like ActivityPub, IETF recommendations/standards. I've mentioned Micro.blog before, but it's worth mentioning again: it's a centralized server producing a Twitter-esque timeline, but the sources of posts might be individual blogs using any number of different blogging engines. When I post articles to my WordPress site, people can reply on Micro.blog and have those replies show up both in their timelines and as actual comments on my blog. (And in fact, behind the scenes, a "hosted" Micro.blog site is actually using all the same technologies, with Jekyll as the blog engine.)
As much as I like many things about Mastodon, I'm not convinced that it's a superior philosophy to Micro.blog's; the dark cloud to federation's silver lining is that the admins of any instance that your social graph connects to (that is, you follow someone on that instance and/or vice-versa) can break those connections without warning and with no recourse to you, beyond moving to another instance and hoping it doesn't happen again.
And, speaking more generally, I think the author definitely has some points that shouldn't be dismissed out of hand: it's possible that ActivityPub might indeed be better than other feed protocols at solving certain problems, but it's worth looking at each use case and asking if that's really true in this case. PeerTube might be one that ActivityPub excels at and that feeds don't, for instance. (I don't see anything about PeerTube's implementation that proves what it's doing with ActivityPub couldn't be done just as easily with, say, JSON Feed, but I haven't dug into that.)
The micro.blog way of doing it is really confusing, if I post something on my blog it shows up in micro.blog and then people can comment there and it shows up on my blog (in theory, in practice it never did for me, I never got a webmention from there), but now I want to answer on one of those comments and I have no idea how. If I do it as a comment post on my blog it never reaches those people from micro.blog, so the only way to do it is to externalize commenting to micro.blog and thus not being able to own my own content anymore, which is what micro.blog was advertising for all the time. Same with "likes", etc.
I think the main draw of Mastadon is that it's an intentional experience, with blessed clients, discovery, etc etc. I'm unlikely to read anyone's blog if it's not put in front of me somehow. Furthermore, all I need to do to interact is install the client; I don't need my own site to do it.
Overall I think your argument is very strong if you can provide a comparable experience to mastadon. If not, then it's not clear why the benefits are worth it.
Micro.blog proves it's possible to provide a comparable experience--in some ways I prefer it, although that has much more to do with its aesthetics and nascent culture than any underlying technology. At any rate, if your blog is hosted on Mastodon itself, you don't even have to know it's a blog, per se--you can just use it exactly like Twitter.
The catch right now is that Micro.blog is a paid service. I don't see any reason why someone couldn't set up something very similar built on the same tech--other than, of course, the willingness to put in the time and money. :)
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?"
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.
I'm not an ActivityPub user, but this post remindeds me of the initial comments to "Show HN: Dropbox" [1].
"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."
1: https://news.ycombinator.com/item?id=8863
Kind of true of all [new] technology though. Will it be a Betamax or a Blu Ray? I think the point of the article is trying to make the case that maybe you don't need the extra complexity of ActivityPub for your project.
Also, that user was completely right re: Dropbox, but they missed the market value of packaging all that for you in a few clicks install, on any platform with 99% uptime (also, I believe that user has noted in other threads they recognize their mistake in making the argument that Dropbox wasn't a value-add). On the other hand, it seems to my uneducated opinion on ActivityPub, that it is trading extra complexity for...push?
I wonder how that user feels about always being referenced in this context.
Five months ago:
> It's funny how often that comment—which I made as a 22-year-old undergrad—resurfaces. Someone even reached out to me 2 weeks ago because they wanted to use it in an article as an example of "the disconnect between the way users and engineers see software"!
> I like to think that I've gained a lot of perspective over the last 11 years; it's pretty clear to me that point #1 was short-sighted and exhibited a lot of tunnel vision. Looking back, though, I still think that thread was a reasonable exchange. My 2nd and 3rd points were fair, and I conceded much of point 1 to you after your reply (which was very high quality).
> Obviously, we have the benefit of hindsight now in seeing how well you were able to execute. Kudos on that!
That comment was true then and is even more true now. rsync, unison, and git over SSH provide a far superior solution for more use cases (many of which Dropbox cannot support) than Dropbox does, without any of Dropbox's risks to privacy.
And how many easy to use, one-click install, git over ssh with port-forwarding and key generation packages are there to download out there? There's two levels of software - easy to use and complicated. They both can accomplish the same goal with different levels of privacy.
There is no such software, because what you are asking for is for the software to "one-click install" read your mind. Dropbox cannot cover customized use cases, and it does not accomplish the same goal. My use of the commands mentioned cannot be replicated by Dropbox. The facts that Dropbox does not provide adequate privacy, and is proprietary software, also prevent it from accomplishing certain goals (namely that I want my data to remain private, and that I would like to avoid using proprietary software).
I agree with those statements.
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".
Atom already provides most of what ActivityPub provides regarding the description of the content (rich content, attachments, external links, comments, reply-to...).
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.
This is a static page generated from Atom articles published on a XMPP Pubsub feed from TechCrunch RSS/Atom feeds https://nl.movim.eu/?node/news.movim.eu/TechCrunch, we can even generate back an Atom feed from it easily. On a similar way you can handle personal "blogs" https://nl.movim.eu/?blog/edhelas@movim.eu with likes, shares and comments :)
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...
You don't have to create "new standards that will cover everything else" (see https://xkcd.com/927/) 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.
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).
Pet peeve: it's "would have", not "would of".
A problem with opportunistic caching would be degraded user experience for the first user that sees some specific piece of content, since they'd have to wait (potentially for seconds) for their instance to fetch the content from the origin instance.
pleroma's media proxy is works just like that and the user experience is fine. actually, i've run instances that don't have caching configured and it still works fine (if a bit unfriendly to other instances).
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.
> 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.)
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: https://rinzewind.org/shared.xml. 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?
Maybe RSS could be dropped? Are there news readers that support RSS but not Atom?
> Maybe RSS could be dropped? Are there news readers that support RSS but not Atom?
Unfortunately yes. Gnus has not gotten Atom support yet (people keep using external programs to translate). Also far too many feeds still output RSS instead of Atom. RSS is a horrible format and there is no reason today to use it instead of Atom.
iTunes for podcasts.
Forget RSS/atom, use microformats2 h-feed.
https://indieweb.org/sidefile-antipattern
And there is existing tech for the popular reply-like-repost UX for this, based on webmention.
There are less than 9000 websites that supply h-feed formatted data, and only four of the top 10 000 websites. https://publicwww.com/websites/%22h-feed%22/
h-feed haven’t been a massive success.
Are there any feed clients that support h-feed? I’m legitimately asking. I was looking for a h-feed capable client (like a traditional feed reader with h-feed support) only a few days ago and came up with none.
https://indieweb.org/reader
Usually things that integrate more into the whole indieweb ecosystem, but some are (plugins for) more traditional feed readers.
This doesn't seem to work too well for sites that need JavaScript to render. Then again, I suppose those sites might not have RSS either.
Content sites, i.e. blogs/news type things, MUST NOT need JavaScript to render.
I agree, but that's where we're headed.
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.
> expanding it with social functionality like likes, reposts and comments
One of the problems I had with blog comments is spam. Blogger would queue up moderated comments and send you an email about them. The idea occurred to me that that was redundant and it would be better to cut out the middleman - you are getting email notifications about comments needing moderation, and email already had long established and much better spam filtering. Why not have people submit comments via email? That way you can also reply to people privately. This is also convenient for people who read their feeds via RSS-to-email or in newsreaders/email clients like Thunderbird and Gnus.
Another aspect of comments via email is that it is much more like a letter to the editor. Your blog posts are articles, and you can choose to update them with corrections and comments that people send in, instead of trying to manage a half-baked message board that is the standard LiveJournal/Blogger/Wordpress/Disqus comments section.
I think an easy and valuable way to get non-geeks to use web page feeds more is to provide the option to sign up for the feed via email, by offering a "newsletter" option.
I upvoted your response as your ideas are very reasonable but as for me, I don't like e-mail for a number of reasons, both psychologically subjective and technical.
The first things the e-mail ecosystem is to do to become more adequate to the modern day world are to deprecate all the codepages but UTF-8 for any part of a message (header included), eliminate the overquoting tradition (including full text of the message the message is a response to) and introduce an efficient thread tracing mechanism instead, establish a more reasonable signature culture (i.e. people and software to stop including redundant and useless information in the bottom of every message) and make Markdown a core part of the standard (while HTML should better be deprecated).
Those are all very good ideas for email. Part of it could be dealt with in RFCs, part of it by changing default email client behavior.
I also agree that email should be a personal preference. I think that DFeed[1][2] shows how open discussion systems should be built. DFeed provides a unified discussion system that is simultaneously accessible through email, NNTP, a web interface, and Atom feeds. That would be a really nice way to offer a comment discussion system on a blog.
[1] https://forum.dlang.org/help#about [2] https://github.com/CyberShadow/DFeed
What you're describing sounds a lot like the indieweb movement. Worth checking out although they're getting significantly less momentum than activity-pub or any other number of protocol-first social networking projects.
https://indieweb.org
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 <5 line function, and something Google Reader was implementing a decade ago.
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.
Most use cases of new thing would be better off as old thing.
I don't believe in federated solutions, but I'm also not sure if and when our end-user devices are ready for p2p.
P2P and self hosted stuff is what I want out of the internet, not SaaS style platforms. People's cable modems are almost always on so it's reasonable for them to have some almost-always-on services behind them, but circumstances make it difficult to build viable P2P tech:
- It's tough to monetize since true p2p software can just get pirated. You can't gatekeep to make sure people pay.
- The shortage of IPv4 with the help of buggy insecure operating systems made closed-to-the-outside NAT standard, making peers inaccessible without manual configuration or some helper technology.
- Data hungry government and corporations see independent communication channels as an obstacle to their goals. (See the recent story about five eyes pushing for backdoored crypto in Australia.)
I've always felt that NAT ruined the internet. It made it basically improbable that someone might host something at home like the internet was made for.
If you care about this, the best thing to do is to start using IPv6, and insisting on IPv6 support in any interactions with service providers (SaaSS, hosting, data providers, etc.) that you have.
All my sites support IPv6. My router is horribly old and doesn't. But, once it kicks the bucket, I'll be sure to get an IPv6-compatible one.