Just realized we're allowing the same public key with different cases here – can we lowercase this before storing to make sure we only have one version with it?

The public key is base64 encoded... lowercase and uppercase characters are different.

This is different than the ethereum address which is encoded as hexadecimal (with optional capitalization to compute some sort of checksum)

I wonder if we should also make sure we don't have multiple cookies with the same public_key. Our whitepaper talks about restoring an existing public_key onto a new device (in "3.1 Backup" and "4.1.7 Primary Device Switch").

That necessitates some sort of hand-off between devices. We generally want to avoid a scenario where two devices are represented simultaneously by the same cookie... we've seen this before after an iOS backup is restored. So you could imagine us excluding the cookie from the backup, as discussed in point 1 of ENG-2628.

I could imagine some sort of problem behavior that would result here of the new device then trying to initiate a new cookie with the same public_key. The protocol in the whitepaper requires the handing-off device to initiate a new session, but if it fails to do this for whatever reason it could be a problem.

Created ENG-2628 to track adding a UNIQUE constraint here.

Created ENG-2628 to track adding a UNIQUE constraint here.

Oops, I meant ENG-2629

The public key is base64 encoded... lowercase and uppercase characters are different.

Got it

This is different than the ethereum address which is encoded as hexadecimal (with optional capitalization to compute some sort of checksum)

Uhhh interesting, is that something where we should be normalizing?

Uhhh interesting, is that something where we should be normalizing?

Thought about that, but figured it made sense to keep things symmetrical with the interfaces we're using. EG base64 encoding for the public key since that's what OLM uses, and hexadecimal for ethereum address (since that's what rainbowkit... and pretty much everyone uses)

We could prefix some sort of base64_ to variable names + column names to make it clearer maybe? (https://en.wikipedia.org/wiki/Hungarian_notation)

I think we should normalize the ETH addresses so we only have one way to represent an ETH address in the database. We could keep the checksumming behavior with a package like ethereum-checksum-address (NPM link), or we could just lowercase them. What do you think? Can you create a task to track before landing?

https://linear.app/comm/issue/ENG-2630/normalize-storage-of-eth-address