Medical terminology for trans healthcare

Comments

I am finally enrolled in Kaiser Permanente’s transgender healthcare program. (Why I didn’t get enrolled when I first signed up for it is a mystery, but whatever.) Today I finally received my insurance form for submitting reimbursement claims for my hair removal.

It gave me a diagnostic code of F649 with an explanation of “Uncomfortable with one’s gender.”

This is… not great phrasing.

Read more…

Reprogramming my sleep cycle

Comments

So because I’m starting the new job next week I figured it was time to get myself back on a compatible sleep schedule. In the past I’ve always done this by taking a dose of melatonin before bed to ease myself into going to bed early, and then try to continue to go to bed at a regular time every night. That usually works for about three days.

What I’m doing this time is attacking it from the other end: I have set my smart bed and Apple Watch to both wake me up at 8:00 every morning, both only on weekdays. The smart bed’s alarm comes through my phone (which charges on my nightstand) and happens during a shallow sleep phase during the half hour or so before the actual alarm time. This usually wakes me up effectively.

The Apple Watch charger, however, lives on the bookshelf across the room, and the Nightstand Mode alarm turns out to be the right combination of pleasant enough to not be jarring and annoying enough to get me up to turn it off.

Read more…

So what is Subl, anyway?

Comments

So I’ve been talking about distributed social stuff a lot lately, especially Publ (my publishing engine, which runs this site, in case you are new here), and also ecosystem stuff for things like private entries and other things that have been pinging around in my head for a while.

A thing I keep on mentioning is Subl, but generally only talking about it tangentially without actually going into detail with what it even is. So, I guess I should talk about that at some point.

Read more…

The authenticated Atom musings continue

Comments

Now that I’ve had a chance to think about this more than what was afforded by a quick response fired off between songs at a karaoke bar, I feel like expanding more on the details that I’d only implied (and probably badly) from the previous post. So, here’s how I think things could look.

Read more…

Some more on authenticated Atom

Comments

Oh hey, I got my first actual reply in WebMention form, from the wonderful Aaron Parecki, who responded to today’s design doc with some pretty good points:

I think my main concern, which you sort of hinted at, is that the feed will essentially leak info about how many followers someone has, as well as this potentially including a lot of data as someone’s followers grow to the hundreds.

Yeah, those are very good concerns and I’m definitely worried about all of those things. My expectation is that friends-only entries would be only going to a small, fairly select group and certainly not to all followers, but I admit I only had my specific use cases in mind when I wrote it.

Have you seen the work going on around making IndieAuth work in a server-to-server environment without user interaction? The idea with that is to let a feed reader fetch a private feed on behalf of a user. indieweb.org/AutoAuth

I actually hadn’t but I’m not surprised that’s being worked on. I actually do really like that idea in general combined with the authenticated feeds approach since it satisfies a pretty good set of positives:

  • Auth exchange is trivial for the user
  • It needs specific support by the feed reader, meaning that can also be an opportunity to add private-entry metadata that is to be abided by (reblog control etc)
  • It doesn’t leak any data at all as far as I can tell

Offhand I do see two three negatives though:

  • No subscription sharing (which is admittedly a very minor concern)
  • I don’t see how that would work with WebSub immediately (which is a more major issue)
  • EDIT: No static publishing either

I could see a way of supporting WebSub by having private entries cause a “check your auth feed” notification to all subscribers, which does leak the fact there’s private activity (and would cause extraneous notifications) but I don’t think it would actually leak any useful data that way (aside from someone being able to gather analytics on someone else’s private entry count). And come to think of it, that could work for the normal auth feed case.

This is definitely what I’ll keep my eye on going forward since I like its mix of characteristics and it means I can already move forward on how I’d implement it in Publ without having to wait for the spec to get formalized. (In the interim I’d probably go with the same old hybrid form I did with the placeholder entries though.)

Also I do have a slight issue with the current implementations of IndieAuth, or at least with the brokers I’ve seen: they require people to set up a profile page, rather than letting people directly use their auth identity (e.g. their GitHub or Twitter). It’s not a huge issue but it does present a barrier for people who aren’t already tech savvy and immersed in this world — but I hope that’s something that can change over time. (I also suspect it’s simply an oversight in the brokers I’ve looked at.)

Anyway. The multicast crypto approach was inspired by DVDCSS/AACS/SiriusXM/Dish/etc. which all work in that way at an absolutely gigantic scale, but their delivery infrastructure and rewuirements make it much more sensible for their respective situations. This probably doesn’t map so well to blogging, and it definitely doesn’t map well to microblogging. I was pleased mostly to have come up with a key exchange protocol for a seemingly least-bad crypto solution, but it seems like the crypto part has too many downsides.

