Greeners: check for updates!
brent.micro.blog
@eridius Not yet. I’ve been thinking about how it should work before I write much code. Blog post in progress.
@brentsimmons any chance of support for fever, or some other interoperable api for selfhosted readers down the road? I’d love to use evergreen full time, but can’t kick my selfhosted habits.
@eli I’ll be adding more syncing systems for 2.0 (and probably 3.0) and will certainly strongly consider Fever.
@brentsimmons even better, since you seem to be in the IndieWeb mood lately, you should consider supporting the emerging Microsub standard! – indieweb.org/Microsub – We use it in Together and its great.
@cleverdevil I don’t quite understand what that is — but I only gave it a quick read. That said, my general philosophy with Evergreen is to support IndieWeb things. (Currently working on h-feed support, for instance.)
@philbowell while it’s true that fever itself is gone, there’s healthy support for the standards in self hosted systems. Tt-rss has a plug-in, and the 1.0 version of miniflux has fever support baked in.
@brentsimmons totally fair. In concept, a Microsub server acts like the server-side of a reader. It has “channels” which are like folders and in them will be feeds. It fetches feeds, parses them, and normalizes them. @aaronpk is the spec author.
@cleverdevil @brentsimmons I'd love to work with you on improving the Microsub spec based on your implementation of Evergreen! The idea with Microsub is to make it easy to develop reader interfaces without dealing with managing subscriptions or feeds.
@aaronpk Thanks!
Let me see if I understand it. I’ll try putting it into my own words:
Microsub is a spec for a syncing system.
The server crawls feeds, handles feed parsing, and keeps the true copy of the subscriptions list (folders and feeds).
A client app can add/remove folders and feeds and can download the parsed feed data.
(There are additional features, but I think those are the basics. True?)
The two things I think an Evergreen user would still want are: 1) per-article read/unread status syncing, and 2) per-article starred status syncing.
@brentsimmons That sounds about right!
I've had multiple requests for read/unread, but I'm curious about the starred thing. Is that meant as a private bookmark, or more like publicly favoriting something? Or is it more like adding it to a "starred" folder?
Out of the various feed reader APIs you've used like FeedBin, Feedly, Feed Wrangler, which do you like working with the best and why?
@aaronpk A starred article is a private favorite — generally it means something you want to come back to later for some reason. It’s common to have a special pseudo-feed that shows just starred articles, so a user can find them all easily.
I haven’t worked with current syncing system APIs much yet: my experience is mainly with NewsGator and Google Reader APIs, both now defunct. I vastly preferred NewsGator’s API, because it was designed as a syncing system, where Google Reader’s API was designed for Google, and was never publicly documented or supported, and didn’t work very well for apps like Evergreen (there were lots of ambiguous cases).
@brentsimmons Awesome, thanks, makes sense. I might add a note that servers should feel free to create these sorts of pseudo-feeds themselves. I'll see if I can dig up the NewsGator API docs. It's helpful to know that you're thinking about this from a "syncing" perspective rather than more of a REST API perspective.
@aaronpk The worst thing about NewsGator’s API, though, was that it was not just XML but SOAP. Ugh.
Syncing is often built on top of a REST API — but, still, I understand the distinction. Syncing also implies that I could do a thing in the client, not be able to reach the server, and queue that action and notify the server once it’s reachable again.
Syncing also implies a focus on efficiency, and this doesn’t always fit that well with a strict REST API, and may involve the need for things like sync tokens.