#Loqi[aaronpk] #7926 Microformats markup on spoiler posts is wrong
#aaronpktl;dr Gargron is considering removing the `p-name` class from toots. currently that class breaks CW/spoiler posts.
#aaronpkwith the new implied name rules, `p-name` would never have been added in the first place. it's only because of the old implied name rules that `p-name` was added to the posts to prevent the junk names from appearing.
#skippyI changed my Granary feeds to HTML, and Monocle is still not showing me the original tweets in quoted replies...
#aaronpkskippy: okay that is something that should be fixable... not sure if it's granary or aperture tho. can you open an issue on XRay and paste the HTML that Granary creates for one of those posts?
#skippyhow can i get the Granary-generated HTML, instead of hte Monocle rendering of it?
#aaronpkyou'll have to visit the granary URL in a browser and grab it from there
#Loqi[Aaron Parecki] A change in the Microformats parsing spec from a few months ago reduced the cases where parsers would auto-generate a name property if there wasn't one in the original markup.
Previously, when the name was autogenerated, people ended up having to ad...
#snarfedif you posted other replies w/synd links, it may not have crawled them yet
#aaronpknotice that that's a reply to a particular reply on that issue (I show it in the reply context) but bridgy sent the entire thread as webmentions to that post
#[snarfed]backfeed to github comments is kinda unintentional, so i expect it's losing the synd url fragments and thinking your reply posts are the originals
#aaronpkcan you do me a favor, and check out one part of your current implementation in the token endpoint. in the step where the client sends the authorization code and gets back an access token... what does your code do with the `me` parameter that's sent in that request?
#[manton]Hmm. Looks like I don't do anything with the `me` parameter. I store the original `me` and I think I meant to check that they match, but doesn't look like I do.
#aaronpksigns are pointing to this parameter being completely unnecessary at this step
#aaronpkand if we can drop it from the IndieAuth spec, then IndieAuth is reaaally close to regular OAuth 2
#aaronpkanother question... do you use the `me` parameter in the first authorization GET request for anything?
#[manton]Yes, for the first GET, I do use the `me` to display to the user and if they aren't using a hosted blog, I also check that the `me` matches a verified site on the Micro.blog user's account.
#aaronpkwithout it, I suppose the alternative would be that you provide a list of identities that the user could sign in as: their micro.blog address and their verified site
#[manton]More specifically, I show it to the user when there's a problem, e.g. "You tried to sign in as https://manton.org/ but you're signed in as someone else" or it can't find your site.
#[manton]I guess it's not strictly necessarily, since when I redirect back to `redirect_uri` than that other app should verify that the `me` matches there.
#[manton]Yes, technically uppercase M, lowercase b. But I'm not too picky about it. 🙂
#aaronpkwell the only thing the client checks with the original `me` that was entered is that it's on the same domain. that allows the server to canonicalize the URL like adding https or a trailing slash
#aaronpkso in the first request, the `me` is really more of a suggestion, and what you're doing like showing a warning if they're signed in as someone else is a good thing to do in that case
#Loqi[Aaron Parecki] tl;dr The more I think about it, the more I think this parameter enables a use case that isn't really necessary. The me parameter in the code exchange step specifically allows for a token endpoint to be detached from both the Micropub endpoint and th...
#Loqi[Aaron Parecki] Here's a quick survey of current implementations of token endpoints:
Integrated Micropub/Token/Authorization Endpoints
p3k - verifies the me parameter exists, but does not use it for anything
Wordpress IndieAuth plugin - verifies the me parameter ...
#@patio11My comic book swearing that I occasionally do in tweets was semi-valid liquid templating syntax, but only semi-valid, and so attempting to put them on my blog killed Jekyll. #{I%#)ing computers. (twitter.com/_/status/1015219519147499520)
#Loqi[Sven Knebel] Lot's of things going on here, but I think I figured them all out.
missing avatar
Frank’s site is only served over HTTP, not HTTPS. In <img src="">, that’s fine and only creates a warning in the browser, but in your comment display it is include...
#sknebel(which hasn't shown up in his comments yet, I hope it's only stuck in wordpress moderation queue :D)
[manton] joined the channel
#[manton][cleverdevil] Wondering if Indiepaper should have an option to sign in with IndieAuth and look for a rel="indiepaper" endpoint to use for saving articles.
#[manton]Cool. Just thinking out loud... I think for Micro.blog sharing the token between the normal Micropub endpoint and special Indiepaper endpoint would be okay.
#[cleverdevil]Yeah, that would definitely work for Micro.blog.
#skippyaaronpk: that implies that your Micropub server knows about destinations, rather than Monocle knowing about multiple destinations?
#[manton]Or maybe something with `mp-destination` would be better. I haven't thought it through... Just would be nice to eventually have sign-in and discovery more automatic.
#aaronpkyour micropub endpoint can return a list of other destinations. your site is then responsible for actually making that work
#aaronpkyou first do normal indieauth and get an access token. then you query the micropub endpoint with that access token
#aaronpkI don't really want my list of destinations to be public
#[manton]So I guess if it uses destination, we'd lose a little flexibility in pointing Indiepaper to a completely different posting backend. (Not sure whether that is good or bad. Just walking through it.)
#[cleverdevil]The best thing about this is, technically, I don't need to add IndieAuth on my end to make this work 🙂
#[cleverdevil]If I added the ability for auto-configuration in the macOS app with a link like this, then [manton] could simply generate a link directly from within Micro.blog.
#aaronpkyou can also keep that existing form where someone can paste in the micropub URL and token, then you can generate that link they can click to configure the app
#[manton]Yeah, seems good for Mac users. I think having IndieAuth might still be nice so that someone could start at indiepaper.io, click sign in, etc.
#Loqi[cleverdevil] #1 Automate configuration of mp-destination and token
jackjamieson joined the channel
#[cleverdevil]I am just trying to think of a use case where it'd actually be necessary.
#[manton]I guess if someone wanted to use the JS bookmarklet?
#aaronpkconfiguring for an aperture channel would work that way
#aaronpkunless I explicitly add support for this particular app
#[cleverdevil]I still don't *completely* understand what it'd look like. Would the user sign in with their regular domain or with the aperture channel?
#aaronpki'm more inclined to not hard-code things like specific apps, so enabling indieauth on aperture channels bridges that in a standard way
#aaronpkthey'd type in aperture.p3k.io into the sign-in box, then on the authorization screen they'd see a list of their channels and they'd be able to select one
#[manton]Yeah, that seems like it would be the most flexible, so that Indiepaper could work with servers that weren't really designed for it.
#[cleverdevil]I like how indiepaper.io is totally stateless at the moment. It stores zero information, so the IndieAuth exchange would only be used to generate bookmarklets and macOS configuration links.
#[manton]Yeah, that is less appealing to me for Micro.blog, then. Because I don't want to prompt the user for a "channel" whenever they sign in to any IndieAuth app.
#[cleverdevil]The macOS auto-config via URL thing is pretty easy to do.
#aaronpkwait is there a "read later" thing in micro.blog?
#[manton][cleverdevil] Right, sorry to create more work for you. 🙂
#[cleverdevil][manton] no, its all good, it helps me evolve Indiepaper :)\
#aaronpki'm confused about what [manton] is suggesting adding support for to micro.blog
#[cleverdevil]I knew I was going to need to do *something*, I just wasn't sure *what* yet.
#[manton][aaronpk] Not yet, but I was thinking I would experiment with it specifically using Indiepaper.
#[manton]Basically I was thinking I'd add a special Micropub endpoint for Indiepaper. But then that led to these other questions about what the user experience is like.
#aaronpkoh interesting. so you would be adding a new timeline along with the main timeline, mentions, favorites?
#[manton]Maybe. Or maybe for now it's just a special feed that you could subscribe to in another reader.
#[manton]So, backing up a little... If I supported that, I'm still confused about how IndieAuth in Indiepaper would figure out where to save each article.
#[cleverdevil]For your use case, I wouldn't bother with IndieAuth.
#[cleverdevil]You already know the user's endpoint and bearer token.
#aaronpkyeah if you're going to shortcut things at all like not making a web view for it, I would also just take the shortcut of hard-coding the indiepaper app configuration URL in the settings screen
#[cleverdevil]You could just give people a bookmarklet and macOS configuration URL directly in the Micro.blog website.
#[manton]Right. I'm thinking of the case of where someone goes to indiepaper.io and then sees the field for "Bearer Token" and thinks... Huh, what now?
#[cleverdevil]I'd happily add a little section to the Indiepaper website that linked to the appropriate settings page in Micro.blog.
#aaronpkif you wanted to support it the same way aperture (will) support it, you'd add something to the micro.blog authorization screen that lets people choose that they want the app they're logging in to to post to their "read later" feed instead of their micro.blog account
#[manton]It's also possible that I have IndieAuth on the brain and I'm looking for how it can solve all problems. 🙂
#aaronpkwe could also make a specific indieauth "scope" for this so that the client can specifically request it
#aaronpkactually yeah that's probably the best way
#[manton]Because yeah, what I want to avoid is if someone signs in to e.g. IndieBookClub, they shouldn't get prompted to put that into a read later queue, necessarily. (Or Quill, or whatever.)
#[manton]So, just so I'm clear, if we used scope, I would essentially tie the token to that specific scope, so that when the token came in I would know to route posts to a special place? So no separate Micropub endpoint URL.
#aaronpkthat works well in this case because you always want a particular app to have *all* the things it sends to the micropub endpoint to go to either one place or the other
#[cleverdevil]Definitely record the requests as issues on Indiepaper on GitHub if you come up with an ideal solution.
#[manton]What happens with most IndieAuth providers right now if they get a scope=readlater that they don't understand? Or do most ignore it?
#aaronpkyeah they'll ignore the scope they don't recognize
#aaronpk(unrelated, is there a jsonfeed for the micro.blog discover timeline?)
#[eddie]Yep. You can log into micro.blog and turn off replies to people you don't follow if you want to get rid of a lot of those 🙂
#[manton]I could see both ways. "readlater" has a certain well-understood meaning. I don't feel strongly about it, though.
#aaronpk"readlater" also has a very specific meaning and is frankly kind of puzzling unless you're familiar with that app
#[manton]Also, glad you find the Discover feed useful!
#[eddie]That's true. I feel safe about "Save" because Facebook has had that in a post action menu for awhile.
#aaronpkI don't actually use those services myself and would probably avoid a feature named after it
#aaronpkbut I can see other ways I would use this "save" feature
#[eddie]Yep. That's one reason I loved Pocket's approach, was they tried to differentiate themselves by being something you could save any web content into for later consumption
iasai and snarfed joined the channel
#tantek__there's some prior discussion / analysis of save vs readlater etc on the /webactions page
#[schmarty]there are some supporter-only podcast episodes on dr.ip, but dr.ip doesn't actually provide podcast feeds. i wrote a little script to manually create a feed for myself, but having an indiepaper-like "listen later" would be great. like a personal huffduffer.
#aaronpki'm gonna have to add a podcast RSS feed export option to aperture channels aren't I :)
#[schmarty]similarly, i get frustrated at having Watch Later lists on multiple services and feel like there aren't many ways to queue up youtube or vimeo (or other) videos for watching later.
#[schmarty]aaronpk: that sounds like a fun standalone microsub client bridge??
#[schmarty]that example is server-side with nodejs+express. that wrapper creates the various handlers for starting auth and handling the return callback.
#[cleverdevil]Awesome. I just want it to handle the IndieAuth part and provide me a token, and then I can generate a bookmarklet and macOS configuration URL.
#[cleverdevil]Hmm, this seems like server-side JS, not client-side.
snarfed joined the channel
#[schmarty][cleverdevil]: re server-vs-client yep, see above. however, the micropub-helper lib it relies on does support client side, assuming you don't run into CORS issue.
#aaronpkyeah the trick with client-side only is most ppls sites don't support the CORS headers needed to do discovery and such
#[schmarty]i think of it as using the server as a proxy for the CORS things, mostly. plus handling the callback in client side feels weird and like it should basically use OAuth2 Implicit Grant at that point.
#[schmarty]that's one area where my OAuth2 understanding gets a little muddy without examples.
#aaronpktl;dr you probably don't want the implicit flow, just use the regular authorization code flow with no secret
#[schmarty]rad. i had a lot of Thoughts about in-browser apps when i first learned about IndieWeb and was surprised to see almost no one doing it that way.
#[schmarty]still has lot of Thoughts about purely in-browser Micropub apps, but would probably include a fallback proxy mode for CORS workarounds.
#LoqiIt looks like we don't have a page for "organizations" yet. Would you like to create it? (Or just say "organizations is ____", a sentence describing the term)
#snarfedcloudflare workers are really cool, but running code on a CDN edge solves a problem i don't really have, and it'smissing most important parts of a dev ecosystem (storage, logging, local stack, etc) that i actually do care about