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.
Laravel’s scheduler would make all of this so easy. But: if I use the built-in `hourly`, `everyTwoHours`, `twiceDaily`, etc. schedules, lots of feeds would still get downloaded at the exact same time (_on_ the hour). So, I can either use `hourlyAt($minutes)` to spread things out a bit, with `$minutes` a random offset (and somehow skip rarely updated feeds that I deem “not yet due”). Or simply use `everyMinute` and something like a `next_check` column to only fetch and process overdue feeds.
Surely there’s quite a bit that can be borrowed from Aperture. Not sure if I want extensive filters and what not. (Maybe you should, you know, just unfollow feeds you don’t enjoy reading. Anyhoo, we’ll see.) Not sure if the JS modals are a keeper, either. Not a big fan of ’em, although they are interesting (and kind of work well here).
“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.)
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.”)
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.)
@Canageek Static site generators. Or CMSes, come to think of it. I mean, they may switch CMSes, too, and forget about auto-generated routes and stuff.
@bekopharm A bit like WordPress’s “cron system.” Gets run every couple minutes and runs actions that should’ve been run. systemd is out of the question, thing has to be pure PHP (plus a single Linux cron job).
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!