The hope of Sele is to make it "easy" to deploy. This version is focused on the "community" edition that'll be hosted for general use. I'm already looking to what parts can be shaved down for its underlying libraries that separate attestation and the general IndieAuth endpoints (so any Axum-powered Rust project can drop in IndieAuth support with WebAuthn support by only providing a means of data persistence). This is important for the rewrite of this site (Shock, namely, this is stored into something else) because I'd want to bake in the IndieAuth provider logic from a battle tested implementation.

I'm not sure how to get this into more hands outside of solving some usecases for it. The most immediate would be looking to coax folks using to opt for this service but that could be a lot. I think, instead, I'll keep it quietly humming along and then flip my personal site to use it. And once that's cool for about a few days, I'll start working on Lighthouse to flesh out the social reader system. My site's truly going to be the last thing rebuilt, ha.

Sele's (my IndieAuth service) tracking for beta testing by early February. It won't be ready for general availability though. By then, it should have WebAuthn, email sign in and rel-me provider support with new providers rolling out when I can find time to support them and based on the kind of providers people tend to advertise (though I need to filter it for rel="authn me" for reporting). I'm glad I spent some up front time abstracting the means of attestation. I'd want to add a pre-flight page to do some testing of the inital request so I can do some stuff like checking preferences for a browser or basing it on location (I'd like to opt for WebAuthn on my preferred browsers but since GNOME Web doesn't support it yet, opting for something that could use the prompting solution by pushing a request and approving it from the GNOME desktop).

I could have done this faster in Python but I did like the challenge Rust provided and the amount of compile-time checking reduced the number of tests I'd have to write in a Python (and Node) stack anyhow. Only immediate concern is improving the security of the system. There's a fair amount of logging but no secret values are printed until needed (thanks to typing hiding that). I should look into either encrypting the database using SQLCipher or separating any secret values into an encrypted database and have them be retrieved that way.

I'm curious about syncing my reading progress to places like Open Library. I, like most people, still send it to Goodreads (especially because there's the strong social aspect of it - I've gotten some good recommendations from peers on there) but I know that things like Open Library (and also Bookwyrm, though I'm inclined to use that when I begin making my site more directly compatible with ActivityPub versus this current syndication approach I'm taking now).