Before you can start using Space and Time, you have to authenticate to the network. We provide three different ways to auth, so you can access SxT in a way that's familiar to you:

• Web3 ED25519 keypair auth
• Web3 Ethereum wallet auth
• Web2 username/password auth

Why our solution?

The main benefit of a decentralized system is also the crux of the authentication problem - since the system must be trustless, secrets cannot exist inside the system. Luckily, this problem has long since been solved - enter public key cryptography. In public key cryptography, each identity (i.e., SxT user in our case) has a key pair - public and private. The private key is kept private, and identities encrypt their outgoing messages with their private key, producing a signature that is sent in addition to the message. The public key is shared with all other identities in the network, and other identities use this public key to decrypt the signature and check if it matches the original message. If this is successful, other identities have a strong proof that the message was indeed sent by the actual identity who owns the public key.

Most (if not all) blockchains today use public key cryptography for authentication - each wallet has a private key and a public address (which is basically the public key).

What's the difference?

So, if a decentralized system like Space and Time needs public key cryptography, why are there three different ways to authenticate? The truth is that there's only one way to authenticate, just different methods to reach the same result. For example, both Ethereum wallet and ED25519 implement public key cryptography, they just use a different algorithm to generate keys and encrypt/decrypt messages. When you authenticate with username/password, the Secrets Proxy is actually handling the authentication request. As a custodial secrets manager that lives outside the platform, it ultimately just generates and uses an ED25519 keypair to authenticate with the platform on your behalf (translating from username/password to public/private key).

When to use each method

So, why three different methods if they're all practically doing the same thing? Well, each method lends itself best to a specific use case. For example, if you're logging into our dapp, it might feel a bit clunky (if not outright insecure) to have to paste both your ED25519 private key and public key into your browser to authenticate (perhaps even worse if you had to request a challenge and have some code you wrote generate a signature and then have to paste that into the browser). In another example, you wouldn't want to export your Ethereum wallet private key and store it in any application you built on top of SxT. Lastly, you might not even want to think about public/private keys and would rather just interact with a very familiar username/password solution. For these reasons, we've implemented the three different methods for authentication. The great news is that you're not limited to one - it's easy to add a new public key to your keychain (see the Key Management API section of our docs for more details).

ED25519

ED25519 is best used when building applications on top of Space and Time. They're easy to generate and can be tied to a single application, limiting exposure to potential security risks with deployed applications.

Ethereum Wallet

Ethereum Wallet is best used when connecting to our dapp, as authentication is as simple as clicking sign on the Wallet extension popup that appears.

Username/Password

Username/password is best used when you want to avoid both of the above two means. It can be integrated into your application (you'll just need to make a single API request in order to get an access token) and is already supported by our dapp, via our Secrets Proxy server.