Me during the day: why am I always so tired?

Me at 3 AM: I must design the database schema and update algorithm for my new RSS reader

Follow

Okay I wasn’t expecting quite the response to an off-the-cuff post about a project I’ve been talking about on and off for the last several years. I guess people really want a new RSS reader!

My initial thing is just building a subscription engine that supports authenticated private posts through a few different mechanisms and it’ll be a long time before I get any UX in place. In the meantime check out github.com/fluffy-critter/Feed if you want the mature, stable self-hosted reader I’ve been using.

And if you want to know more about this new project (which, I reiterate, will not be particularly usable for a long time and is initially just to prove out some protocol-level stuff), there’s a smattering of information about it on my blog, particularly at beesbuzz.biz/blog/5711-Access- and beesbuzz.biz/blog/8118-So-what

Show thread

also seriously please don't hold your breath expecting Subl to, like, exist anytime soon. Literally all I've written is some ideas and a sketch of a database schema, and I have a day job and a severe chronic pain disability. I do appreciate the attention but I can only do so much. :)

Show thread

Just to centralize some of what I've been saying about this, I went ahead and opened a (very placeholder) repo at github.com/PlaidWeb/Subl/

Show thread

@fluffy Ah. Never got the point of those, but glad you'll be able to help so many people.

@Canageek the point to them is that you manage your subscriptions and read status from one location. It’ll also support clients eventually.

@fluffy Yeah, but if funding ever goes away it turns off. I'm a browser extension person, since Firefox automatically syncs my bookmarks, and even if the creator abandons it, it usually works for a good few years until a browser extension breaks it.

@fluffy That is better, I'm still a installed program person when I can. Too many bad experiences with web apps going away, changing, etc.

And I don't have the money or skill to self host.

But as I said, glad you are filling a niche that will help people.

@Canageek well, you should also be able to self-host it on your own desktop computer if you want. :) Flask apps are incredibly portable, and I try to keep my stuff Windows-compatible even if I don't run Windows normally myself. I will absolutely not require, like, a full database system or whatever.

@fluffy Ah, I hear "self-host" and I hear "you need your own web server" and "If you don't set this up it will open 8 million security holes" (ie wordpress)

@Canageek oh goodness no, there's lots of ways of building web software which aren't total trash.

@fluffy Slightly suspicious since I've never seen it, but that does sound better then like Discord.

@Canageek yeah I'm not fond of Electron or React or Angular or any of the other shitty frameworks du jour. And I build my web stuff using Python+Flask which is inherently more secure than PHP (or at least it's harder to majorly mess up with it as it adopts secure-by-default patterns wherever possible).

@fluffy My opinion of web apps is biased heavily by the fact that I lied for a couple years with really bad wifi, but for some reason ONLY my laptop had a problem with it. So it would drop out for a few seconds very couple of minutes.

That *breaks* almost every web app *hard*. Downloads and static sites usually don't notice, but suddenly buttons in most web apps just...don't do anything, and they fail silently. Google is just about the only site smart enough to NOT break like this.

So I prefer my apps written in C or whatever and safely installed on my computer, or tucked into my browser if they rely on the web anyway.

@fluffy (Also the fact I saw someone implement the discord client, which is hundreds of MB in 12 MB with almost every feature intact when they rewrote it as a native application)

@Canageek yeah a lot of web developers don't consider failure cases, and a lot of frontend frameworks make it hard to do that. I adopt a philosophy of doing everything server-side and only using javascript to progressively enhance the client UX, and doing it in ways which are robust around failures like that.

@fluffy Nice! Thank you for not assuming everyone lives in California with fast, perfect internet.

@Canageek yeah, I'm sorry so many web developers have given you such a bad impression about what hosted web services are like. (And I totally agree!)

@Canageek I'm definitely not approaching this in the way that "modern web apps" are doing it. Here's a rant I wrote about web development recently: beesbuzz.biz/blog/2934-Advice-

@fluffy (This also brought to you by the fact I'm being forced to mark in a badly written web app right now.

Enter grade. Click outside textbox. Hit "End" on the keyboard to scroll to the bottom of the assignment. Hit "Update Scores" Wait 3-4 seconds for that to happen. Hit next student. Wait 4-5 seconds for that to load. Hit "Question 9" and wait for it to scroll to that question. repeat.

(So 6 s * 3 questions * 59 students = 17 minutes of loading time)

@fluffy Basically every web app ever.

I really wish the IMAP model was the default. Local client, downloads all your data, then syncs each action to the server either in real time or when you next connect. Wastes way less bandwidth (only have to download data and client once, not every time) and WAY more robust.

@Canageek

Hopefully those days are gone. With PWA, webapps are now cached and served locally so only the REST calls can fail (as with a real desktop app).

So the app loading is instant, will work offline and the update process is very close to the desktop one (side loading and then updating).

Of course, you get all this only if the webapp is PWA, but it's not really difficult to do, especially if you're relying on any proper framework.

@fluffy

@NicolasConstant @Canageek I mean PWA is sort of trying to undo the problem with "web apps"

I'm not building a "web app"

@Canageek that said, some features will need to be on a server that's publicly reachable; WebSub (push notifications) and TicketAuth (one of the authentication mechanisms) for example. But those won't be required for the reader itself to work, they're just additional functions. (And TicketAuth also requires that you have your own website already anyway so don't think you're missing out on that.)

@Canageek building for the web means a lot less difficulty with a bunch of things; I don't want to build desktop apps because those tend to break pretty quickly, and I also don't trust, say, Firefox extensions to remain usable in the long term.

@Canageek also like. RSS feeds are on the web already. And having something server-based allows a lot of stuff like push and whatever.

@fluffy your project is much further than most of mine

@SoniEx2 re the Feed On Feeds issue you opened, getting started with FoF dev is pretty easy and it seems like a pretty simple thing to add in, so if you have any willingness to add code to a pile of reasonably-well-factored PHP hacks I'd suggest giving it a try. :) I had written some adaptive refresh logic a while ago which never worked that well but might be possible to adapt or at least use as a guide.

@fluffy I'll see if I can find spoons for it some time.

@SoniEx2 yeah that's always the problem :/

FWIW I don't think the Refresh header really makes much difference, especially given FoF's defaults and popular sites hopefully using a CDN or reasonable caching to serve up the feeds anyway.

Sign in to participate in the conversation
Queer Party!

A silly instance of Mastodon for queer folk and non-queer folk alike. Let's be friends!