GWGgRegor: Does the ticketing for IndieAuth extension as I tried to rewrite it a bit for clarity make sense? I know I had some comments in that area from angelo and capjamesg and tried to do a little work, more to do though
Loqi🧰 Specifications (or standards) are technical documentation for communicating between two or more implementations in an interoperable way; for the indieweb in particular, standards help reach greater levels of user functionality to publish, express meaning, notify, subscribe, and many other user actions https://indieweb.org/standards
omz13aaronpk if it helps, consider that the people (or tools) are actors playing rôles; so think persona not person; it is also a draft so some of the text might not be 100% correct
[tantek]unless we're talking about butlers and personal assistants that you can verbally ask to "take a memo", I'm not sure it's helpful to personify tools into roles like that
omz13[tantek] there are various actors (Alice, Bob, Carol, etc) who may be people or tools or tools doing things like impersonation or on-behalf-of people or other tools. Confusing, perhaps, but rôle-based (and not unknown, q.v. RBAC)
ZegnatI think the idea is that “Martijn parses Tantek to discover a webmention endpoint” makes less sense than say “Martijn’s blog engine parses the link to Tantek’s website to discover a webmention endpoint.”
ZegnatWhere it makes sense to use people to make examples easier to read, it is often also fine to use example placeholder tech (e.g. blog engine and website).
[tantek]Zegnat++ agreed. We should not be conflating people who we are centering in terms of choice & agency, and machines who we are NOT centering that way and the focus is doing precise tasks accurately & predictably.
[tantek]IMO it's both confusing and in general undesirable and unnecessary. E.g. The OAuth model grants certain "access" to OAuth client apps and nowhere in any explanations of those OAuth flows did they ever have to pretend that a client app was a "person"
omz13I am really regretting getting involved in this. Impersonation is a well established concept. Similarly on-behalf-of. Some actions are done by people, Some actions are done by tools.
omz13GWG the "single aspect" of the original TicketAuth proposal never made much sense: being diplomatic, it read to me as if half the story was missing. Adding in ticket wanted is the missing element, and that's what I've implemented; mine is not a "different solution" but a complete one because I considered all aspects and solved them together rather than approaching in tranches and hoping it all works out in the end.
LoqiAutoAuth is the working title of an extension to IndieAuth that allows clients to authorize to other servers in the name of their user, without the user being present to confirm each individual authorization flow https://indieweb.org/AutoAuth
ZegnatThe problem with AutoAuth was probably that sknebel and I did it for an IWC and had a lot of fun implementing. But we have very weak usecases ourselves. So it sorta stopped there.
omz13I tend to think in terms of first have some use cases, which then tends to thinking about what data needs to be moved around, then how to move that data around, then throw a POC together, update cases/thinking, rinse/repeat, produce a specification based on something that actually works.
omz13GWG but I am being "subversive" and want things to happen in-band: what is the point of forcing a person to authorize between parties when they have already given those parties authorization? One less thing for the person to do makes the user experience far smoother (especially as there are trust guarantees included)
aaronpki tried reading the ticketing use cases again omz13 but i'm sorry I can't make it through it trying to jump through all the mental hoops of figuring out which people are impersonating which tools and such
[schmarty]aaronpk: i am gonna look at doing a pass on https://indieweb.org/Microsub-spec#Indicating_Item_Source_Proposal for Aperture. `timeline` responses already include a `_source` that is only a string (the `_id`). i'll make it an object with `_id`, `url`, and `name` - i don't think Aperture has a handle on source per photo right now. any concerns so far?
Loqi 🧰 Specifications (or standards) are technical documentation for communicating between two or more implementations in an interoperable way; for the indieweb in particular, standards help reach greater levels of user functionality to publish, express meaning, notify, subscribe, and many other user actions https://indieweb.org/standards
omz13 GWG the "single aspect" of the original TicketAuth proposal never made much sense: being diplomatic, it read to me as if half the story was missing. Adding in ticket wanted is the missing element, and that's what I've implemented; mine is not a "different solution" but a complete one because I considered all aspects and solved them together rather than approaching in tranches and hoping it all works out in the end.
[schmarty] aaronpk: i am gonna look at doing a pass on https://indieweb.org/Microsub-spec#Indicating_Item_Source_Proposal for Aperture. `timeline` responses already include a `_source` that is only a string (the `_id`). i'll make it an object with `_id`, `url`, and `name` - i don't think Aperture has a handle on source per photo right now. any concerns so far?