[bioemerl]

I'm absolutely amazed that people are going with federation of this form with this massive overhead instead of something like RSS, but beefed up to a standard, where you can just point your client to multiple web servers and have them use your server as identity provider and that's it.

Imagine your subscriptions and account living on one server, then when you log in that server gives you the list and your client goes and gets all the data.

We already had this sort of federation figured out, it's the open web. We just have to find a way to get the open web to provide the things that google, facebook, reddit, provided.

Easy way to contribute content.

Discovery for new content.

Search ability.

Kill the things centralized websites provided, let people host websites within that system, and let the clients handle dealing with the fact that there are all sorts of providers out there.

[zimpenfish]

> that server gives you the list and your client goes and gets all the data.

That would suck on a mobile device with limited bandwidth and/or data. Also lots of repetitive fetching when people have large number of followers too, no?

[CharlesW]

> That would suck on a mobile device with limited bandwidth and/or data.

Why would it be any different than using a mobile feed reader to follow hundreds of blogs, or using a podcast app to follow hundreds of podcasts? Both are commonly done on mobile all the time. Checking if a feed has been modified since the last time the client checked costs virtually nothing.

bioemerl: I've been casually digging into Mastodon and ActivityPub for the last few weeks and FWIW I think you're absolutely right — with the caveat that I may be missing something obvious, it's seems very dumb for Mastodon/ActivityPub servers to be downloading and delivering content on behalf of client apps.

[zimpenfish]

> Why would it be any different than using a mobile feed reader to follow hundreds of blogs

In my experience, you generally do that through an aggregator which has already cached the articles for you and you're doing a bulk fetch from a single host - that is quite different to calling out to hundreds of individual hosts and fetching a page from each.

> it's seems very dumb for Mastodon/ActivityPub servers to be downloading and delivering content on behalf of client apps.

Isn't that literally what an RSS aggregator does?

[CharlesW]

> In my experience, you generally do that through an aggregator…

My understanding is that a cloud-based aggregator (like Feedly) delivers feed and state information to clients, but not the content itself.

To test this with blogs, I did a new install of Reeder, synced with Feedly, then turned off Wi-Fi. In my subscriptions, I got everything that would be in the feeds themselves (notably item titles and descriptions as created by publishers) but nothing beyond that. The offline experience was mostly useless, suggesting that the client does most of the heavy-lifting even when leveraging cloud-based aggregators.

So is making a few REST API calls a significant savings over checking a couple hundred (or whatever) RSS feeds? With "If-Modified-Since" checks being so cheap, I'm not sure that inserting Mastodon instances as middleboxen makes sense. If all Mastodon did was store subscriptions and state info, it seems like we'd have a far more resilient microblogging ecosystem.

[zimpenfish]

> My understanding is that a cloud-based aggregator (like Feedly) delivers feed and state information to clients, but not the content itself.

Depends entirely on the feed. Just checked my most recent 100 entries from Feedbin - that comes back with 23k of `summary` and 508k of `content`. That was one call to return 661k of JSON covering 28 feeds.

> So is making a few REST API calls a significant savings over checking a couple hundred (or whatever) RSS feeds?

I've made one call to get (assuming >2k in `content` is a full article) 74 full articles from 28 feeds. Add another 26 and I'm looking at 27 total.

Even just retrieving the RSS feeds is 28 and 26 more for the non-included articles to make a total of 54 - double what I had to do via Feedbin. That's before we start considering response times and latency for each of those sites which would drag things down even further.

There's a reason why people use RSS aggregators!

[bioemerl]

Is it really that big of a deal? We've advanced like 15 years since we were able to handle Twitter on our devices, why can't we handle many feeds from multiple servers?

[ilyt]

That was solved with RSS readers.

It would be akin to having single-user mastodon instance

[bioemerl]

Rss seems like it's a pretty bad standard that doesn't let you do a ton with it and doesn't solve problems of things like discoverability or your ability to post content.

It's great for reading from lots of new sites at the same time, but it's clear that it hasn't taken off and when that happens it's normally for pretty good reason

[ilyt]

Think they are referring to way it works, not technical details of implementation, as it isn't really "social network" with no ability to have any social action

As in you can subscribe to who you want and no moderator will stop you and then you can... just comment on a blogpost or article, with no 3rd party aside from this particular space moderators

[zimpenfish]

> That was solved with RSS readers.

Wasn't it solved by moving to RSS aggregators and doing a single bulk fetch of your cached N blogs rather than calling out individually to N blogs?

[bombcar]

That works best when you have few clients and lots of “sources” but mastadon is apparently designed for few sources and lots of clients - in which case updating the “server” once could be more performant.