R3 Docs R3 Docs Home

Chat CorDapp Design heading-link-icon

The foundation for the Chat app is the ChatState which is the data model for facts recorded to the ledger. It can be represented in the CDL CorDapp Design Language as follows:

Data model for facts recorded to the ledger
Data model for facts recorded to the ledger

Where:

  • id is a unique identifier for the chat, it is the equivalent of a linearId in Corda 4, in other words it is the common identifier for all the states in the backchain for a particular chat between two participants.

  • chatName is a human readable name for the chat, it does not guarantee uniqueness.

  • messageFrom is the MemberX500Name for the virtual node The combination of the context of a user and the ephemeral compute instances created to progress a transaction on that identity's behalf. which created this ChatState.

  • message is the message in the Chat.

  • participants is the list of PublicKeys belonging to the virtual nodes of the participants of the chat.

The history of a chat will be recorded in the backchain of the chat.

The Smart Contract Digitizes agreements by turning the contract terms into code that executes automatically when the terms are met. (combination of the ChatState and ChatContract) can be represented by a simple Smart Contract View diagram:

Smart Contract View diagram
Smart Contract View diagram

The evolution of the ledger when stepping through the walkthrough steps can be shown using the CDL State evolution view:

CDL state evolution view
CDL state evolution view
  • The Create transaction has no input and starts a new chat with a unique id. The id operates similarly to the Corda 4 LinearStateId, which has not been implemented yet in Corda 5.
  • Each update transaction creates the new ChatState as an output and consumes the previous ChatState as an input.
  • To recreate the historic conversation the back chain is traversed from newest (unconsumed) state to oldest.

There are six flows Communication between participants in an application network is peer-to-peer using flows. in the Chat Application:

FlowFlow typeInputsAction
CreateNewChatFlowClientStartableFlow
  • chatName
  • otherMember
  • message
  • Forms a draft transaction using the transaction builder, which creates a new ChatState with the details provided.
  • Signs the draft transaction with the virtual nodes first ledger key A key which can be used to sign for transactions. This key may be held confidentially and signatures may be used as evidence of authority to sign transactions. Alternatively, it may be published in the virtual nodes's MemberInfo to act as a published fact to prove the identity of the virtual node on the ledger. .
  • Calls FinalizeChatSubFlow which finalizes the transaction.
    • UpdateChatFlowClientStartableFlow
  • id
  • message
  • Locates the last message in the backchain for the given id.
  • Creates a draft transaction which consumes the last message in the chain and creates a new ChatState with the latest message.
  • Signs the draft transaction with the virtual nodes first Ledger Key.
  • Calls FinalizeChatSubFlow which finalises the transaction.
    • ListChatsFlowClientStartableFlowNone
  • Finds and lists unconsumed states.
    • GetChatsFlowClientStartableFlow
  • id
  • numberOfRecords
  • Reads the backchain to a depth of numberOfRecords for a given id.
  • Returns the list of messages together with who sent them.
    • FinalizeChatSubFlowSubFlow
  • signedTransaction (to finalize)
  • otherMember
  • The common subflow used by both CreateNewChatFlow and UpdateChatFlow.
  • This removes the need to duplicate the responder code.
  • Sets up a session with the FinalizeChatResponderFlow and calls the finalize() function that collects required signatures, notarizes the transaction, and stores the finalized transaction to the respective vaults.
    • FinalizeChatResponderFlowResponderFlow
  • FlowSession
  • The FinalizeChatResponderFlow is initiated by the FinalizeChatSubFlow. It runs the receiveFinality() function which performs the responder side of the finality() function. ReceiveFinality() takes a Lambda verifier which runs validations on the transactions.
  • The validator checks for banned words and checks that the message comes from the same party as the messageFrom field.
    • Previous
    UTXO Ledger Example CorDapp
    Next
    Running the Chat CorDapp

    Was this page helpful?

    Thanks for your feedback!

    Chat with us

    Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.

    Chat with us
    Propose documentation improvements directly

    Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.

    Learn how

    We're sorry this page wasn't helpful. Let us know how we can make it better!

    Chat with us

    Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.

    Chat with us
    Create an issue

    Create a new GitHub issue in this repository - submit technical feedback, draw attention to a potential documentation bug, or share ideas for improvement and general feedback.

    Create a new issue
    Propose documentation improvements directly

    Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.

    Learn how