2019-05-09 Meeting notes: Discuss ListenAtName

Date

May 9, 2019

Participants

  • @Kelly Foster

  • @Kayvan Kazeminejad

  • @Timm Schäuble

  • @Artur Gajowy

  • @Ovidiu Deac

  • @Dominik Zajkowski

  • @Tomáš Virtus

  • @Sebastian Bach

  • @Adam Szkoda

  • @Former user (Deleted)

  • @Łukasz Gołębiewski

  • @Pawel Szulc

  • @Lucius Meredith

Goals

Review the dApp developer use case for ListenAtName. Discuss improvements.

Discussion topics

Item

Notes

Item

Notes

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