Roadmap and honest status

We are steering hlf-core toward becoming an industry standard, and the path to it lies through quality, not through loud claims. That is why it makes sense here to talk both about what has already been done well and about what still lies ahead — one without the other would be dishonest.

What is already strong

The main thing is that hlf-core has been proven in production, on real financial systems, not on demo examples. Its architecture is coherent: a single entry point, signing at the application level, an ORM over key-value — all of this is not a set of disparate tricks but parts of one idea. The token system is mature, with auditing and exact string arithmetic. The framework works with both Fabric 2.x and 3.x (see «Compatibility»). There are also things that people usually never get around to: batch mode and transactional state management through StateProxy.

What is in progress

The most noticeable of the open items is reliable delivery of effects: at the moment commands can be lost between the commit of a transaction and the dispatch of effects, and we are closing this with the transactional outbox pattern. In addition, an English documentation locale and automatic generation of the API reference from the sources lie ahead.

Technical debt

If we call things by their proper names, hlf-core has places that hold together not through their construction but through the author's care. These are exactly what we consider the primary debt on the way to a standard, because for an outside consumer "holds together through care" means "will break one day". Some of what is listed below has already been closed — I note this right where it applies.

First — defaults and their cleanup. The default values were set in two places at once: where they are applied when a command is received, and where they are cleaned out of the envelope before sending, so that nothing extra is laid into the ledger forever. This pair is obliged to stay symmetric, but keeping it that way had to be done by hand, and this has already let us down — one options field long lived under a different name and was not recognized as a default. The core of this is already done: the defaults have been reduced to a single source, from which both the setting and the cleanup are derived automatically and physically cannot diverge, and the field itself has been renamed. What remains is to close the last asymmetry — in the batch branch the cleanup does not yet have a paired restore.

Second — the nonce and the concurrency model. Replay protection is built on a strictly increasing per-user counter, and this deliberately serializes the user's commands: two parallel transactions of the same user conflict on a shared key. For accounting systems such serialization is often even desirable, but it is worth stating explicitly rather than leaving as a surprise, and reducing nonce generation to a single canonical way. Bulk operations go off to batch precisely for this.

Third — implicit conventions. Part of the correctness rests on agreements that are nowhere fixed in the types: command names without service characters, the order of assembling the envelope. As long as the convention is observed, everything is correct, but it can be broken silently. We are moving such invariants from "by convention" to "by construction", so that the error is caught by the compiler or a check, rather than in operation.

Fourth — releasing and versions. The core of this is also already done. The package publishing process has been put in order: a release goes through with a single command, the publishing tool no longer pushes extra branches and correctly sets the version in the package being assembled, and the inconsistency of its versions across packages has been eliminated. The READMEs of all packages have been aligned to a single look — without decorative noise, with the same structure and common sections. What remains is to finish the automatic generation of the API reference from the sources and to align the remaining version ranges of dependencies.

Fifth — cryptography under regulatory requirements. Support for GOST and RSA solves the compatibility problem, but the GOST implementation is not certified as a cryptographic information protection tool (CIPT), and RSA relies on an outdated library. For a legally significant signature this needs to be stated plainly: behind a certified perimeter stands a separate certified tool, and our layer provides an interface to it, not a replacement.

On openness

hlf-core is an author's project, and this too is worth stating plainly. The path to the status of a standard is not only code, but also outside consumers, feedback and the community's contribution, and we are open to this. Questions and suggestions — via GitHub.