The old school way of doing something like serving notifications over websockets without using a hacky solution like bitcoind's walletnotify to a script, or new, well-engineered solution like btcd, is to create an actual lightweight Bitcoin node in the language of your websocket server. Traditionally, people have used artforz's old Python half-a-node for this purpose[1].
I recently updated this old half-a-node, also using code from jeffgarzik's python-bitcoinlib, to run on Python 3's new asyncio instead of the old asyncore. I have then have it tapping into PyZMQ to scale up and serve websockets on multiple Tornado servers. I've open sourced the asyncio part and may open source the rest soon[2]. In the full project, Tornado provides the main event loop for asyncio, but also smoothly integrates the ZMQ event loop using eventloop.ioloop.
I used this to create a backend for a realtime Bitcoin POS application, but I'm not convinced there's a real market yet for it, so I've not yet moved forward with it. Fun stuff.
It is odd that something based on the actor model could be so overengineered though. This is in spite of the fact that messages are untyped!
The library did feel very solid though, our project was deployed on a pretty big network and we had no issues on the akka side concerning messaging, and this was with some extremely heavy traffic message-wise.
http://blog.codacy.com/2014/01/29/typed-actors-with-routing/
One thing that I dislike about the Akka implementation of actors is that they can't block, because this would block a thread in the thread pool. Quasar's implementation of actors allow you to block on e.g. I/O, because Quasar can preempt fibers that are parked. This makes Quasar's actor framework much more powerful and more Erlang-like.
About being over-engineered... well, it is quite extensive for what it does but I'm not sure I agree with it being over-engineered...
I also found that it's a bit difficult to debug, since I often have request-response chains (like: get raw transaction (1) of an incoming transaction, get raw transaction (2) of the input, create a new transaction using the output of (2)...) and one chain of messages gets mixed up with another chain of messages. So it gets somewhat confusing in the logs. But I guess that's a common problem of event-driven programming...
This has the benefit of less time for the unencrypted key to be vulnerable in memory and also ease-of-use since it can automatically search the blockchain for keys generated by the user. For application servers this adds a huge layer of security since you can accept money with the private keys fully airgapped.
Where do you see this? In a conformal README or another README for this scala project? Because it is not necessary to derive the root private key to create a new public address. Instead, the next public key can be chained from the previous public key and the chaincode (seed). When pubkeys and addresses are created this way, the private keys are not immediately created, but are recovered the next time the wallet is unlocked. So while this is not an HD wallet (it's essentially the same as Armory's current file format, and there is no hierarchy), it does have some of the same deterministc address chaining properties.
The code for performing this pubkey chaining can be found here: https://github.com/conformal/btcwallet/blob/8795534408b47685....
for the related blog entry with some more details, check out
http://markgoldenstein.com/building-websocket-client-btcwall...
we just recently released a small library that makes using the JSON-RPC much easier, and it should work with both bitcoind and btcd
https://github.com/conformal/btcrpcclient
this makes some of the things mark mentioned a bit less painful, e.g. marshal/unmarshaling the JSON, error handling, async replies. it is in go, so it might not be immediately useful to scala devs.
btcctl is also really helpful. I only found out about it today though. Before that I've used curl and httpie and that was not very convenient.