[opensource-dev] separation between login id and publicly visible id(s) (was: display names = the end of 1.x viewers?)

Ricky kf6kjg at gmail.com
Mon Aug 23 16:16:37 PDT 2010

And a further note: Be sure to handle the "+" (plus) character in emails.  Gmail
(and possibly other systems) allows you to concatenate a + and some
character string to the account name portion of the email address.
This would allow me to have myemail+alt1 at gmail.com, etc. allowing me
to only need a single email account, but have as many "unique"
addresses as I need for a given task.

I've had too much trouble with websites and programs accepting an
email address with a +, but choking on it after account creation...

Cron Stardust

On Mon, Aug 23, 2010 at 1:51 PM, Lance Corrimal
<Lance.Corrimal at eregion.de> wrote:
> Am Monday 23 August 2010 schrieb Yoz Grahame:
>> On 23 August 2010 11:51, Joel Foner <joel.foner at gmail.com> wrote:
>> >  As Josh and others have said, one of the things we'd need is a
>> >  unique
>> >
>> >> secret account identifier. Unfortunately the only existing
>> >> account datum which might work here is email address, and
>> >> that's not unique, though we're starting to think that it
>> >> really should be
>> >
>> > Just a quick note... email addresses change fairly regularly.
>> > Basing the permanent unique account identifier on a transient
>> > token seems bound to create problems in the longer term due to
>> > user movements from one email address to another, and old
>> > addresses become invalid and even forgotten by users.
>> Many other services seem to manage it just fine. But this is the
>> kind of devil in the details that makes it require some more
>> thought. I'm sure we'd have some kind of internal account ID (in a
>> similar vein to agent ID) to which everything's tied, so that
>> email changes would have minimal administrative update cost, and
>> we'd keep a history of all such changes. That's *if* this is the
>> route we take, if and when we do this work.
>> -- Yoz
> one additional field in the avatar's data... "parent UUID"... the main
> avi would have NULL_KEY in there, alts would have the UUID of the
> "master account".
> users would always log in with the login account, and after you log in
> but before you actually connect to the grid you'd get a popup with a
> list of your avatars to select from, and a button for "create new
> avatar".
> During rollout each avatar would be set up as a master avatar (parent
> avi = NULL_KEY), and on the website you could link your alts to your
> main account IF YOU SO DESIRE.
> This relation would/should not be visible for anyone else but the
> avatars in question, of course.
> each avatar could have a separate email address configured for IM to
> email, changeable in preferences and the website. newsletters and the
> likes would _only_ be delivered to "master accounts"... I believe that
> would cut the sheer volume of email traffic coming out of the lab down
> to 30% if not less (not counting IM to email).
> This relation would/should not be visible for anyone else but the
> avatars in question, of course.
> it would also open a way towards shared inventories (which might
> actually require an additional boolean in every asset... a permission
> bit that a creator could set, "allow to share with your alts" or
> such). it would also allow xstreet purchases to be delivered to your
> alt (making freebies pseudo-giftable).
> bye,
> LC
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges

More information about the opensource-dev mailing list