Yesterday at #indieweb summit, someone - I think @aaronpk@twitter.com - mentioned that one of the big differences between IndieWeb initiatives and ActivityPub is that IndieWeb is made up of simple building blocks you can pick and choose while ActivityPub frontloads a lot of complex work.

This is a sentiment I very much agree with and it’s unfortunate that the main reason Mastodon switched from OStatus (which is very IndieWeb-esque) is because it made it slightly less inconvenient to pretend to have private posts. Which aren’t even implemented that well.

I’m hoping that the current push toward AutoAuth and trying to use it as a basis for private webmentions and the obvious next steps of private feeds and private WebSub will change that. I do worry that IndieAuth/AutoAuth are kind of hard to do in piecemeal ways though.

And of course once you get into an integration between auth stuff and content stuff you also need to worry a lot more about content management and how it integrates, as well as this seeming fundamentally incompatible with static site generation.

Follow

@fluffy i've thought a bit about static site integration. best I can come up with is the equivalent of .htaccess or nginx stanzas that get included server-side to enforce. but it's still leaky into things like indexes, unless you're comfortable with metadata (titles, tags, etc.) being exposed.

i *really* want to move to a static site but this is presently holding me back.

@wohali I mean you could use nginx for routing rules and pre-compute every person's view of the content but then you've basically reinvented dynamic publishing the long way around

@wohali like, pushing display/routing logic onto the webserver isn't actually an advantage over running a userspace fcgi/wsgi/php frontend

@fluffy Right, if it's *just* post content, or at the directory level, and coarse grained, it can work. but it can't work for fine grained access and will be super leaky.

@fluffy btw I'm a committer with Dreamwidth, so if you get close with your implementation design, lemme know. I can def. make a case for it.

I honestly thing the LJ/DW model has a lot of things people have completely forgotten about that are actually meaningful in this space. (Not saying you don't know these things, I know you do!)

@wohali Oh absolutely, and the LJ/DW model is... not *exactly* what I'm modeling Publ's after, but it's absolutely a major inspiration.

@wohali that said what I’m focusing on right now is just the auth-and-view side of things rather than providing any real private feed mechanism. I have a very half-baked Atom idea somewhere on my blog but it doesn’t really solve that much and IndieWeb folks are generally more interested in mf2 these days.

@wohali come to think of it, the way I implement it should work out of the box with AutoAuth on the consumer end. So as long as DW implements IndieAuth (which is a very tiny adjustment to OAuth2) and lets people subscribe to atom/rss/mf2 feeds without a syndication account, it shouldn’t be hard to support.

@wohali which is to say, I’d focus on getting Dreamwidth to support an IndieAuth endpoint for outgoing identity. It would only need to support the authentication, rather than authorization, flow (gosh I wish they’d chosen better names for that).

@wohali like support OAuth2 for app stuff and you can add IndieAuth practically for free.

(Wish some of the Mastodon devs would get on-board with this, because IndieAuth for Mastodon identities would be :chefkiss:)

@fluffy I'll look into it. There's an attempt to add Fediverse support that I personally feel is ill-advised and glosses over bad actor vectors / data leakage. It could work, but I think it misses the forest for the trees, so to speak...

@wohali yeah I feel like most of the "fediverse" stuff is just... well, not bad, just... poorly-considered.

@wohali also most of the fediverse stuff (and, to be fair, IndieWeb as well) is oriented towards what I call the “follow” mechanic, as opposed to the “subscribe” mechanic that I feel like DW/LJ are much more closely aligned with.

@fluffy Yeah, that's exactly the objection I have. Well put.

@wohali For what it's worth there's an OpenID to IndieAuth proxy that might simplify the development of IndieAuth for Dreamwidth. (Not that implementing IndieAuth directly should be all that difficult!) github.com/cweiske/indieauth-o

@fluffy Thanks. Hm. Adding yet another service to deploying DW (even just within DW) is a challenge, but at least it's code that could be a starting point. Thanks!

Sign in to participate in the conversation
Octodon

Octodon is a nice general purpose instance. more