-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: lazy ot #186
feat: lazy ot #186
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm 🚀 nice work
LGTM, except one q above @sinui0 |
I dont see a q |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the q should now be seen
}, | ||
); | ||
|
||
while let Some(Queued { count, sender }) = self.queue.pop_front() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if the sender payload length is less than what was queued, then there will be partial or empty OTReceiverOutput
. Is this the intended behavior? why is such behavior needed?
seems like a footgun which will be hard to debug.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sinui0 ---^
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The length of the entire queue gets processed at once, this should always have the correct number. The assumption is that new messages will not be queued in between transfers. This should probably be documented, or enforced via type state.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sinui0
Sorry, I'll try to more accurately describe the issue because your response didn't seem to address it.
Suppose, the receiver queues 60 OTs.
Suppose in receive
the length of SenderPayload
is 30.
Why is it not an error that the receiver will get only 30 OTs out of the 60 that they intended to receive?
This PR refactors our OT crates to have lazy interfaces. It also disposes of committed/verifiable functionality as we no longer need it. Dependent crates are in a broken state and will be fixed in following PRs. Ferret is also omitted temporarily.