allow people to un-select websites that were discovered

[aaronpk]

From IRC: http://indiewebcamp.com/irc/2016-02-11/line/1455222513863

"after I auth with twitter, show me a list of all the links it finds in my bio and website field, and allow me to un-select individual ones if I want. no typing required, and if peopel do nothing, it behaves as it currently does."

[tantek]

What about if there's a "website" field then it takes precedence over any URLs in the bio?

Thus if you wanted to link to multiple websites you could just put them in the bio field.

Or ONLY IF your bio field includes the site from your website field, then use all the URLs in the bio field.

Something like: if there's a website field { use it for rel-me; if the bio field contains the same site as the website field, then use any other other sites in bio field also } else if there's sites in the bio field, use all of them

[snarfed]

acknowledged! hopefully blacklisting oauth.net and micropub.net made this more tolerable in the short term.

@tantek interesting! bridgy actually does pull sites from both website and bio right now, and prefers website. it doesn't have the logic for when website is also in bio, though.

[snarfed]

background in #282, and to a lesser degree #206 and #107.

[snarfed]

@drikkes re https://github.com/snarfed/bridgy/commit/042a4de7335134a82001cc351e10ddd4d2661d16#commitcomment-28695061 , sorry for the trouble! i plan to add an 'Edit' button soon. feel free to follow this issue.

[snarfed]

turns out this will take a nontrivial amount of work to OAuth-protect with all of the silo OAuth dances, so i probably won't prioritize it after all. @drikkes feel free to send me your bridgy user page, here or private IRC !tell, and i'll remove that post URL from it manually.

[snarfed]

notes to myself: i'd probably do this by adding a generic set of handlers that can oauth-protect any arbitrary bridgy code. something like a new /silo-auth handler that starts the oauth dance for a given user, and a /silo-auth/finish callback that verifies the returned code, then calls through to an internal callback.

i already basically have this for deleting users, and a git stash with a start on abstracting it out. even so, it'd take some work to finish, and it's probably not yet worth it given how little demand there is overall.

[drikkes]

Thanks, @snarfed. You mean this by "user page"? https://brid.gy/facebook/10206219375153745

The URLs should be the same for FB than they are for TW https://brid.gy/twitter/drikkes

[snarfed]

@drikkes thanks, done.

[drikkes]

Thank you, Ryan!

[snarfed]

so this is fully implemented, except for auth. ie if i deployed it, anyone could add or remove domains to any bridgy account. :/ auth is doable, but nontrivial, so it's not hooked up in the UI, and i'm not prioritizing it right now.

[manton]

Just a quick +1 from me too, as I've noticed recently that because I have "Micro.blog" in my Twitter bio, Bridgy sends Webmentions for anything mentioning Micro.blog, which is not really what I want since it's not my blog. 🙂 I like the idea of keeping the default behavior of assuming any domain names in your bio are yours, but with the option to remove them later.

[snarfed]

Some options for auth here:

• Redo the whole silo OAuth dance. Pro: we already to this for interactive publishing and deleting accounts. Con: it's bad UX. It's surprising and confusing to users when they end up on a silo OAuth prompt and it's not obvious why, or what they're authorizing.
• Put the silo token (all parts) in query parameters. Pro: better UX. Con: have to check the token validity server side, may occasionally lead to leaked credentials when people copy and paste URLs.
• Put the token in a cookie. Pro: better UX, less prone to leaks. Con: we'd have to expire it, since we sometimes refresh tokens server side, in the background, during polls. Synchronizing the expiration would be a pain.
• Mint a Bridgy token, put it in a cookie. Pro: this basically creates a full fledged Bridgy login, which would be useful. Con: it'd be a lot of work, securing logins is nontrivial and risky.

Not sure which way I'm leaning yet.

[snarfed]

...and a workaround punt option. Don't do any of the auth ideas. Instead tell people to temporarily remove the site(s) from their Twitter profile, auth with Bridgy, and then add them back.

[snarfed]

@manton in the meantime, I've removed micro.blog from https://brid.gy/twitter/mantonsblog manually.

[snarfed]

I've expanded on the workaround above in the docs.