chrisaldrichMy current issue is appearing on 1&1, but I'll try some quick tests with the two other hosts I've got as I think one of them had an issue as well.
aaronpkThe best thing is to use the `error_description` field to give users enough information to find a path to resolve the issue, and encourage clients to display that to users
aaronpkWell since you know you're writing a wordpress plugin, and you know a very common issue is hosts blocking that header, it seems like it'd be helpful to explicitly point that out to users
[tantek]good suggestion [chrisaldrich] - the sooner that a plugin can warn a user about a known / existing problem, the sooner the user can take action, the less time they've wasted, the less they're likely to be upset
Ruxtonlate to the party but, couldn't the indieauth plugin just run a test on activation to see if the headers are working appropriately and warn/provide direction from there?
snarfedKartikPrabhu: yup. better tradeoff though. if bridgy still used the evergreen URLs, *all* twitter profile pictures it had sent would now be dead.
jackjamiesonGWG - Is there a distinction between how micropub and microsub use the authorization headers? I can still post to my site with micropub even though I'm getting an error with Yarns
jackjamiesonAh, interesting. Naive question: Is it feasible for microsub and/or other clients using indieauth to adopt Monocle's approach? The requirement to edit .htaccess seems like a strong barrier for some users
sknebelGWG: I'd add it to the authorization request. at that point, you know a) what's requesting access b) that it wants authorization, not just authentication and c) have full control over the users browser
sknebelbefore you show the confirmation screen, check if it is confirmed that it works for the user. if not, show a (skippable) prompt to run the check. if it succeeds, you can remember that for the future and skip the step automatically
jackjamiesonAs an additional step, I could try adding a notification to Yarns if auth fails. A pretty frustrating error and I don't think I would have figured it out myself, so I'd like to make it high visibility
[grantcodes]Cool, probably going to do it this week, then I am working on completely rebuilding the backend so that may be another change. But I'll let you know
sebselgraphql is cool. would be nice to make a sort of micropub/sub to graphql bridge, which should not be hard, just for the blogpost you can write about it ;)
[grantcodes]sebsel: Yeah what I end up with will hopefully be pretty close to a bridge to microsub with graphql, the really nice thing about it so far is the built in polling and pagination. Makes live loading data really easy (at least with the client I am using)
[cleverdevil]One of these days we should move Together into a different place so people don't assume that I do all the actual work since you *actually* do it all, haha 🙂
[grantcodes]Ha well if if this thing actually works the backend and frontend could probably be split into 2 repos as people could theoretically use just the backend as a graphql server
[grantcodes]Eh I don't really care too much. If anyone is *really* worried about who makes something on GitHub they can looks at the contributers tab or some other stat 😛
[cleverdevil]Also thinking a bit about major "traditional" feed reader apps that will likely want a little more capability around metadata, organization, etc.
@ChangelingMxAll I wanted to do was get my microsub endpoint working. Instead, I’m now pondering transferring my domain to a less annoying hosting platform. I’m also giving serious thought to revisiting http://micro.blog for managing my content. I’m completely exhausted. (twitter.com/_/status/1120799564821409793)
Loqijacky: [eddie] left you a message 1 day, 1 hour ago: I think tags and mentions can both be seen in the silo world as well. It's the same as hashtags and @-mentions