Re: User interaction

Mike Hearn

Hi Tomas,


Your utility code sounds very interesting! It’d be excellent to get it out into the open if your management doesn’t mind. If you like, we could stash it under the experimental directory of the Corda codebase (code in this part of the tree doesn’t have to go through code review). Or it could be a separate repository that you retain management of. Up to you.


Stefano has done some experimental work on a layer on top of Corda that auto-generates a lot of the boilerplate that’s needed when working with specifically just linear states that evolve in predictable ways. (Un)fortunately he ended up working with an important/high priority customer instead so that work got parked, but we may try to unpark it at some point. The idea is, it generates a class that looks kind of like a normal object. You can make normal method calls on it inside flow context, and behind the scenes, it’ll create a transaction to make that change, distribute it to the right participants and so on. Almost a bit like the Ethereum programming model except that it’s backed by the ordinary UTXO-style Corda ledger.


Obviously there are limits to what you can implement that way – fungible assets in particular don’t map that well to object oriented programming, but for states that just want to track a single data structure over time, it should be easier.


It sounds like your approach is somewhat related, so comparing notes would be great. In particular the FSM specification sounds interesting, maybe we can combine forces somehow.


There is this one year old proposal about "Human task integration":

Are there any updates for this proposal?


Not really, although I’ve been doing some more expansive thinking on the topic over time.  I’ll jot down some notes here.


The proposal you link to is essentially a small set of independent upgrades to make flows more useful. The idea is that flows will be able to pose users questions and get back answers, using ordinary imperative constructs like loops and branches to beat the user into submitting valid data before the flow proceeds to try and sync up with other organisations.


Tradle (Gene Vayngreb) has done some good work on the UI side of this. is an open source framework for chat-style interactions that also support embedding straightforward dialog-box style question and answer prompts, ability to upload and download attachments and so on. I’m not totally convinced by AI driven natural language chatbots as the future of business, but a rich chat-log style UI for structured interactions, developed at lower cost than traditional web form style UI - I totally buy that. There’s no particular reason why all business logic must be driven via web forms and it’s often easier not to. For instance, many web apps struggle to handle the back button correctly. A log-style UI framework would assist developers in controlling back edges in the workflow graph.


Chat-log UIs fit very naturally into the notion of Corda flows. We can easily imagine an API like this:


val location = sendAndReceive<WorldCoordinate>(


“Hello poxy flesh-being, tell me where you would like to ship your bananas”,



var sure = false

while (!sure) {

     sure = sendAndReceive<Boolean>(humanIdentity, “Are you sure?”, YesNoButtons)



in which the UI framework handles the details of letting the user navigate an embedded Google Map with search to select a place, and the flow sleeps until it’s done.


Of course the original suggestion of adapters to bridge to ticket systems and the like are still valid.


There’s a fundamental thing here, which is that in your utility code the current state of the user interaction is stored as an actual ledger state. Whereas in the vision I outlined above it isn’t, instead the state is opaque data stored inside a checkpoint.


Flow checkpoints have a few attributes that deserve further examination:


  1. They are very easy to use – almost too easy, in fact, often the first time developers become fully conscious the mechanism is there is when it goes wrong somehow 😊
  2. But they don’t survive upgrades to flow code well, or sometimes at all.
  3. And they aren’t processable or analyzeable in any way.
  4. Because of (3) they are ephemeral. They aren’t meant to be stored, logged or kept long term. Checkpoints are erased when no longer needed. A checkpoint that lives more than a few days probably indicates something has gone wrong. They exist only to make the node robust to restarts and outages of peer nodes.
  5. Again because of (3) flows have a notion of a progress tracker to expose human readable information about where they got up to. They can also use ordinary logging frameworks, of course.


The sort of human interaction I’ve been imagining is entirely within an organisation. The other side doesn’t know what’s going on in detail. They just know they’re waiting for a response. Therefore, the limits of checkpoints and flows don’t matter much – if you do need to communicate some sort of “Your request has been picked up and is being worked on” progress information then you can define custom messages for that.


The sort of human interaction you’ve implemented is different – the progress of a thing being authorised is itself sharable on-ledger data. You pay a higher programming and storage cost to get that, but it has some advantages.


I’d be interested in getting more thoughts from the community on this whole design space. If flows were extended with the ability to send messages to/from people, if we had an ultra-low cost way to develop interactional UIs via Tradle-style chat UX, and if we enhanced the flow framework a bit more, would things like status tracking migrate off-ledger or are there other factors driving this? Do you really need the overhead of a full ledger transaction for this use case?




Join to automatically receive all group messages.