Current goings-on

Comments

Still on disability leave, and still in considerable pain. I’m trying not to work too hard on things, but it’s hard not to do things.

For example, I worked on a song with my friends Ken and Huan-Hua for this week’s Song Fight!; we entered the “We Did Everything We Could” fight under the band name Richard Donner Party. It was a fun song to make. Fortunately I didn’t have to even so much as look at a guitar. Most of my work was vocals, light keyboard work, and editing.

Read more…

Private, friends-only, IndieWeb stuff

Comments

Yesterday I participated in the IndieWeb sensitive data pop-up, or at least the first half of it (I had to disappear for my refrigerator delivery). It was really great to have some further discussion about what people want out of this stuff and how we’re all going to agree to get it.

Authentication stuff

One of the biggest pain points that keeps on coming up is there being no support for people to be able to get private posts without having to log in or be notified about them in side channels. Lots of people are doing things like making pages with unguessable URLs and then doing side-channel notification, but that’s unwieldy; fewer folks are doing things with actual login mechanisms.

Read more…

Regular check-in

Comments

I’m personally physically all right, at least for now. The house guest also made it here safely, right before things got really weird.

I gotta say, getting an urgent group text informing my building of an incoming teargas cloud and “Close your windows” is not a thing I thought I’d ever experience first-hand.

Read more…

Stuff and things

Comments

So, some updates of the things that have been going on in my life since the last update, because I’m waiting for my car to get some overdue scheduled maintenance and I forgot to bring my Switch, so why not.

Read more…

New store page

Comments

I finally got around to making a better store page. It’s still not great but it’s better than just linking to either my Threadless or Storenvy or whatever, and I’ll be able to backfill a bunch more of my items into it eventually.

There’s a lot of stuff I’d like to change of course, but this at least gives me a hook to setting up my own PayPal/Stripe/etc. cart as well.

Anyway I’m glad that Publ is in a state where it’s gotten easier and easier for me to make new sites from scratch with it. And I also released a new version of Publ with some shiny new features.

New job!

Comments

I have accepted a job at maven.io as a full-stack engineer. I’ll be working on web publishing stuff as an actual source of income now!

I am very optimistic about this. Everyone at the interview was super-awesome and friendly, and their ethics seem pretty much aligned with mine. I hope to be part of making curated published content on the web better for everyone! (Readers and publishers alike.)

Read more…

I’m warming up to ActivityPub

Comments

While Publ is still going to be an IndieWeb-first platform (simply because it’s so much easier to integrate – having modular Lego bricks and a pick-and-choose functionality set that is as simple as adding it to one’s HTML templates is a very compelling approach), I’ve had some good discussions regarding ActivityPub lately and it’s starting to seem a bit more possible to add that as an add-on for Publ.

Read more…

Re: Why Publ won’t support magic auth links

Comments

In response to a Publ blog post, Kicks Condor writes:

One question, though—could the Atom feed list rel alternate versions of the feed? (That would have type application/atom+xml?) It also seems like rel self could have the non-authenticated version of the feed. It doesn’t make sense for credentials to be in that URL. These are possibly naive suggestions—apologies, if so. Again, fantastic write-up!

The problem is that it’s up to the sharing news reader to know which URL to use for the sharing, and there’s no way to control what URL the reader happens to use. I know that Feed On Feeds will use the URL for the actual subscription (since that’s the only source URL it tracks in the first place), and who knows what other readers with sharing features will do!

And changing the rel="self" URL has a different problem – some readers (again, such as Feed On Feeds) treat that as the canonical URL and will update their subscriptions to point to that URL instead, so setting rel="self" to the unauthenticated feed means most users will be unable to remain logged in.

Basically, it’s a tricky issue that has no right answer with the Atom spec as it currently exists. So if some other mechanism has to be designed, it might as well be done in a safe, unambiguous way from the beginning. If some other use case for magic auth links comes up I’ll reconsider implementing them, but at least for friends-only subscription access, the privacy risks are simply not worth it.

Proper comment privacy! Yay!

Comments

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 <foo@bar.baz> wrote:

Good point!

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.

Read more…