<div dir="ltr">I daresay your concerns are completely valid (except that 512 bytes * 2000 users = 1 MB, != 1GB). But they are not new. Passwords that take username/password have issues with one-time visitors creating accounts just to get to some service or content once. OpenID makes that one-time visitor's experience better, which increases the likelihood of getting people creating accounts. That's only bad if you can't retain them. But that's not new either.<div>
<br></div><div>A standard policy web email services employ is "if you don't stop by once in six months, your account is deleted". You could perhaps do the same.<br><br><div class="gmail_quote">On Wed, Sep 3, 2008 at 6:56 PM, SitG Admin <span dir="ltr"><<a href="mailto:sysadmin@shadowsinthegarden.com">sysadmin@shadowsinthegarden.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="Ih2E3d"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I had to chuckle at your dilemma of a server that didn't have space for the OpenIDs.<br>
</blockquote>
<br></div>
Well, it depends on how much space you're allocating for each one. I may be going slightly (*slightly*) nuts here with UTF (foreign URI's) and keeping track of *both* the typed-in ID *and* (leaving room for) the designated ID - half a kilobyte per OpenID.<br>
<br>
Admittedly this isn't much (two thousand users will swallow up a gigabyte), but since I intend to release the source code once it's to a point that this can actually function as a content publishing engine, I've been going nuts (and this time, it ain't "slightly") trying to design it in such a way that it can scale infinitely for users I don't have with hardware I don't have, and also be efficient for independents running their own server on an old Pentium, and be reasonably secure for anyone using a shared host that gives them maybe a gigabyte of space.<br>
<br>
There are other concerns, but you get the idea. My engineer side is struggling to make it "perfect" before release (i.e. even before *I* use it) and if there's a management side, it isn't winning ;)<div class="Ih2E3d">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
"Oh," I can hear all the other webmasters saying, "that I had the problem of too many visitors...!"<br>
</blockquote>
<br></div>
Well, let's plan ahead - if OpenID *does* become popular, how many "anonymous" visitors might you get, people that are just planning to try out the site? It would be nice to detect a user's "anonymous" decision and give them *your* "anonymous" account, saying "Sorry, but we don't give service to anonymous users; you're welcome to try us through *our* anonymity mechanism, though." This would let the user remain accustomed to entering their anonymous ID everywhere as a preventative privacy measure, and the heuristics described previously could still be used to raise a flag about OP's that might possibly be not identifying whether their users were using an anonymous ID.<br>
<br>
Although, if the RP offers services that it's willing to demo and any of those services involve communication or personalized settings (such as might leave users confused by another user's actions), I can see how it would be better to keep users separate. Or indeed ANY demo if the intent is to limit it by time instead of features, i.e. "Try us out for a month and either upgrade to a *real* OpenID by the end of that time or we'll delete your demo account!"<br>
<br>
Another factor might be defunct accounts. How long do you keep around information on users that no longer log in? If their Identity was "anonymous", does this affect your estimates of how likely they are to log in again?<br>
<br>
-Shade<br>
</blockquote></div><br></div></div>