wrinkles

diff --git a/doc/todo/Separate_OpenIDs_and_usernames.mdwn b/doc/todo/Separate_OpenIDs_and_usernames.mdwn
index ae427d5400959a9493f259aa934d9bcbeed6e330..3fb952f965bccf6259aab99f6d95b88516fc85d4 100644 (file)
--- a/doc/todo/Separate_OpenIDs_and_usernames.mdwn
+++ b/doc/todo/Separate_OpenIDs_and_usernames.mdwn
@@ -13,8 +13,9 @@ A slightly more complex next step would be to request sreg from the provider and
 > implemented as a badly-done wart on the side of their regular login
 > system.
 > 
-> Openid Simple Registration is now used to populate the userdb with the
-> email address for openid users.
+> The openid plugin now attempts to get an email and a username, and stores
+> them in the session database for later use (ie, when the user edits a
+> page).
 > 
 > I am considering displaying the userid or fullname, if available,
 > instead of the munged openid url in recentchanges. It would be nice
@@ -23,7 +24,9 @@ A slightly more complex next step would be to request sreg from the provider and
 > while still keeping the openid of the committer in there too.
 > Perhaps something like this (for git): --[[Joey]] 
 > 
->      Author: Joey Hess <http://joey.kitenet.net/@web>
+>      Author: Joey Hess &lt;http://joey.kitenet.net/@web&gt;
+> 
+> 
 
 Unfortunately I don't speak Perl, so hopefully someone thinks these suggestions are good enough to code up. I've hacked on openid code in Ruby before, so hopefully these changes aren't all that difficult to implement. Even if you don't get any data via sreg, you're no worse off than where you are now, so I don't think there'd need to be much in the way of error/sanity-checking of returned data. If it's null or not available then no big deal, typing in a username is no sweat.
 

diff --git a/doc/todo/avatar.mdwn b/doc/todo/avatar.mdwn
index 4409e7b14061076c799eae285cb140730827ad3b..3a4e64b95243af244e13a850f60607f22b15bf1c 100644 (file)
--- a/doc/todo/avatar.mdwn
+++ b/doc/todo/avatar.mdwn
@@ -15,14 +15,20 @@ included in eg, a comment post via a template. Possibly included in a
 recentchanges page item via that template too?
 
 The avatars are provided by various sites. For email addresses, it uses a
-[gravatar](http://gravatar.com/). For openid,
-[openavatar](http://www.openvatar.com/) could used, but I am not very happy
-with it; probably better to just get the email via SREG (as is done now for
-openid), and use that. For a wiki username, the
+[gravatar](http://gravatar.com/). For a wiki username, the
 user's email address is looked up and the gravatar for that user is
 displayed. (Of course, the user has to have filled in their email address
 on their Preferences page for that to work.)
 
+For openid, openavatar sucked and is now dead. So we need to use an email
+address instead, I guess. Problem is that the email address of a given
+openid is only known when that user is logged in and making a change.
+And we don't want to leak an openid user's email into a page either.
+Hmm. Suppose the gravatar hash could be calculated from the email address
+and embedded instead of the openid?
+
+Or, for openid, could use <http://paulisageek.com/openidavatar>.
+
 An optional second parameter can be included, containing additional
 options to pass in the 
 [gravatar url](http://en.gravatar.com/site/implement/url).