Consider using XID for UUIDs #930
Comments
|
I could use this feature, as we're creating a product that implements the SIM7020 chipset for 4G NB-IOT communications. The chipset lacks PPP support, so the internal client has to be used, and this only supports a maximum username for MQTT connections of 32 characters, which makes connecting to MF with the standard ID's impossible. For us this feature is a should-have, because of the aforementioned limitations of the SIM7020, however we are working on a workaround. |
|
I am not sure if we can make ID format optional - it is not good idea, can create havoc :). But it would not be so hard to replace UUIDv4 currently used with XID. @MisterScience5 did you succeed to solve your problem, or we should look into this issue more carefully? I am reluctant of changing ID format now, without huge need. I would rather leave this for post-1.0 version. |
|
I am in the process of doing so - just using HTTPS as the modem handles that (somewhat) better. As a sidenote, getting MQTTS working on the modem is a nightmare too, so for me this is not critical - I will adapt:) |
|
Great to hear that you've found a workaround. We are always striving in making Mainflux better and more complete, we just need to estimate where is good to make an engineering compromise. We need to understand better this problem and probably address it when we have more time. For now it is low priority. |
|
https://blog.kowalczyk.info/article/JyRZ/generating-good-unique-ids-in-go.html http://antoniomo.com/blog/2017/06/03/unique-ids-in-golang-part-3/ https://forum.cockroachlabs.com/t/best-practice-for-xid-primary-keys/2655
|
|
One more thing to note is that it would be good to have true randomness and unpredictability of UUIDs, as they can be used for tokens (passwords) as well. Related to this I asked a question about Reference: https://security.stackexchange.com/questions/165987/is-uuid-v4-cryptographically-safe-for-passwords |
|
I am concerned about the state of XID development: questions are not responded in a timely fashion, issues hanging for a long time: https://github.com/rs/xid/issues Because of low responsiveness, I would disqualify this format and pick ULID as a better candidate. ULID Go implementation seems to be very active. |
|
Interesting read: https://www.sciencedirect.com/science/article/pii/S2352864818300671 |
|
After many considerations, we have decided to stick with UUIDv4 as the only standardized (by IETF) specification. Sticking to standards is important. Both ULID and XID are not yet officially standardized. |
FEATURE REQUEST
Is there an open issue addressing this request? If it does, please add a "+1" reaction to the
existing issue, otherwise proceed to step 2.
Describe the feature you are requesting, as well as the possible use case(s) for it.
Mainflux curently uses UUIDv4, which is great for the purpose, but can have some drawbacks explained here:
I am not sure that we need sortable UUIDs, but I think shortening the length of the ID can be beneficial for clients that go over cellular or satelite connections and saving any byte on bandwidth (multiplied by millions of devices) can be beneficial.
As described in this text, xid seem interesting indeed.
On the other hand, as API key (token) is also in the form of UUID, maybe lowering its length can have negative impact on security.
nice-to-have
The text was updated successfully, but these errors were encountered: