Should the library be renamed?

[whyoleg]

cryptography-kotlin name is nice, but it's long, hard to remember, not unique, and not ready for the Next 25 years (thanks to @martinbonnin for the great talk BTW)

Later this year (hopefully), I would like to introduce a HUGE breaking change to the API to make it easier to use, easier to evolve, and have a better split of synchronous and asynchronous APIs (and so remove confusing blocking suffixes).
This breaking change will be a bit easier if the package/dependency names are changed to facilitate automatic migration (via ReplaceWith).
This breaking change is the last step before the 1.0.0 release!

That's why I would like to hear from you:
Do you think it makes sense to come up with a new name for the library, like decrypto or anything else?
(Suggestions for the library name are welcome.)

P.S. A small sneak peek at the new API, of course, the API is subject to change:

Digest:

// new API
Digest(SHA512).hash("text".encodeToByteString())
// current API
CryptographyProvider.Default.get(SHA512).hasher().hashBlocking("text".encodeToByteString())

HMAC:

// new API
val hmacKey = HmacKeyFactory(SHA512).generate()
val signature = Hmac(hmacKey).sign("text".encodeToByteString()) 
// current API
val hmacKey = CryptographyProvider.Default.get(HMAC).keyGenerator(SHA512).generateKey()
val signature = hmacKey.signatureGenerator().generateSignatureBlocking("text".encodeToByteString())

[ptitjes]

Will you be using context parameters to achieve this new API?

As for the name, I'd say kotlinx-crypto? 😜

[whyoleg]

As for the name, I'd say kotlinx-crypto?

It's better not to use kotlinx if it's not in the kotlinx domain/package/etc. And IMO, I'm not sure that at this point we can have official kotlinx-crypto because of multiple reasons (some of them I've presented previously here)

Will you be using context parameters to achieve this new API?

Nope, plain old extension functions and default parameters :)
I have thought about how context parameters could be integrated with cryptography-kotlin (CK), and every time I come to the conclusion that it will not bring any benefits. Context parameters shine in places with dynamic behaviour and DI-like solutions, where we could have multiple implementations (or instances) of one interface/class in different contexts, or when we need to use something different in tests. I don't think that cryptography falls into that category.

If you have an idea or other opinion, feel free to share it. I would like to hear it!

[ptitjes]

And IMO, I'm not sure that at this point we can have official kotlinx-crypto

Yeah, I figured that out. This was more of a pun...

Unfortunately, I don't have meaningful names that comes to mind. But maybe shorten it to crypto-kotlin?

Nope, plain old extension functions and default parameters :)

Ah, OK. I thought you'd use context parameters to remove the need for the CrytographySystem singleton.

[whyoleg]

remove the need for the CrytographySystem singleton.

I am still thinking about how to improve the situation around this singleton, but so far, it is still the best way
Plus, it will always be possible not to use it, as it is now :)

[MMauro94]

It's not particularly original, but what about krypto? It references being a cryptography library, has a K in the name to reference Kotlin, and the name as a whole might be a reference to kryptonite, which I guess you could find a reasonable explanation of. (E.g. it's kryptonite for attackers).

[whyoleg]

First of all, I personally don't really like this obsession with changing c -> k :)
And in addition, I believe that krypto is used already toooooo much: https://github.com/search?q=krypto+language%3AKotlin+&type=repositories

[MMauro94]

Oh wow, there's a lot of stuff. Yeah probably not a great idea to add another one to the pile.

Another similar idea is to take the word crypt (as in vault: https://en.wikipedia.org/wiki/Crypt) and play with it:

• crypta: the Greek word from where crypt comes from
  • krypta: Kotlin variant
• cripta: this is the Italian translation of the word, but it also means he/she/it crypts

All very similar, but might give you some ideas. One thing I like is when people put some part of their language/culture into the name of something, as long as it's easily readable/pronounceable. So maybe you could look if there's something from your language/culture that fits.

[eygraber]

What about crypto-kmp or kmp-crypto?

[luca992]

People need to stop separating kmp from kotlin. Kotlin is multiplatform. You don't see rust packages including what targets they support in the name.

[MMauro94]

Yeah I agree. I think mentioning the multiplatform-ness in the short description of a library is enough. Looking at the biggest multiplatform libraries, almost none reference the multiplatform in the name.

[whyoleg]

Yes, please, no kmp or multiplatform in name :)
I hope that in the future, multiplatform will be just the baseline of all Kotlin libraries :)

Also, I don't only want to make the name shorter

[martinbonnin]

Few suggestions:

• "Vibranium", to stay in the super hero lexical field, krypto -> kryptonite -> vibranium (also doesn't hurt superman).
• "Bubbly castle", building on the "bouncy castle" legacy (not sure how much this libs inherits from bouncy castle, maybe not the best call).
• "Trampoline" still like a bouncy castle but takes you higher. Might also be clearer that it's not affiliated.
• "Crypus", anagram of the islands where it look like that software was written in? Also starts with Cryp like cryptography but sounds a bit off.
• Maybe "Cryptus" sounds a bit better? "Crypt-us"? "Krypt-us"?

I don't know, naming is hard!

[whyoleg]

Thanks! You really have some good ideas on how to name things!