LoqiThis room is one of several discussion channels for the IndieWeb community, see the channel descriptions for the focus and purpose of each room https://indieweb.org/This_room
[fluffy]So my current thinking on private feeds: user agents need bearer token support. They can get this token through any number of flows, like https://beesbuzz.biz/profile or with Ticket Auth or whatever. This isn’t novel thinking of course.
[fluffy]Oh also a thing I worry about with bearer tokens in general is how to deal with refreshing them. Like I don’t want the bearer tokens to have an indefinite lifetime, and at there are also circumstances where all tokens might need to be refreshed.
[fluffy]For example in Publ all tokens are stateless and just use HMAC-style signing, and if the signing key leaks that means it needs to change and all tokens become invalid.
[fluffy]If I ever get around to building Subl my intention is that a 401 error will cause the feed to get re-fetched without authentication and also set some
[fluffy]Yeah having an abstract token store has advantages over signing (and Authl and Publ both support that) but Publ defaults to using signed tokens because it lets me keep things stateless and database-independent.
[fluffy]And then Aaron wrote up a quick idea for a token grant mechanism which handwaves around the issue of invites/discovery in a way which happens to work very well for Publ. :)
[fluffy]But I should just hecking do it and then hack it into Feed on Feeds like I always do even though I have qualms about how multiuser subscriptions work in that
[fluffy](Subl is designed with this in mind from the beginning of course but all I’ve written on that is a rough schema and some even rougher notes about how to implement it when I have a round tuit available)