What's this?

Didn't we want some conception of a "device type"?

jon mentions below that "device" is the signing public identity key of primary device

+1

should we call this primaryDevice?

this is a little confusing since it's actually the value of HashMap, not the whole thing

What's the significance of having this here now? Are we trying to future-proof for the future world where we support the concept of a primary device? If so, we should perhaps replace this with the proper "device list" from the whitepaper

Sure

I'll make it into another block

What's the significance of having this here now? Are we trying to future-proof for the future world where we support the concept of a primary device?

Honestly, it was a carry-over from the last table. but having a primary device being easily identified seems aligned with the longterm vision of the identity service; and fits the data model as a users should have one and only one primary device, so I left it in.

I wouldn't call lit future proofing, this diff just defines field names for the table; which is free to evolve somewhat with time.

If so, we should perhaps replace this with the proper "device list" from the whitepaper

Device list in the papers is much more... involved, including a series of order-able signed updates.

I would like to avoid device list scope creep.

Might be good to define the format of this, potentially by referencing the .proto

My high-level point is that we'll never use this device field at all. It's not useful today because we don't have a conception of a primary device, and it won't be useful in the future because once we do have a conception of a primary device, we'll need to introduce a device list

If you feel strongly that you really want this here, I guess it's fine to have useless fields. But I honestly think it should be removed given it will never be used

I assumed that it would be important for reasons that weren't immediately obvious to me since it was in the fields for the previous users table.

I'll just remove

I don't think it was in the previous users table. The "device" concept in constants.rs is just for string interpolation and error handling. This is an example item from DDB:

{
  "userID": {
    "S": "4740395"
  },
  "devices": {
    "M": {
      "sXvztyukQSLrsRSkPVk9wJQbi6iuUwCqOjvTYHPjsys": {
        "M": {
          "payload": {
            "S": "{\"notificationIdentityPublicKeys\":{\"curve25519\":\"A4XE/R5jAwVQAKufEnaR3ZFgckKzHGXBHvC5ABg3zUU\",\"ed25519\":\"cskr5GRd1ZJdBewpj6W2v5LE560uD/irmcxuFagL9IQ\"},\"primaryIdentityPublicKeys\":{\"curve25519\":\"nxTumGZiB67Ab9U0XmHK4q6/C1MVpNqqbanNIVSWeU4\",\"ed25519\":\"sXvztyukQSLrsRSkPVk9wJQbi6iuUwCqOjvTYHPjsys\"}}"
          },
          "signature": {
            "S": "Wy1IfR3YYtUeiD4naTrkq+STPos882Np1odCffGtwFMWXMBqvZVUi+iPhI9XkhDMpZLVDk0EHWRVDCg5w1OPBg"
          }
        }
      }
    }
  },
  "pakeRegistrationData": {
    "B": "hFzSfOs751EWUGQM35JmizGPkDK7FWXD6Bvf66bp/gyoyl3seLJUl9FXR+o1H2+aL8oGIZrq+Qu1kTSnSAoxAAGrLyG9mQgSndYFXhMprIvW5TdKw7pTxVGq8AX9BlW9jFuF3ky/50Rnz/RFU4psMod23wQkSWlZ4Vo8q4xuuygURmOsBpABIy7nt4SPuxJjsats8YdrHG8qCIT6P0B8lxyTYDQrIJvrowXH9dyyp0KSSodMOW8QrbqfOWCP1X1L3g=="
  },
  "username": {
    "S": "testedt"
  }
}

I'm referring to the constants.rs file, https://github.com/CommE2E/comm/blob/493a462e18fe19cb4ce0e35759dd4bb3942e3963/services/identity/src/constants.rs#L14.

We never described the schema outside of implementation previous to this diff.

The "device" concept in constants.rs is just for string interpolation and error handling.

I understand what you're referring to. I just wanted to make sure you knew what that const was for. We use it for error handling, so I don't think you should've removed it from the opaque2 module. It probably does make sense to separate it out from the schema concepts, though.

I suppose we could also just use the existing const for error handling