2019-05-09 Meeting notes: Discuss ListenAtName

Recap of the issue

ListenAtName misses updates on channels and doesn't accurately reflect the tuplespace, making it difficult to validate the success of the transfer of data on the blockchain.

RSong use case

• Through 2 deploys

  • Put data on chain

  • Request via ListenAtName

• To access data on chain, request via ListenAtName

• Kayvan walked through rsong-immersion.rho

  • Risk removal of forgeable names will break call to string to fetch song

•  

Discussion

• Discussion about challenges of delivering in time what would be ideal

• Discussion about how implementation of POBox would support this

• Discussion about SubscriptionAtName

  • Using Kafka

• To observe results off-chain, we need things to be finalized

  • We cannot reason about data on-chain that is not finalized

  • Concern about the amount of time it takes to achieve finalization

• Łukasz’s idea - app looks at comm event log

• Artur’s idea -

• Artur’s other idea - look off chain

• Use case: You want to be able to say what your contract is doing for debugging reasons. You want to be able to

• DECISION Start with ListenAtName that asks and returns for persisted tuplespace names, data that is finalized.

  • Later work on handling ephemeral data

• Use case - I want the updates

  • I pass a hash of a finalized block I know

  • I could then inquire for what’s changed after that (ex was was deployed)

  • Requires tracking my deploy ID

• Use case
  
  

  Open

  

   

A proposal

• We will improve ListenAtName in stages

• First stage, be able to serve data about the most recent finalized block as a stream

  • User provides

    • Provide 2 hashes:

      • Hash A is most recent finalized block

      • Hash B is the one before that (default is most recent if not specified)

    • Provide deploy ID

  • ListenAtName returns the diff between the hashes

  • Requires the ability to generate the deploy ID

  • Requires putting the deploy ID and unforgeable name in the tuplespace

  • Assumes ability to connect deploy ID to unforgeable name

• This is blocked by NextRSpace completion

Solution for knowing what to listenAt from an off-chain location

DECISION - Do this!

• Introduce on-chain deploy ID token. Each deploy can use to look up a deploy corresponding to it on a channel

• You ListenAtDeploy to the deploy ID

• If you need to distinguish between different types of messages in the deploy you make your items a tuple and make them a category

• Plan to remove ListenAtName

• Create a deployID channel using the system process to generate name