Hi, here are some answers and comments to your comments and questions:
The community of Tackler is next to non-existing, that's true. However Tackler is actually used based on OSS-repository statistics and stats are increasing over time. So there is some traction of it e.g. e257/accounting/tackler#2
Tackler core itself is actually really small, few thousand lines of code, so with all the tests it should be fairly easy to take over it. Also used Scala code is pretty straightforward. These should provide some insurance against small community.
It would be ok-ish to have some java code with Tackler, if reason is good and well justified. One example would be in-memory Git repository writer: GitDB On the other hand, Scala is really nice language and it's possible to move from Java to Scala in gentle way (I did that - Tackler isn't very die-hard Scala).
If you could point worst places where documentation is lacking or provide patches, that would be really awesome.
Easy requirements for contributions are that everything is signed-off (e.g. every single commit) and it would be really nice if you could also PGP sign commits. Please see CONTRIBUTING, it has some information.
Then the more difficult and vague stuff about contributing:
There are some reason why tackler exists in first place and some high level goals in README. At the moment aim of Tackler is to have really narrow focus, but that minimal feature set should be done extremely well and trustworthy.
Also all features must be tested really well. This is unbreakable rule for Tackler. I won't accept any changes (my own or someone's else) if it degrades seriously test coverage. There might be exceptions if it's truly too difficult to test reasonably, but it should be exceptional situation.
Tackler's idea is to be minimal core and cli interface is "reference implementation" of those features of core, but not necessesary full CLI UI. For example, I have several applications where all kind of business domain specific filters are defined in shell script and fed to tackler via --api-filter-def as base64 armored ascii strings. But those filter combinations are not implemented as CLI options for above reason.
On the other hand, if the idea is cool, then by all mean let's have it in the Tackler (e.g. accounting checksums and geo location).
My plans for tackler are: It will be maintained and extended as needed. (ATM I have tag support on the pipeline). Tackler's README has some high level ideas for future. I typically work with Tackler during nothern hemisphere winter and not so much during summer. However, this winter has been exception. Tackler probably won't ever have as many options and features as ledger, hledger or beancount. And it won't have ledger-compatible format.
Do you think we could compile the scala code to a typescript library as well ?
I'm working with a friend on an react app that will allow us to assign transactions exported from the bank to a list of accounts
That sounds really cool. Especially if you have feedback how handy or not git storage backend is for your use case, that would be interesting to hear.
Hi, Thanks, nice to hear that! I don't have any real customer or usage stories to be shared, but based on OSSRH stats, it is used to some extend. I have private systems which are based on Tackler, but I can not share details about those.
In general, there are several features which makes Tackler really well suited to client-server systems (kind of CQRS setups), imho:
For example the client can update "account" state by sending transactions as single message (txn-file) to server. This transaction will internally be coherent (guaranteed by accounting equation e.g. sum is zero), and it can be delivered to server either as a file/message or as part of git commit. If it's delivered as file/message, then it can be verified by server
string2Txns (https://gitlab.com/e257/accounting/tackler/-/blob/main/core/src/main/scala/fi/e257/tackler/parser/TacklerTxns.scala#L326) before it will be inserted into storage (be it on filesystem or git).
There is possible to generate proof of used (by server) accounting data to the client, and client (system) can run reports by themselves and verify that server has used correct transactions for the report https://tackler.e257.fi/docs/auditing/ and https://gitlab.com/e257/accounting/tackler/blob/main/contrib/txn-set-checksum.sh
Lastly Tackler data model is designed and tested to withstand a lot of transactions (not in VISA scale, but in scale of smaller system), it is routinely tested with integration tests with 100_000 txn sets, and performance tested with 1_000_000 tnx sets. One transaction every minute over year is around 500_000 txns. Or 1000 persons, 10 txns per person per day for one month, that's around 300_000 txns. Git itself will have some problems when there are many objects, but there are workarounds for those problems. If you like to play with git as db, check out this demo/proto: (https://gitlab.com/e257/proto/gitdb)
If you are after personal finances and don't need strong auditing capabilities, then you could be better of with ledger, hledger or beancount. On the other hand, if you have system, which is (semi) autonomously producing transactions, then tackler could be something which is worth of investigation.