Skip to content
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

Does payload padding still make sense? #70

Open
jstuczyn opened this issue Jul 21, 2020 · 1 comment
Open

Does payload padding still make sense? #70

jstuczyn opened this issue Jul 21, 2020 · 1 comment

Comments

@jstuczyn
Copy link
Contributor

Or even, has it ever made any sense? Recall that inside sphinx library itself we are padding the received message so that the payload has constant length: https://github.com/nymtech/sphinx/blob/develop/src/payload/mod.rs#L95-L96 . But should it even be responsibility of this library? I think it should rather be up to the user to what they put there. Plus right now (inside nym) we are padding the message twice and thus losing a tiny bit of possible data we could send.

@burdges
Copy link

burdges commented Jul 21, 2020

You need body padding somewhere, but obviously not twice. ;) You want some quality-of-service layer with erasure coding that does the actual padding. All applications must share the same transport and quality-of-service layer, so like Alice trickles out new objects from her and Bob's shared git repo as she messages him. Also, the mixnet itself should use this quality-of-service layer, so Alice packs in some extra SURBs for Bob when she sends him a small message or whatever. I think one hard question is: what does the interface for a quality-of-service layer that supports really extreme slowdowns look like?

@mmsinclair mmsinclair moved this to To analyse in Core systems May 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Status: To analyse
Development

No branches or pull requests

2 participants