Commit missing change

In D12017#343209, @ashoat wrote:

Interesting that this change is backwards compatible! What's the significance of the optional keyword in the .proto definition – is that just an annotation so that types can be codegenned correctly?

Yes, looks like the optional keyword is mainly for codegen. In Rust, it's String vs Option<String>, in JS it's string vs ?string etc.
Technically, on proto side it doesn't matter, except unset optionals are not serialized to save bandwidth. If the received message from client doesn't contain a field with given number/index (here 5 or 6), but the proto definition expects it, it will be assigned a default value when parsing the message.
As long as we don't change existing field types nor rearrange field numbers, we're safe.
Interestingly, you can unfold identity-unauth-structs.cjs in this diff and there you can see a call getFieldWithDefault(msg, 5, "") for all fields, regardless if it's optional farcaster_id or non-optional initial_device_list.

From proto docs:

optional: An optional field is in one of two possible states:

• the field is set, and contains a value that was explicitly set or parsed from the wire. It will be serialized to the wire.
• the field is unset, and will return the default value. It will not be serialized to the wire.

You can check to see if the value was explicitly set.

Also, a note about backwards compatibility when adding new fields:

If you add new fields, any messages serialized by code using your “old” message format can still be parsed by your new generated code. You should keep in mind the default values for these elements so that new code can properly interact with messages generated by old code. Similarly, messages created by your new code can be parsed by your old code: old binaries simply ignore the new field when parsing.