GWGThe outstanding question is, IndieAuth Token Verification has no auth. OAuth2 Token Introspection requires authentication. Should we or just note we don't.
[fluffy]oh, I also don’t implement any sort of token verification on the token endpoint, I just have it such that like `Authorization: bearer xxxxx` works
[fluffy]I don’t really have any strong opinion about that stuff, I’m only implementing tokens insofar as they’re for allowing private entry access from feed readers and so on
[fluffy]well also I have `_tokens?me=http://foo.bar` to initiate a ticketauth grant flow but that’s a hack and not the intended flow for TicketAuth AIUI
[fluffy]yeah I suppose, I don’t really relish the idea of bringing in a full OAuth server thing when I only care about supporting some very specific IndieAuth-related things.
GWG[fluffy]: I had a GET token verification function already. It took about 30 minutes to change it to a POST and adjust the three parameters I needed.
[fluffy]the primary TicketAuth flow I support is like… someone logs in via IndieAuth, and when the profile discovery sees that there’s a TicketAuth endpoint, it sends the TicketAuth grant.
GWGSo, right now, I'm thinking you POST to the ticket endpoint with the token that authorizing you to get tokens as the token parameter, and resource being what you are looking for.
[fluffy]my assumption for how that’d work is that like, your user profile URL would provide a ticketauth endpoint that communicates with your feed reader in some way, and then when you get the token grant, your feed reader has access to the bearer token, but how that actually works is an implementation detail of the ticketauth endpoint and the feed reader
[fluffy]having a standard mechanism for token storage wouldn’t be a bad thing but I’d worry about a turtles-all-the-way-down issue if retrieving the bearer token requires having an active session, since that sort of defeats the point to having a token for an unattended feed reader 🙂
GWG[fluffy]: That's why I was suggesting that the feed reader gets a scope that allows it to retrieve tokens from the token store the ticket endpoint keeps.
[fluffy]the feed reader I keep on wanting to build would just have its own association between identity URLs and its backing storage, and would provide the TicketAuth endpoint since the only use case I personally have for TicketAuth is feed reading
[fluffy]the feed reader I want to build isn’t going to be based on micropub/microsub, and I was just going to use authl as its login mechanism which means not necessarily requiring IndieAuth for login either. and I have out-of-scope-for-this-discussion reasons for wanting to build it that way.
[fluffy]yeah someday I will get around to writing Subl because I am so sick of dealing with FeedOnFeeds’ limitations and ther’es no way I’m going to hack TicketAuth into that
[fluffy]also some nice things to have would be support for like… autodiscovery of feeds of things that people you read in turn link to, for getting feed suggestions
[fluffy]being able to subscribe to things ‘publicly’ would be neat, like providing a timeline for others to look at and also providing subscription suggestions to others
[fluffy]which is especially good for comics, but also for the notion of making atom itself a distributed social network, which was one of the original goals (and a lot of what indieweb does sort of replicates atom’s social aspects, although in ways that are way more practical)
capjamesg[d]Also, what is the proper way to mark up a list in which there will be two buttons that are enclosed in form elements? Is <div> really the best option? Something feels off about using an <li> / <ul>.
Murray[d]What I would add is that `<button>` may serve just as well, though it's been so long since I've implemented something like this without JS I forgot how accessible button events are outside of forms 😄
Murray[d]I understand that, but in this instance it may fit better. Semantically, I'd argue you're creating buttons, so `<button>` is a better fit. In practice, a form submit event seems to be treated closely enough to a button that I don't think it makes any difference.
Murray[d]Sure, I guess I'd expect a submit event to be sending *user* input. In this case, you're prepopulating input and restricting it, so it's really just a predefined action, ergo `<button>`. **But** I think both are fine from a practical sense 🙂
Murray[d]I suppose I brought up `<button>` to consider the nesting: if you feel that a `<button>` within a `<li>` is fine (which I see no issue with :D), then a `<form>` operating like a `<button>` should also be fine 😊
capjamesg[d]WAVE doesn't have any objection to the markup or accessibility. But I'll have to do a manual test with a screenreader for more info on that.
Murray[d]Yeah, the code structure put me in mind of a to-do list, and those often end up in debates over table versus list structures. Personally, I'd test with a screenreader (and possibly something like a Google Home or Echo device) and see how both options _sound_, then pick whichever best fits the use case 🙂
Murray[d]Of course, tables do have some benefits (and negatives) when it comes to layout as well. For example, that wrapping `<div>` might not be necessary in a table
@Cambridgeport90I wonder what it would be like using @Statiqdev for a personal web site with Indieweb functionality? (that is, Webmention support, likes and comments from various other places showing up near the post, and so on). I might fool around with it if nothing else. (twitter.com/_/status/1436328665080500226)
[tantek]general guidelines for links vs buttons: is it "just" navigation / changing the user's view of the information? hyperlinks are fine for that. is it providing some information from the user to the server (even a single bit of information like a checkbox)? then a form is the proper semantic.
[tantek]re: "I am using forms to trigger an up / down movement in the channel list." <-- that sounds more like navigating a view of information rather than any kind of information submitted by the user.
[tantek]one of the big reasons you want to use links vs forms/buttons properly is that browsers do treat them very differently in the UI, e.g. back buttons
[tantek]when a page is the result of a form submission, when you navigate further, and then use the back button, you may see a warning about the information being re-submitted. that should *only* happen when the user has deliberately submitted some information, and navigating up/down in a list (or sorting a table, or any other kind of view manipulation) should not cause such a warning because it will only confuse the user
[tantek]btw, example of "a single bit of information like a checkbox": agreeing to some terms like a ToS or confirming that you've read some disclosure
[tantek]there are some interesting borderline/hybrid cases of "navigating to a different view", e.g. when you're viewing the history of a wiki page, and click the radio buttons next to two different versions and then click the "Compare versions" button.
[tantek]that could be considered navigating to a specific view of the data, and it also required some deliberate user input to choose which versions to compare.
[tantek]since the navigation / retrieval of that information is read-only, the form uses method GET, which performs a navigation action like a link would, except by adding the various form input name value pairs to the URL, which is added to the user's browser history as a idempotent action so no warning is needed if they go "back" to it
capjamesg[d]I had not considered the submit form again browser feature you mentioned. Which actually makes me think JS would be okay in this case because I could easily change the page to show the reordered channels.
[tantek]I think there's a way to do that that both presents a decent default UI, and is *very* portable (each "topic" page is self-contained in a single file that you can move to any "folder" and have it "just work")
[tantek]though I'm mixed on whether a revision should be displayed as it was when it was the most recent revision, OR if it should be shown with ins/del changes highlighted
[tantek]there's been a lot of bad examples of that unfortunately. fancy displays of revision history without any functionality to selectively revert or any other kind of way to restore old content
[snarfed]I haven't done any deep dives. definitely worth looking again if you do, eg wordpress, notion/roam, etc. but I don't have detailed recommendations
[tantek]I'm more likely to go from desired user feature set -> optimum HTML storage (+ CSS for MVUI) -> potential editing primitives -> proposed additions to Micropub
[tantek]e.g. one "simple" way to markup a single-page storage file of revisions of a page would be an h-feed for the file, and an h-entry for each revision
[tantek]the most recent h-entry would be the first in the file, and its dt-updated would reflect that revision, along with the dt-published reflecting the first revision
capjamesg[d]snarfed Right now I just post from a bookmark on my phone that loads my Micropub web app. Nothing special but the UX is not quite what I would like.
[tantek]in looking at my own edits, it looks like either paragraph (block element) granularity or entire page granularity is sufficient to store and (re)store / (re)generate revisions dynamically via DOM manipulation
[tantek]what you wrote up combined with today's conversation here & in #indieweb and your assertion of combining the sets of requirements for pages & posts 🙂
[snarfed]for evergreen pages + posts, minimal support arguably doesn't require much new functionality, if any. it's more a mindset shift that you could treat some posts as evergreen, and keep them regularly updated and current
[snarfed]eg on my site, the only difference is that pages don't have dates in URLs and don't show up in feeds. and neither of those is strictly necessary.
[snarfed]personally, i'm happy to start by just evangelizing here that evergreen pages/posts are useful, more of us should try them in our existing sites, and we can all prototype them as normal posts that we update over time
[tantek]there's a distinct disadvantage to the 'prototype as normal posts' approach in that as you observed, 'normal posts' typically have their date published in the URL in some form, and as such imply a certain point in time in contradiction to the intended meaning of a "current" or "evergreen" page
[tantek]now, prototyping a *revision* of an evergreen page as a "normal post" could work, since a revision is also strongly tied to a particular date(time)
[snarfed][tantek] oh sure, prototyping implies rough edges. I think visible dates are a small enough rough edge that you can still get the sense of the value
[tantek]For me the more important / urgent aspects are what’s the minimum needed to move things from pbwiki to my own site, even if editing gets a little harder
@TwitterDev Better believe it, OAuth 2.0 is nearly here! We’re releasing OAuth 2.0 into beta on the Twitter API v2, and you're all invited to request access today. Let us know what you think and learn more in the forum post 👇 https://twittercommunity.com/t/announcing-oauth-2-0-beta/159189 (twitter.com/_/status/1436020870875656196)
[snarfed] [checks watch] it's 2021 https://twitter.com/TwitterDev/status/1436020870875656196
[fluffy] well also I have `_tokens?me=http://foo.bar` to initiate a ticketauth grant flow but that’s a hack and not the intended flow for TicketAuth AIUI
capjamesg[d] I'm all set up on Monocle now. Still got a lot of the spec to implement on my server though.
[KevinMarks] Apple defined some extensions to feeds (for podcasts) to distinguish oldest first from newest first, and to label episodic posts
jeremycherfas Sure.
Murray[d] Yeah, the code structure put me in mind of a to-do list, and those often end up in debates over table versus list structures. Personally, I'd test with a screenreader (and possibly something like a Google Home or Echo device) and see how both options _sound_, then pick whichever best fits the use case 🙂
@Cambridgeport90 I wonder what it would be like using @Statiqdev for a personal web site with Indieweb functionality? (that is, Webmention support, likes and comments from various other places showing up near the post, and so on). I might fool around with it if nothing else. (twitter.com/_/status/1436328665080500226)
[tantek] general guidelines for links vs buttons: is it "just" navigation / changing the user's view of the information? hyperlinks are fine for that. is it providing some information from the user to the server (even a single bit of information like a checkbox)? then a form is the proper semantic.
@RubygemsN authorio (0.8.5): Rails engine to add IndieAuth authentication endpoint functionality https://rubygems.org/gems/authorio (twitter.com/_/status/1436458994562781187)