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…

Mastodon instance rambling

Comments

Lately most of my social networking has been via Mastodon, which is basically an open source, semi-distributed equivalent to Twitter. When I first joined a few years ago I got an account on the flagship instance, but not much later ended up switching to queer.party. Unfortunately, queer.party has had several scaling issues – similar to a lot of the other small instances – and while it hasn’t gone down entirely, it’s so backlogged that it’s gotten to be pretty much useless.

On Mastodon there’s a general feeling that anyone with a mastodon.social address isn’t savvy because they don’t “get” Mastodon, that the whole point to it is that it’s distributed and you don’t have to be on a single central instance and so on. But the problem is that most of the instances – and there’s quite a lot of them – aren’t run in a way that can be expected to scale over time.

Most instances are maintained as a spare-time thing by someone, but instance management is more and more becoming a full-time job. I am incredibly grateful that Maffsie is willing to run the instance even on that basis, don’t get me wrong! But all the same I’d like to be on an instance where it doesn’t regularly go down or have massive backlogs (7 hours, at present) or random weird federation problems.

The problem with Mastodon in this case is that any Mastodon instance, regardless of the user count (or a user limit), will continue to grow without bounds for as long as it’s being used, and as the ActivityPub network grows, the amount of stuff that every instance needs to keep track of will grow too.

Read more…

Notes from the pain management workshop, week 6 ~THE FINAL~

Comments

I was kind of thinking about skipping this last week because the previous few sessions were feeling not very useful for me, but I ended up going anyway and I’m glad that I did.

Also, I’m not sure if I mentioned this before but if you’re in Seattle, these workshops are available to you whether you’re a Kaiser Permanente member or not! There’s more information about that on their living well classes, including online versions (and they also have additional online resources).

Main topics today:

  • Working with healthcare providers
  • Weight management (ugh, but don’t worry)
  • Looking forward

Read more…

Notes from the pain management workshop, week 5

Comments

Oops, I forgot to post these earlier while the session was fresh in my mind. I’m going to have to work a lot harder to decipher my handwriting this time around.

This was the 5th week. Next week is the last one. I’m kind of glad to see it ending. Sigh.

Topics covered this week:

  • Medications
  • Depression management
  • Physical activity
  • Mind management

Read more…