Closed igamigo closed 3 months ago
And I'm a bit worried we're overcomplicating ourselves here. I saw on the issue that you mentioned the alternative of forcing imported notes to have their inclusion proofs (i.e we should only import committed notes). Isn't that a possibility?
And I'm a bit worried we're overcomplicating ourselves here. I saw on the issue that you mentioned the alternative of forcing imported notes to have their inclusion proofs (i.e we should only import committed notes). Isn't that a possibility?
Yeah, I share the worry as we discussed today (which is also why I left this as draft to move the discussion forward). I think I mentioned this as well but I don't think forcing imported notes to have inclusion proofs is a real possibility, as many flows are then prohibited.
I think I mentioned this as well but I don't think forcing imported notes to have inclusion proofs is a real possibility, as many flows are then prohibited
Which flow would be prohibited? I think everytime we export a note we can just wait until it gets committed and then export it. I'm not very familiar with other use cases than the standardized ones though so I'm probably missing something
Which flow would be prohibited? I think everytime we export a note we can just wait until it gets committed and then export it. I'm not very familiar with other use cases than the standardized ones though so I'm probably missing something
In general any flow that expects a note to exist in the future, but is not included in the chain yet, like in some of the examples from this issue. We need a way for the client to import incomplete notes and this includes the inclusion proof.
@bobbinth in this PR I implement a basic strategy for dealing with remaining notes. It's fairly complicated and although there are things that could be better (plus some follow-up work like implementing exponential backoff for dealing with stale notes), I wasn't sure if we would move on with this approach so if you have any notes let me know.
Closing this for now, and moving the refactors (not related to the feature in this PR) to a different branch
addresses #341. Still draft as it's not complete (even though it is functional) and not definitive (as we might decide on a better alternative).