- indieweb: meta
Why didn’t anyone tell me that the previous blog post was posted as a very-broken comics post
Why didn’t anyone tell me that the previous blog post was posted as a very-broken comics post
I’ve changed my site templates a bit more, to make CWs work a bit better. In particular, now entries which have a CW will also hide the text behind a
<details> on the page (for example), and similarly I’ve hidden CWed images on individual comic pages (for example). Comic images will also (finally!) be blurred in the OpenGraph tags, as well, after one too many “oops"es when posting links to Slack demonstrating how my CWs work.
I’ve also improved compatibility with Bridgy Fed and with the way that webmention microformats are supposed to work in the first place, per a conversation in which I learned that I wasn’t actually using reply types correctly. (You may have noticed a bunch more micro-posts on the chatter section as a result of me fixing this as well. I also need to finally implement a thing so I can properly filter that stuff out of the little "latest posts” box on the main page!)
The sample templates repository has been updated, accordingly.
Edit: It didn’t take me very long to implement the Publ feature change. I went ahead and cleaned up a bunch of query generator code while I was at it.
Also I think I found a bug in PonyORM. Nope, I think I was just being hopelessly optimistic about a thing.
I’m working on improving some of the https-related security in Authl, in particular making it so that if a site is configured with https, then it’ll only send the security cookie over https. This reduces the chances of a certain kind of possible security issue, but it also means that if you normally access the site with
http://beesbuzz.biz instead of
https://beesbuzz.biz it’ll show you as being signed out, and if you click the “log in” link it’ll ask you to sign in again even if you were already signed in.
I have a fix for that in mind, but it might cause a potential redirection loop problem in some cases so I’m not going to implement it until I’ve determined the scope of the problem and figured out if I need further workarounds.
Update: Fix is implemented and being tested on this site. Authl and Publ updates pending other folks trying it out.
So, one of the things with the Isso migration is that I finally came up with a better way of handling thread IDs to keep them actually-private. And part of that is the mechanism to rehash them.
Which is good, because I keep on accidentally leaking the dang secret sauce. The first time was when I updated my sample templates with the comment hash generation (and I accidentally left the HMAC key intact), and the second time was when I started building a new Publ-based website and decided to start with my actual
app.py as the basis, HMAC key and all, never mind that I later ended up removing about 90% of the beesbuzz.biz custom routes and the Authl config since they’re not actually needed for this site. Yeesh.
Anyway, whatever. Someday I’ll learn my lesson (and maybe I’ll even go so far as to make the HMAC key not even be checked into code!), but today is not that day.
As far as I know, all of the comments have been restored and mechanically updated to work correctly. It’s pretty neat that I actually have comments dating back to 2003, that have survived four separate comment systems! (Movable Type, phpBB, Disqus, and now Isso.) And some of the oldest ones hadn’t been visible for years, since I never got around to migrating them over to my comics section before.
I also now have a script to automatically rehash the thread IDs in case the HMAC key leaks, as it did yesterday when I accidentally forgot to redact it from the sample templates repository, oops. I doubt anyone saw that but now it doesn’t matter if they did.
I do want to make a final migration script to try adding thread nesting to comments which quote other comments. I have a good idea of how to do it but it’s gonna be tricky and since Isso apparently uses oldest-to-newest sort on comments I don’t know how useful it’ll be, anyway. But I like doing that sort of thing.
I also have automated backups of my comment database, as well as having it checked into a git repository so I can do simple checkpointing whenever I do something funky with a migration (and it means I can also run the migration on my local machine instead of having to worry about hecking something up in production). And of course since Isso runs as its own systemd unit I can easily take it down while I’m doing a thing. (If you ever notice my comments completely vanishing for a while, that’s probably what happened. Unfortunately there isn’t any easy way to show a reasonable message when that’s what’s going on.)
So, now I feel a lot more confident in the privacy and longevity of my comments. Which is good because I have a lot more private stuff to talk about. 😛
Because my original import from phpBB to Disqus got botched, and the Disqus to Isso import lost a bunch of useful information, I ended up just going back to my old phpBB database and reimporting it directly into Isso. It mostly went well but there’s a few things that I need to go back and fix. This is my TODO list:
<a href>stuff that got converted to
[quote:abcde]so it didn’t get converted to HTML (example)
[quote]s (way easier said than done, I’ll probably have to do that manually)
Also some of my earliest journal comics had comments posted via Movable Type’s comment system rather than phpBB, so I’ll want to also migrate those over (which I never got around to doing back when I was still using Movable Type to run my website); back then I just had “native” MT comments rendered in the MT template, which was Good Enough and I figured I’d get around to fixing it later. Well, it’s later. And that’s done. Even though I’m up way later than I meant to be. Oops.
Oh, and since I set up monsterid for the default avatars I feel like I should try to track down the email addresses of the folks who were posting to Disqus and fill that stuff in wherever possible.
I promise at some point I’ll get back to blogging about stuff other than the website itself.
Okay, instead of trying to modify Isso to support thread IDs that are separate from page URIs, I ended up leveraging the way that Publ request routing works and just made all thread IDs consist of a
/<signature>/<entry_id> path, where
<signature> is computed from an HMAC signature on the entry ID and a secret key. So, now the thread ID is only visible to people who have access to the entry in the first place (as long as my signing key never leaks), and the fact that Isso only uses the thread ID when generating a reply email link isn’t a problem.
So, for example, this entry has an entry ID of 4678, and the generated thread ID is (for example)
/890824f4d450d4ac/4678, so when someone gets a reply notification the email will say something like:
such-and-such <email@example.com> wrote:
Link to comment: http://beesbuzz.biz/890824f4d450d4ac/4678
which will then redirect back here.
It’s not ideal, of course, but it works well enough.
Of course, to do this I had to migrate all of my thread IDs again, but hopefully this is the last time I’ll have to do that, and it also takes care of all my legacy Movable Type-era thread IDs. It does set a bad precedent that I’ll have to migrate thread IDs more in the future if I ever change my publishing system but the fact I was able to get away with not doing that for so long is a pretty good testament to my laziness, which I ended up having to pay interest on in the future anyway. So, lesson learned.
Also, this approach is even better privacy than what I was hoping to get out of the Disqus method; as it stood before, someone on my friends list (or who saw an
Auth: * entry) could have theoretically figured out the way I was determining private thread IDs and used that to explore comments on entries they don’t have access to, and also there was an issue that if I ever took a public entry private, its thread ID would remain the same as when it was public. But this way, it’s unguessable as long as my HMAC key never leaks, and if my HMAC key does leak I can just reset it and regenerate the thread IDs. (Edit from the future: Ha. Haha. Ha hahaha ha haha. Ha.)
This approach is also useful for things other than Publ; my advice to anyone who’s using Isso for comments is that instead of using the actual entry URI as the thread ID, they should have some sort of stable mechanism for forwarding an opaque thread ID to the actual entry, and use that. This just happened to be really easy to implement for Publ since Publ already supports opaque ID chasing.
So, there’s an issue with Isso which will require a bit of refactoring/feature work on Isso, which I’d might as well try to do since I can’t be the only one who needs to decouple their thread IDs from their URLs.
Anyway, this’ll probably mean that I’ll have to redo the comment import at some point, so don’t get too attached to anything you’ve posted so far.
Update: Rather than doing the right thing for now I’ve opted to just use the shortlink as the identifier. This means that future site migrations will be more painful, and also I need to do some more work to migrate in the old comments from older entries, but I guess the idea of a single universal migration path is a bit silly anyway.
So, Disqus has served me pretty well for quickly embedding comments into my website, but there are a few pretty big downsides to it:
I’m going to look into alternative comment systems, ideally ones I can self-host. Isso looks promising, if a bit sparse. So does Schnack. (I’m going to try Isso first because its setup/requirements are far less onerous.)
Anyway, thanks Passerine for bringing the privacy leak issue to my attention. I figured there was probably something like that lurking in the shadows, but I didn’t think it was quite so close to the surface…
David Yates wrote a great defense of RSS which I completely agree with. To summarize the salient points:
(Note that there’s one inaccuracy in that since that article was written, Twitter has moved over to algorithmic manipulation of the timeline. This can currently be disabled but who knows how long that’ll last?)
Most IndieWeb folks are also really gung-ho about mf2 and h-feed, and while I don’t see any reason not to support it (and it certainly does have some advantages in terms of it being easier to integrate into a system that isn’t feed-aware or convenient to set up multiple templates), I’ve run into plenty of pitfalls when it comes to actually adding mf2 markup to my own site (for example, having to deal with ambiguities with nesting stuff and dealing with below-the-fold content, not to mention a lot of confusion over things like
e-content), and so far there doesn’t seem to be any real advantage to doing so since everything that supports h-feed also supports RSS/Atom, as far as I’m aware.
For me the only obvious advantage to h-feed is that you can add it to one-size-fits-none templating systems like Tumblr where you don’t have any control over the provided RSS feed, but in those situations there’s not really a lot more added flexibility you’re going to get by adding h-feed markup anyway. I guess it also makes sense if you’re hand-authoring your static site, but that just means it becomes even easier to get things catastrophically wrong.
I just read this great essay by Matthias Ott. It does a great job of summarizing the state of affairs of blogging and social media, and how we can try to escape the current orbit to get back to where the web was meant to be.
I especially like the bit about “Don’t do it like me. Do it like you.” Because that is exactly why I’ve been building Publ the way I have; I have specific goals in mind for how I manage, maintain, and organize my site, and these goals are very different than what other existing blogging and site-management software has in mind. The fact that I post so many different kinds of content and that they need different organizational structures to make sense makes this a somewhat unique problem. I’d like to think that Publ is a very general piece of web-publishing software, but it’s probably so general because I have such specific needs. Which makes for an interesting paradox, I suppose.
I guess what I’m saying is that I want to see more types of web-based publishing where the schema and layout fit the content, not the other way around. But it also needs to be able to interoperate with other stuff, while still making sense from a producer-consumer UX perspective.
So hey, Publ now has a tagging system, so I’ve updated my site to show tags in a lot of places. I’m not sure if I should make some sort of tag explorer view or if it’s okay to just pivot between tags within a category listing. Insight or ideas would be most welcome.
What I want to do at some point is tag all of my comics with subject matter and characters, but that seems like a lot of work. I wonder if there’s a way to outsource that to other folks which doesn’t involve opening up my git repo to the world. Maybe I’ll build a simple tool which lets people suggest tags for entries which don’t have tags. Iunno.
I’ve updated the Publ-templates-beesbuzz.biz repository, and also made it a lot easier for me to keep it up-to-date.
I also made it easier for me to put in webmention likes and stuff for things. And since this site is configured with fed.brid.gy support, maybe I can reply to Mastodon comments, like this one, which I have also marked as a “like” in this entry.
Anyway, boost it if you want to.
Update: fed.brid.gy continues to not actually behave in a way corresponding with how I expected. Oh well.