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.”)
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*
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.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!