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.
Lots of folks out there who switch SSGs and not redirect their RSS feeds, unfortunately. (Or announce the change before it happens.)
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.
Think I’ve got it. All that’s left is the actually hard stuff: the interface for adding, editing, and categorizing feeds and channels.
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.)
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.)
Slack timelines, apparently—per the spec. (Is it weird mentioning commercial organisations like that? I’ve no clue.)
Dangit, I just want an RSS reader that supports microformats—author avatars! (And being able to quickly tell replies from other content types! Recognize bookmarked URLs! And so on.)
I don’t care for a notifications channel. I wanna read other people’s blogs is what I want.
First thing I disable in any social media app is freaking notifications. But adding things to my reader’s “Notifications” on purpose? I guess it could work, and a Home channel, too, if one really is looking for a new “Home” on the web (i.e., a Twitter replacement).
I did read someone mention their webmentions ending up in their Microsub reader, tho. Maybe I should try that. I mean, that’s what the channel API keys are for, right? Try having your reader do that! *decides to try and love channels*
Knew I’d seen this somewhere! https://aperture.p3k.io/docs
I’m going to add this to my WordPress site. Push a notification to my Microsub reader whenever I receive a comment/mention. Not because I wasn’t at all hating on it just now, but because I can.
Well, that was easy.
@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.
@jan So… basically a systemd timer? :)
@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).
Just remembered Laravel has built-in model serialization. We should use it. Now wondering if `hasManyThrough` could used to tie entries to channels—it’d be less flexible, though, than the current implementation.