busybee fluffy rambles

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.)