[OpenID] Facebook support for OpenID. Where?

[SitG Admin]

>You may not agree with my views, or I may not succeed to
>convince you, but I thing it is unfair for you to suggest that I should not
>express my views here.

That wasn't his suggestion. What grows tiresome about your expression 
of those views is how you try to establish links between your beliefs 
and whatever may be happening at the moment, apparently without 
regard for showing any actual connection. Over time, this creates the 
appearance that you are either so frantic to make us listen, you care 
less about being relevant or valid than repeating the same points 
over and over, or so fanatical about your beliefs that you can't 
understand the different perspectives people here might have - much 
less, adapt your approach to fit into what *they* want, instead of 
just what *you* want (and think others, if intelligent, *should* 
want).

In your original post on this thread you suggested that because this 
is "Facebook", we say good things no matter what they do. If the 
implementation Facebook had taken to OpenID followed your advice, 
would you still be criticizing them? Still be placing (some of) the 
blame for their (alleged) Fail on not doing so? If they had, would 
you be praising them, instead as an example of what everyone else 
*ought* to do?

>Also sites that use user names as logins can easily integrate OpenID.

Usernames usually have a character limit (say, 16 or so), but most 
OpenID's are (much) longer than that; already, this makes OpenID 
integration *very* difficult. How much room will you allocate for 
primary fields in your backend database? If that room has already 
been allocated, and the structure decided on, how drastically will 
the entire datacenter have to be overhauled?

I spent a while worrying over maximum length of URI's (theoretical 
maximum limit of URL's, and this is limited by a combination of 
server at OP, server at RP, and user's browser; probably 4,000+ 
characters!), but eventually decided to store primary keys of a 
hash's length at most; now, hashes *can* collide, but if you get more 
than one result you just retrieve them all and do more exact 
comparisons on the fuller string!

>The problem is for sites that "use" email addresses as Identities, or
>require verified email addresses. Here implementing OpenID in the current
>form is not practical without including email addresses as identifiers.

Poorly-hidden secret of database efficiency: you get *lots faster* 
lookups if you organize by numeric primary keys. Sure, the topology 
on paper will have username or some other field shown as the main 
index, but your *actual* topology doesn't have to match that 
perfectly.

>And to make OpenID truly "universal", we need to somehow include email
>addresses into the scheme of things.

To make OpenID *truly* universal, it would have to be compatible with 
irc:// and all the rest. That might be a good place to focus your 
efforts (and, of course, I have to mention XRI).

-Shade has been advocating for privacy in OpenID for over a year, but 
was never told to get off the privacy soapbox