| |
---|
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 | |
Discussion
| Discussion about challenges of delivering in time what would be ideal Discussion about how implementation of POBox would support this Discussion about SubscriptionAtName To observe results off-chain, we need things to be finalized Ł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. 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
|
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: 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
|