fred: feed reader extraordinaire
fred: feed reader extraordinaire
fred lets you run your own RSS/Atom feed reader backend. Break free of external dependencies. No more rug-pulling by providers!
fred lets you run your own RSS/Atom feed reader backend. Break free of external dependencies. No more rug-pulling by providers! Read more
feed reader extraordinaire (fred)
fred is a RSS/Atom feed reader. It is both a backend (stuff you run on a Unixy box somewhere) and a frontend (stuff which runs in your web browser). This project aims to clean it up and release it as open source.
Why this is important
With fred, you own it and you run it. You aren't relying on someone else to run it for you. The problem with using someone else's service is that it might not always be there. Google Reader is going away this summer, and everyone on it is experiencing this problem right now. Do you want to jump somewhere else and worry about how long it has to live, or do you want to build something for yourself?
fred lets you turn a boring old Linux box into a feed fetching, post-wrangling superstar. This can be a dedicated server or VPS in some far away data center, or it can be a box in your apartment. If you're not of the Linux persuasion, that isn't a problem! A Mac will also work just fine if you have a few developer type things installed from Macports or Homebrew.
Other systems (like my BSD friends) should be fine. I can't guarantee compatibility with every single Unix box out there, but if you have at least a C++98 compiler (like gcc or clang), jansson, libxml2, and libcurl, it should Just Work (tm).
The web part of fred's backend currently consists of five programs which require nothing more than a CGI interface, such as the Apache web server. These five programs handle retrieval of posts, marking posts read, getting the user's list of feeds, adding a feed for a user, and dropping a feed for a user.
There is also a program which needs to run periodically to bring in new feeds. Having it start via cron or your system's local equivalent is fine. You can even run it by hand if you really like that kind of control.
You don't need to use the frontend. You can totally ignore it if you like, and write your own client to talk to the backend. If someone else writes a compatible client, you can use that, too. You're in control.
Want to see what it looks like? You can poke around the version I wrote for myself. It's this code which will be updated, cleaned up, and expanded to be appropriate for a wider audience. See it here: http://fred.rachelbythebay.com/
The viewer page is smart about this, and if it detects a non-CSP-compatible browser, it punts on rendering the content and instead offers a link back to the original page from the feed. Then you can just click through (or press ENTER) and be whisked off to the page in its original context.
More about the author
I create stuff. Lots of stuff. I went out on my own in May 2011. In that time, I've created quite a few things:
- At least a post a day about life in technology, war stories, what it's like inside corporate America, you name it. http://rachelbythebay.com/w/
- Two ebooks compiled from those daily posts: The Stupid Hour (2013) and The Bozo Loop (2012). Both are available on Amazon for the Kindle, or you can download them from my web store: https://rachelbythebay.com/
- The software to build both the posts and the books themselves. It's called "publog" and it, too, may be released some day.
- The actual web store stuff: Persona integration for logins, Stripe integration for payments, plus item tracking and authenticated downloads.
- "Super Trunking Scanner": basically a software-defined radio which sits here and gobbles down a 3.5 MHz swath of spectrum 24 hours a day, 7 days a week, and has been running since July 2011. It's logged almost 2 million police, fire and medic dispatches and other local radio traffic. http://scanner.rachelbythebay.com/
- A build tool for C++ (mentioned above) which figures out your dependencies from the code itself (via #include directives) so you don't have to repeat yourself in a Makefile. As a result, it's possible to build large projects with *no* Makefile... and no other build language, either! Binary only for the moment. May be a future KS project. http://rachelbythebay.com/bb/
- A version of fred for myself. This is what I'm going to take, clean up, expand, and make ready for a wide audience in this project. You can play with the existing version of fred in guest mode: http://fred.rachelbythebay.com/
- A bunch of random diversions to have fun in your web browser, like some dumb display hacks (Sierpinski, anyone?) and a Hacker News randomizer which looks curiously like the real thing. http://rachelbythebay.com/fun/
- Other custom stuff for clients I can't talk about until they're ready to release to the world. Sorry. (But you will like the things they're doing!)
As for me? Don't worry. I still get plenty of sleep.
Risks and challenges
The Big One might hit the Bay Area and swallow my house, including all of my computers. I store my source code in multiple geographically-separated locations, so hopefully one of them will survive. Of course, once the code is out there, everyone who downloads a copy will be a living backup copy, so that's awesome, too. As for the computers, I could finish the project on a $300 laptop from Frys. Give me a good text mode console and I can write code.
I'm going to have to figure out a good way to make people happy in terms of database backends. I'm thinking PostgreSQL, but there might be an overwhelming cry for MySQL. If it turns out I need to support multiple backends then I'll have to arrange the code to handle them intelligently and use appropriate flavors of SQL for each one.
Related to the above, there's the matter of making it build everywhere: specifically, discovering and using libxml2, jansson and libcurl, plus the database libraries. I guess I have to use autoconf and friends for this, despite my distaste for them, because the world has not yet discovered my awesome C++ build tool. Maybe that'll be another Kickstarter project some day.
I need to find a non-embarrassing way to store the authentication data for the web programs. Baking the username and password into the binary is not going to cut it. It'll probably wind up being stored in some config file outside the document root.
I have to put some kind of authentication system into this thing so people can log in. I'm leaning toward Mozilla Persona since I already have the code to support it, and it's just a matter of connecting it to fred. I'm trying to avoid having Yet Another List of Usernames and Passwords with this thing, in other words.Learn about accountability on Kickstarter
- (30 days)