Generate Better IDs

[svapnil]

a prefix like we had with TRF would be useful to users looking to differentiate between UUIDs

It would be useful to standardize these IDs in such a way that makes it easy for a human to distinguish between them, and have them sufficiently random.

This has been accomplished by leading fintech companies like Increase (https://increase.com/documentation/api#ach-transfers) and Stripe (https://docs.stripe.com/api/payouts).

Examples:

Increase (api bank) ACH transfers IDs are like: ach_transfer_uoxatyh3lt5evrsdvo7q
Stripe payouts IDs are like: po_1OaFDbEcg9tTZuTgNYmX0PKB

Currently, the default IDs that generates are uuidv4()s. We should reimagine this to be like Stripe / Increase

I think we need a system for generating IDs that is similar to these great companies. We might need to think a little bit more about this and generate a thoughtful change that will apply to the whole package. It would be an incredible and needed edition to iso20022.js.

Originally posted by @svapnil in #25 (comment)

[daelvn]

My go-to for generating IDs always is nanoid. It's only 118 bytes, so it's really small, and it can generate a wide variety of IDs. I'd recommend that you check it out. With it, we can compose human-readable IDs for the project.

[svapnil]

Great idea @daelvn . My intuition is that we should steal copy borrow the best practices from Increase / Stripe.

A couple things it would be interesting to learn from them:

• Should the IDs generated be random, or should they have timestamp data embedded in them? (like uuidv7)
• What base / character set should we use?
• What should the naming scheme be? First instinct is that we should mirror the element like "pmf_xxx"

As this library grows and starts being embedded in other companies financial stacks, it's important we get these primitives right

[daelvn]

It's good that you have these things under control more than I do. I wouldn't have thought of some of those things!

I've found an implementation guide from a Spanish bank that mentions a list of allowed characters. It also allows for some ASCII representations, but I don't think we want to be using &; codes for UUIDs, especially with how old or outdated some bank infrastructure can be. The generated UUIDs should therefore all be in this range, I'd understand.

As for timestamp embeds, UUIDv7 generates a 36-character long UUID, which may fall out of the 35 character limit we're using for IDs. In that case, we can use the element name as you said, and a UUID of a standard size that makes all UUIDs never go over 35. Maybe an UUID length of 20, plus the header (pmf_) would be good.