Aaron Parecki

@aaronraimist I got that too. Can you check if my name is the last one in the list you got?

@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 😄

@sentience Replaced it with an SVG! Thanks! /cc @t @KevinMarks @indiewebcamp

@benwerd I'm really happy you're here too!

Thanks for letting me know! See you soon!

The same thing happened to me when I left Eugene and moved back to Portland

@donutjs_pdx @obensource woo hoo! Maybe next time we can livestream the talks!

@ubiquill We're still using them, and working on some new protocols too! Come to IndieWeb Summit this weekend? http://2016.indieweb.org

@kylewm There's so much I want to reply to, but I only have time for a short reply right now. Short version:

Agreed that we need to better define our "inessential weirdnesses". I suspect they are actually things that developed organically and can be replaced by other less weird things that have the same effect and accomplish the same goal

Homebrew Website Club was originally created to be a less technical-focused place to discuss indieweb things.

An alternate IRC channel isn't a bad idea. Slack does a great job of encouraging splitting different discussion topics into channels and we could do the same. That said, I think rather than splitting off the newcomers into a separate channel, we should split off the jargon/plumbing/implementation discussion into a separate channel.

I think we're at an interesting time for the community right now. It's super important to have these discussions, so thanks for the writeup.

@obensource Cool, I will shoot for 5pm then! I need either a 1/4" or RCA output of the audio.

@obensource What's the plan for tomorrow? I need some time to set up, what time are you getting there?

@calum_ryan Oh that's awesome! They look great!