Naming conventions for bindings

[reez]

Naming Convention

• In bdk-ffi, Kotlin is currently named by target/platform (bdk-android, bdk-jvm) rather than by language.
  • That makes sense because Android and JVM are distinct targets, but it breaks what I might have as language-first mental model (bdk-<language>).
  • There is also historical nuance: bdk-kotlin exists (archived/moved to bdk-ffi) and historically published both bdk-jvm and bdk-android.
• External precedent is mixed too (for example LDK Node has a bindings/kotlin directory but publishes ldk-node-jvm and ldk-node-android, Cashu has cdk-kotlin, UniFFI generally uses the term “bindings” for foreign-language generated code).

Wondering about documenting a short naming convention for BDK bindings going forward (repo/module/directory names vs published artifact/package names) that makes sense and cleanly lines up? Not proposing an immediate rename here, mainly thinking thru for a clear rule so future naming is consistent, and also a place to document discussion.

Current BDK binding names

• bdk-android (module/directory inside bdk-ffi, Maven artifact bdk-android)
• bdk-jvm (repo + Maven artifact bdk-jvm)
• bdk-swift (repo + SPM package bdk-swift; Swift module/framework BitcoinDevKit)
• bdk-python (repo, PyPI package bdkpython)
• bdk-rn (repo + npm package bdk-rn)
• bdk-dart (repo, pub package bdk_dart)
• bdk-wasm (repo, publishes npm packages bdk-wallet-web and bdk-wallet-node)
• bdk-kotlin (archived repo; moved to bdk-ffi; historically published bdk-jvm and bdk-android?)

[thunderbiscuit]

One thing I'd be down for right away is to rename the directories. Wouldn't have a impact on published artifacts, just a cleanup of the repo itself.

bdk-ffi -> rust
bdk-swift -> swift
bdk-android -> kotlin

[thunderbiscuit]

This will potentially break downstream repos that have scripts and CIs that rely on the submodule and the naming convention of the rust code (scripts that do cd bdk-ffi and whatnot), but honestly I'd be down to break it all for the 3.0 release! We're aware of all (I think) repos that use bdk-ffi as a submodule, can produce the fix ourselves in all of those, and it would honestly be a nice little cleanup here. Just my 2 sats.