RFC: Identity

[feynon]

Tiles Identity

Decentralized identifiers (DIDs)

Tiles will be having decentralized identifiers, since its foremost should be used locally that means authn/authz should be also local.

But since Tiles will later support multi-devices, it should be decentralized too, which also then leads to a capability based system.

We have found UCAN to be a mature protocol in this regard and its also future safe regarding delegation, revocation and invocation.

We will be going with a did:key method for local ID.

Persisted cryptographic keypair

DIDs are built over public-key cryptography. In-order to store the keypair we would be using keyring which allows us to lean on OS specific password management, in macos case it will be leveraging macos keychain. Since we will be using delegation in case of multi-device its fine to rely on keychain.

Identities

Tiles user can have multiple identities, the default/root will be local identity, but they could also integrate with Atproto and use atproto identity (did:plc). So we will be having a schema underneath to store multiple identities, and all these identities will be linked with the root identitiy.

Usename/nickname

Since DIDs are not UX friendly we can also link a nickname to the DID to show in UI, like how atproto has a username behind its DID plc.

Storage layer

We will be using sqlite as the underneath DB. This will be used to store identities data and also chats later.. This way we can leverage a battle tested DB which is made for relational use cases. This could also reduce the work when we want to sync chats across devices later with libraries like automerge-repo, cr-sqlite, synql.

There's dialog which will be under our radar for sync DBs.

UX

On the first run of REPL, we will create an account if not made as part of FTUE.

There will be also set of commands under account subcommand like login, logout, create etc.. for account management from repl.

This will be also leveraged in webUI.

Modules

The core implementation of accounts will be in tilekit library which will then be used by tiles cli.

References

• https://keybase.io/blog/keybase-new-key-model
• https://atproto.com/specs/did
• https://semble.so/signup

[madclaws]

@feynon Here's the initial plan for identity implementation (updated in the first comment). We can continue the conversation here on github discussions as leaflet anyway doesnt support comments.

lmk what you think regarding the impl.

[feynon]

LGTM.

1. Was wondering if we should have a sqlite db per user like libSQL/Turso does?
2. Would we able to link multiple identities into one as Keybase had with this implementation?

[madclaws]

LGTM.

1. Was wondering if we should have a sqlite db per user like libSQL/Turso does?
2. Would we able to link multiple identities into one as Keybase had with this implementation?

1. Yes, but there will be only one user right?.
2. Yes, we should be, updated RFC, as we discussed there should be a root ID and sub identities/linked IDs.

[feynon]

1. Yeah one user but they can have multiple profiles/identities like you’ve in browsers.