Aaron Parecki

@ungoldman @lyzidiamond is this a euphamism

@chrisbergr Thanks! The screenshots are generated by http://wkhtmltopdf.org wrapped into a small service here: https://github.com/aaronpk/Lithograph

@jeena @veganstraightedge When I launch a new teespring campaign I will make a parallel one that ships out of the EU and it should solve that. The shirts will likely be more than $20 USD though since I'll be doing a smaller minimum order size.

Not that it's your fault, but I think you're starting to confuse the two roles of indieauth.com.

Role 1) indieauth.com is a service that developers can use to handle all the hard work of doing rel-me-auth with specific providers directly. In this case, the application developer has a trust relationship with indieauth.com and users should not be concerned that they're using indieauth.com, from their POV they are just signing in to the website. This is how the indiewebcamp.com wiki uses indieauth.com

Role 2) indieauth.com is a service that users can delegate their domain to. To use indieauth.com this way, the user links to indieauth.com as their `authorization_endpoint` on their domain. In this case, the user has a trust relationship with indieauth.com, and an application discovers the user's auth endpoint by following the rel link on their website. Micropub apps like Quill work this way, where you will only ever see indieauth.com if you have delegated to it yourself.

Does this help clear things up? In situation 2, you'll only ever see indieauth.com if you explicitly set it as your authorization endpoint. You could use indiecert.net or use your own auth server instead. In situation 1, where a developer has chosen to use indieauth.com instead of implementing authentication themselves, you're limited to the options that indieauth.com has implemented. However the idea is that indieauth.com implements a good number of options and in a secure way, making it a better option for developers than implementing PGP/SMS/GitHub/etc themselves.

With that in mind, could you rephrase your request in that context?

Hm, would you want to delegate to the `pgp` one to prevent any other login mechanisms from being used? One of the nice things about indieauth.com showing multiple options is that depending on the device you're logging in on, you might want to choose a different option. For example I usually use GitHub or GPG login when I'm on my main computer, but use Twitter from my phone.

I can definitely see value in wanting to limit the options provided by indieauth.com to a subset of the rel-me links on your site. (Maybe I want Twitter listed on my site, but never want to use it for login.)

What about using the query string to indicate the supported providers?

`https://indieauth.com/auth?providers=github.com,pgp,sms` etc. In that case, indieauth.com could even present them to you in the order given.

Similar to https://github.com/aaronpk/IndieAuth.com/issues/112, if only one is set then it could redirect immediately instead of making you click the button, which would be a better user experience.

Actually my VPSs are on @Linode, I only use @Dreamhost for shared hosting

@timweston I'm a fan of @Dreamhost. Also see http://indiewebcamp.com/web_hosting

@waxpancake Totally not planned I swear 😂 @evanpro

@waxpancake @metaltoad It's hard to see but I'm wearing the grey on black version 😄