* Adapting the passwordauth reset code is probably the simplest way to
implement emailauth. That uses a CGI::Session id as the entropy.
+----
+
+So this all seems doable. What I'm unsure about is this: Is emailauth going
+to be sufficiently easier than passwordauth that it will let users
+contribute to wikis who otherwise wouldn't?
+
+Using passwordauth, the user can register by just picking a password, and
+username, and entering email. That's 2 more things that need to be entered,
+but then there is no need to wait for an email link to arrive. Which can
+take a while, or be an unreliable, opaque process for users.
+
+OTOH, maybe some users don't want to have to make up a username and
+password, or pchycologically don't want to register. emailauth would then
+let them contiribute.
+
+I also have a motivation for ikiwiki-hosting/branchable. That needs the
+user to be able to log into the site, create their own wiki, and then log
+into their own wiki. Currently, openid is the only way to do that;
+emailauth would be another way.
+
+Another motivation from ikiwiki-hosting/branchable is that with google
+openid going away, many sites can have only google openids as adminusers, and
+that has to be manually dealt with. But if emailauth is added, those
+adminusers can be converted, perhaps automatically, to use the email
+addresses on record.
+
Thoughts anyone? --[[Joey]]
+
+> I had looked at something like this before, through [[todo/indyauth_support]] - which basically turned out to outsource their own auth to http://intridea.github.io/omniauth/ and http://indiewebcamp.com/RelMeAuth...
+>
+> But it seems to me that your proposal is basic "email opt-in".. the one impact this has on (drupal) sites i know is that spammers use even those forms to send random emails to users. it's weird, but it seems that some bots simply try to shove victim's emails into forms with the spam data as they can and hope for the best... it seems this could be vulnerable as well... - [[anarcat]]