web2 Login

[alfl]

> be me
> non-web3 developer
> no wallet extension in my browser
> try out kubelt to get a simple core backend
> feelsGood.jpg
> okay, I'll try web3
> install wallet extention
> want to link to existing core
> wat do?

[maurerbot]

A couple requirements:

1. Web2 login should be "migratable"
2. Cryptography namespaces should remain consistent without cascading effects during migration

General thoughts here are:

• email address kekhash makes up the restricted core address
• migration is converting restricted core to unrestricted core and changing owner to new signer

see discussion #263

[alfl]

1. A user logs in, for example using an email address and password.
2. Kubelt stores this record in our own "users" core.
3. As above, kekhash of email is used to create a core restricted to that user.
4. User requests that we "move" the core to their new wallet.
5. Magic link to migration app sent to email address, link contains nonce.
6. We've now authenticated email and can sign nonce to prove ownership of wallet.
7. We make the old email core "unrestricted".
8. The new wallet core is the parent of the unrestricted core.

Is it possible to traverse these symlinks and rewrite the signers?

Re-linking the data would change the addresses so is a very destructive action.

[maurerbot]

for "2." we don't have a "users core"? Do you mean we bind a restricted a core where the address is a hash of the email address?

[maurerbot]

Could probably skip the magic link. The end user just needs to convert the web2 addressed core to an unrestricted core and add the new wallet account as the new signer owner.

[alfl]

No, I mean that we dogfood cores to store user metadata.

[szkl]

Would it be practical to make a core support multiple addresses and identifiers? So the user can access the core via email login or the wallet(s). Similar to single sign-on.

[billkube]

i think the core should have a primary address that could be resolved via email address or other lookup mechanisms, similar to how dns resolves ip

[billkube]

in the case of email auth, there could be a "hosted authentication" service that generates keys for you and when you prove your email, it grants you access

[maurerbot]

Would it be practical to make a core support multiple addresses and identifiers? So the user can access the core via email login or the wallet(s). Similar to single sign-on.

I don't think this is practical. one address only.

[maurerbot]

in the case of email auth, there could be a "hosted authentication" service that generates keys for you and when you prove your email, it grants you access

too complicated. an email binded core is just a restricted core. as much as possible, finding this core should happen on the client and everything continues as usual. That said, we probably need some gateway for SSO and then moving between cores becomes difficult so this whole thing is not practical even though, theoretically we could make it work.

[billkube]

I think the "email binding" would be at the application level. we can do this without changing the core design afaik

Alice's SSO gateway has core A

Bob uses his email to sign into AliceSSO

Alice creates a new core B with core A assigned as an auth proxy

Bob logs into AliceSSO with email, Alice logs into core B using core A and provides Bob with core B's address and live jwt

[Cosmin-Parvulescu]

How about cloning a core? Is that feasible? Instead of spending the time to link and re-link, just clone it to another restricted core, discard the old one and create anew.

[maurerbot]

Not practical: #278 (reply in thread)

[maurerbot]

On second thought, web2 login could work if you connect your web2 identity to your web3 identity meaning, a restricted core should expose a way for "linking" these two things together and managed in a global space. Global operations like this are commercial features.

[maurerbot]

Working on this now with the 3ID OxAuth and address cores