Adding a timestamp field to the "uAttributes" and treat uuid strictly as the unique idenfier ("id")

[lynn2009]

In the current uAttribute design, the message creation timestamp is embedded in the UUID, and different UUID versions require distinct methods to extract this timestamp. While working on uProtocol 1.5.8, we must ensure backward compatibility with uProtocol 1.3.x, leading to implementation complexities in the cloud platform or applications.

To simplify this, we propose adding a new timestamp (uint64) field to uAttribute to represent the message creation timestamp. This allows the id field to be used solely for unique identification, enabling applications to choose the most suitable UUID version without backward compatibility issues.

[stevenhartley]

Hi @lynn2009 both the UUIDv6 and UUIDv7 have means to fetch the timestamp and calculate expiration and this timestamp is when the message is created so adding another 64bits with an ideantial timestamp as what is in the UUID would not be efficient nor add any additional value to the message. We cannot swap out UUID versions as we see fit, doing so would mean there is no consistency in the protocol hence why we are sticking with UUIDv7.

[lynn2009]

@stevenhartley , we should decoupling the unique identifier generation from the event timing: a) performance overhead introduce to have additional logic to extract and interpret the timestamp from uuid
b) compatibility issue -- recognize timestamp-based UUIDs leading to integration challenges. We see this when we try to upgrade to 1.5.8.

Having separate fields for the UUID and the timestamp of an event is more flexible and clearer -- distinct fields make it clear that each value represents.

[stevenhartley]

@lynn2009 , a) there is no evidence that there is additional logic pulling out the first 48 bits from the 128 bits of UUID takes more time than reading a separate 64 bit timestamp (that includes additional bits that don't add precision accuracy that we need). b) This is not an issue, the UUID has a bit that indicates v6 vs v7 and it is very efficient to pull out the bits and verify the timestamp.

The proposed changes (a separate 64 bits timestamp) doesn't solve the actual real issue of clock source and clock synchronization across the devices, that is what we need to focus on solving.

to your final point, once could argue that if we were to redo the protocol again (say version 2.0) we want to consider less bits for ID and split the time then but it is too late for these changes. Steven.