#jackylike implementation on the server or client?
#jackyfor the server, I figure it's similar to what aaronpk mentioned there (just swapping out the scope) and for me, adjusting the `post_status` field
#GWGjacky: Does draft mean you can only create drafts? Update them? Delete them?
#jackythat seems to be already answered in the beginning, no? (only CRUD-y actions for drafts)
#jackyif we had concepts of actions in scopes then I think this would be a bit easier
#jackylike if `draft` meant really anything to do with drafts but giving `draft:read` would be "you can only read draft posts"
#jackycombining it with the `read draft` flow makes it more confusing and (tbh!) less specific
#[schmarty]jacky: i've been thinking it would be nice if an auth server (or whoever was providing the consent screen) could get ask the actual services expecting to consume that token what details to show to the user
#[schmarty]yeah, or whether they understand it at all.
#[schmarty](or even translated or expanded lists of things the user could opt into/out of! it blows up fast.)
#[schmarty]one problem is that a client will not tell the auth server what endpoints they intend to use the token with afterwards. so the auth server would have to discovery for each type of endpoint it is expected to protect.
#jackyhm those could be hinted by the kind of scopes they'd use, no?
#jackylike if they need a media endpoint, they'd have to send `media`
jamietanna and treora joined the channel
#jamietannahaha jacky those, and the removal of padding, are the little gotchas I faced at the time I was doing my IndieAuth PKCE - definitely things we would need in a test suite (and maybe even to clarify / with more examples on the spec?)
#GWGI am asking because I didn't think about it until jamietanna mentioned it in implementation
#jamietanna> what endpoints they intend to use the token with afterwards
#jackyI _think_ we can squeeze that on the wiki and if someone else comes along with an issue then bump it to the spec
#jackyhm the wiki doesn't mention it (which makes sense - the spec is canonical)
kitt joined the channel
#jamietannaI think the issue then is there are _tonnes_ of combinatory scopes to support and manage
#jamietannaI'd prefer, at least in terms of `draft` for it to be quite sweeping across everything that's authorized
#jamietannaIf we went combinatory, we'd then want i.e. `update:media` or `update:post` right? Then the clients have to know which of the many scope options to request