Anyway, thanks for the feedback! I think I see a much better path forward.

(Also I thought I should mention I composed this entry on my iPhone over an ssh connection using vi. Inhave really got to get a better editor working. CodeAnywhere couldn’t connect to my server for some reason though. Oh well.)

Federated access control with Atom and WebSub

Comments

I’ve been ranting about ActivityPub vs. RSS/Atom a lot lately, and I think I’ve proven to myself (and maybe a few others) that for fully-public content feeds, Atom (combined with WebSub and WebMention) is superior to ActivityPub; it’s simpler to implement, works with many more hosting environments and configurations, it generally scales better (and handles scaling failures better), and it’s modular and allows for much eaiser migrations between hosting setups and so on.

But one thing ActivityPub supports which Atom does not is the notion of private content. The way it does support this is a bit hamfisted (in that ActivityPub publishers choose to only push content to endpoints which have a trusted user, and endpoints only forward that content over to the trusted users, albeit in a not-very-trustable way). It doesn’t inherently support the ability to backfill older content (or make it otherwise browseable) to someone who is granted friends-only access after-the-fact, though, and it has many scaling and security implications in how this works (since it requires push to be reliable and requires the recipient’s storage of said push notifications to also be reliable).

I’ve put a lot of thought into how to add friends-only stuff to Atom on and off over the years; my previous blog (which used Movable Type for publishing and phpBB for comments) actually had an ad-hoc implementation which worked sort of okay; people could authenticate with my site’s forum, and people in a trusted friend group would see private content. On the public feed, if their reader were logged into the forum (via cookie sharing etc.) it would see the private content in the feed, otherwise it would see placeholders saying “THis is a friends-only entry, please visit the site to read it.” It worked okay but it was never great.

Anyway, I think I have finally come up with an auth approach that works with Atom and offers a… well, least-bad solution all around, which scales better and more reliably than ActivityPub while working with WebSub and existing/legacy feed readers.

Read more…

Some WebSub-Atom observations

Comments

As part of testing my WebSub changes for FoF, I decided to switch to a WebSub hub for myself that provides some subscriber analytics and so on. One neat thing about how WebSub works is that the “hub” layer is completely modular and it really doesn’t matter at all which one you use, and if the one you use has problems you can switch to another one just by changing the URL in your feed and all subscribers will eventually seamlessly migrate (at their next normal polling interval); if anyone even notices a problem it will just be that they don’t receive a push update during that polling interval. (Which, let’s be honest, is incredibly unlikely for most RSS feeds.)

Anyway, because of these new analytics, as well as information I gathered from my new WebSub-supporting reader, I now know a bit more about the state of WebSub.

Update: A lot more supporting readers have shown up in my stats in the two years since I published this article! Please see this entry for a list.

Read more…

Implementing WebSub

Comments

So, I keep on talking about how Atom is a better idea overall than ActivityPub (due to scaling, fragility or lack thereof, and a bunch of other reasons), and how WebSub adds the much-requested push notification stuff to it, because apparently push is the only thing a lot of engineers talk about.

While this site has supported WebSub for a while, I kept on putting off actually implementing a client because I wanted to make that part of Subl.

Well, today I decided, screw it, I’m adding WebSub support to FeedOnFeeds. It seems to be code-complete, but I have yet to actually verify that it’s working. So this is a test entry to hopefully verify that.

EDIT: It works!!! Now to merge it into master and issue a PR…

New job!

Comments

Two years ago when I decided to go indie I had a few motivations behind it. Part of it was that I needed to work on my own thing for a while, but most of it was just that I needed to get the heck out of the tech industry; everything in that industry is so toxic and based around everyone being “passionate” about doing everything for a company with an incredibly asymmetric relationship. I was working myself to death (often literally) and putting myself deeper into intractible chronic pain, which never felt like it was enough and employers kept on demanding more and more, while being less interested in my own physical and mental health.

So I went indie, because I had a bunch of projects I wanted to work on, such as Publ and my games. And I thought I’d be able to make a little niche for myself making music for other peoples' games as well.

Well, it turns out that I’m my own worst boss. When I’m working on my own projects I get just as passionate, obsessed, and self-injurious as ever, and I also managed to burn myself out on all that. And when it came to working for others, well, I had a hard time finding people I wanted to work with who would be able to give me anything approaching a steady income. I was also feeling impostor syndrome like crazy, like what right do I have to be trying to do this when I (feel like I) can’t even get everything done?

Read more…