Closed kantorcodes closed 2 weeks ago
This came out of a conversation between Kantor and I. The field refers to the Sequence ID of the message being referenced, so renaming it 'sid' makes more sense and will clear up confusion/ambiguity over what the uid is supposed to represent.
I'm good with updating that attribute, especially if it's causing confusion. The intention of uid was in case it was referencing something like a external entity pointer or just a proprietary uid on a message separate than the sequence number.
If we change to sequence number, did ya'll consider the other attributes that may be in line with other hcs standards?
We use sn
on hcs-5 and we could match t_id
format with s_id
or sn_id
. If there's a strong want for sid
that works too, just making sure those other options were considered
I'm good with updating that attribute, especially if it's causing confusion. The intention of uid was in case it was referencing something like a external entity pointer or just a proprietary uid on a message separate than the sequence number.
If we change to sequence number, did ya'll consider the other attributes that may be in line with other hcs standards?
We use
sn
on hcs-5 and we could matcht_id
format withs_id
orsn_id
. If there's a strong want forsid
that works too, just making sure those other options were considered
Per discussion, I think we should leave it the way it is. uid
is more flexible for external references and could be confusing with sn
Per discussion, it could make utilizing HCS-2 slightly less confusing if
uid
wassid
to represent the sequence number being updated.