Rambles that are fluffy, by fluffy
Right now I’m sitting bored in a waiting room, so I decided to give CodeAnywhere a shot as a means of editing entries directly on my site, since that’s a use case I’ve mentioned as a possibility for the future.
Here are some of my observations as I run across them while writing this entry.
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.
So, thinking about things more, the “profile URL” scheme doesn’t make sense for pure OAuth endpoints like Twitter, Facebook, etc. I’m thinking the API should provide two discovery mechanisms: one for profile-type (OpenID, IndieAuth/RelMeAuth, Mastodon), and one for SSO-type (OAuth).
I ended up writing a little embed widget to embed webmention responses/reactions into my blog posts. It all happens client-side, but so do Disqus comments so I figure that’s okay.
It only works with webmention.io as the webmention endpoint (although it could be modified to work with any endpoint that speaks the same query API), and I suspect Aaron might end up being a skosh annoyed with how I actually implemented it, but whatever. :)
Anyway, if you find any bugs with it or want to make improvements, for now you can submit an issue against the Publ website repository or you can just, like, comment here or something. Update, 7/9/2019 I have moved this into its own GitHub repository.
So, I’ve started yet another web programming project, a generic authentication wrapper library for Python. Because I need something like this for Publ and just want to do it once.
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.
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.
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.
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.
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:
Offhand I do see two three negatives though:
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.)
