I may finally start rewriting my Microsub server from the ground up. It’ll be inspired by both Aperture and Yarns, plus all the extra goodies I’ve been adding to my Aperture fork. Only dependencies should be PHP and MySQL, and, optionally, Redis. This should make it _very_ easy to self-host. And a built-in client/reader, eventually.

It’d still totally leverage X-Ray for parsing feeds, and use Yarns-like polling—WebSub may be a future option. The client bit would be more of an RSS reader and less of a social media app.

Another benefit of built-in polling rather than relying on a separate WebSub server is that it suddenly becomes really easy to update feed URLs.

“Really easy.” I’ve given the channels as categories some more thought, and editing sources outside of channel context isn’t too easy, either, _if_ you want to offer “channel-specific source settings,” like if the aggregator should try and fetch original web pages rather than save just the feed summaries. (In Miniflux, which knows only categories, and limits them to one per feed, this is a source-specific setting. Or rather, user-specific source setting.)

Would anyone want the same content displayed differently in different channels, though? I mean, probably not. (Wondering if there’s some sort of `hasManyThrough` with pivot data.)

Having `source_user` rather than `channel_source` would clear up some of this confusion. And `entry_user`, perhaps, so that we can still filter entries in a user-specific (rather than channel-specific) way. Or we drop all that and just parse feeds. And filter dynamically, if we must. That’s what RSS readers do, I think—not sure. They don’t offer different channels. One category per source, and limited options otherwise. Ima look at FreshRSS’s code.

Looks like FreshRSS may be single-user, which is a heck of a lot easier. As soon as you go multi-year, you’ll want to centrally process feeds—poll them once, not once per “owner”—yet allow different users to give ’em different names. Aperture does that, uses `channel` as an intermediate model, works great. Thing is, as soon as you’ve got per-user source settings, you’ve gotta store these per channel. And since sources can belong to multiple channels, there’s going to be duplicate settings.

That’s it. That’s the thing. There’s either going to be duplicate (per-channel) data, or it’s all going to be done per source (per user), with channels merely acting as labels—as categories. (I’m guessing actual channels are somehow inspired by TweetDeck’s columns or so? In that they _might_ show different entries of the same sources, because of filters and all. Having spent a couple years using traditional RSS readers, I really had to get used to “channels.”)


The spec doesn’t quite explain _why_ we need channels. Only things like, “Removing an entry from one channel should not remove it from other channels.” Dangit, there goes my idea of having them behave like traditional categories!

Could it be an option to limit sources to a single channel, at least through the UI? Sure. Make it a select menu. Make it possible to add a source from anywhere in the app, and override the current channel, if any, using the select box value. Make it editable after the fact, too. That could work. (I’m now using checkboxes to easily move or copy sources around, but I don’t think it’s 100% secure in multi-user environments. And it clutters up the UI.)

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!