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

[Yoz Grahame]

On 23 August 2010 02:32, Boroondas Gupte <sllists at boroon.dasgupta.ch> wrote:

> You'd win :-)
> SVC-6212 <http://jira.secondlife.com/browse/SVC-6212> (which also includes
> the 1:many relationship between (1) and (2) Argent suggests below)
>
>
As I commented in that issue, this is something we at the Lab would dearly
love to have. In fact, we did some technical design on a master account
system as part of a project which unfortunately had to be significantly
scaled back. The idea definitely isn't dead, though.

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. Using the email address as a
unique master account ID (and then choosing avatar on login) would probably
be the way to go - once we've managed to move email address out of the
avatar record, which is significant work in itself and not currently on the
roadmap. (However, there are also advantages to making email
unique-per-avatar; the horrible hackiness of the IM<->Email system is a
demonstration of that)


> Which would allow for interesting permission schemes, like allowing
> transfer of products only between avatars of the same account. (This would
> probably have to be a new permission. Allowing transfer of all "no-transfer"
> items between Alts, as SVC-4319<http://jira.secondlife.com/browse/SVC-4319>suggests, would probably upset quite some people.)
>
> But even without that, a 'master account' would make a lot of things
> easier, like one could account verify all Alts at once, see billings for all
> linked agents centrally etc.
>

Yep. But obviously, as well as looking at this as a whole pile of useful
functionality, one has to look at this as a possibly-bigger pile of work.
Especially since most of the value comes from a load of new or overhauled
interfaces and logic rather than merely creating the underlying structure.
(Also, we consider any proposed changes to the permissions system with all
due reluctance, not to mention outright terror.)

In short: it's not a question of if but when and how, especially in relation
to all our other priorities.

-- Yoz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100823/d0f35fad/attachment.htm