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.
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?
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...
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.
[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.
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...
[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.
[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.
[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]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
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
[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.
[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.
[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.
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
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]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
[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
[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.
[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]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.
[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.
[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]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.
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