Fingers crossed and let’s see if this works with the Nym Mixnet and it’s gateways etc.
Hi @Ch1ffr3punk,
The 1GiB split/pause test looks great, clean split into 11 parts and smooth progress on both ends.
Fingers crossed with you on the gateway side too.
We’re sticking with nymdrop’s small file cap for now (~10MB), no plans to chase big files there, but good to know the split+pause pattern works if we ever need it down the road.
Best regards
Gab
1 Like
Hi Gabx,
Over the last night and today I tried various parameters, but nothing worked with 1GB. I may have to check the Rust gateway code to see if it has rate limiting etc. I work also on a simplified Rust version, which uses the Nym Mixnet without the official nym-client, but made it so that it no longer uses auto-split-sending and auto-receiving-joining, because it does not work, of the reason described above. But I thing with further testing I will find a reliable solution to bypass the gateway issues, by cheating 
, so that journalists, whistle blowers and activists can send very large files, for their daily work.
Best regards
Ch1ffr3punk
1 Like
Ah, too bad the 1GB test didn’t hold up in the end.
Makes sense if it’s the gateway itself and not just pacing on the client side, that’s a much harder layer to work around.
Good call moving to raw nym-sdk for the Rust version, and splitting split/join into separate manual steps instead of one automatic pipeline, that’s probably the more honest approach until the gateway behavior is actually understood.
Keep us posted, this would be huge for journalists/whistleblowers if you crack it …. ops !!! LOL
1 Like
Hi Gabx,
I am a naughty boy, an English man would probably say… I currently have 10 instances running, 5 sender and 5 receiver. Fingers crossed. The problem is probably that not all mix nodes and gateways are equally updated to the latest release and I believe it can cause therefore sometimes packet or chunk loss. I switched from my previous approach in NymTransfer from fire and forget to a more reliable solution with re-transmitting, if chunks do not arrive. The split and join commands are no longer in NymTransfer, as it is now a seperate app, called sam (split and merge). Hope you like!
Best regards
Ch1ffr3punk
Well, from five parts only three arrived and it shows that chunks losses are very much more likely in the Nym Mixnet, when sending larger files, compared to small ones. Maybe something for the Nym Developement Team to look into.
Must improve the retry logic for the sender side.
Finished NymTransfer v0.1.0 and will release it soon, after another very cool Nym Mixnet project, for the global Nym community (an autonomous VPS and Desktop game) will be finished. Stay tuned!
Hi @Ch1ffr3punk,
Thanks for your NymTransfer tests sharing, improving file size transfers is in my TODO.
While you were pushing bytes through five sender/receiver pairs,
i was head-down on a couple of improvements on NymDrop:
- Added memguard-backed protection for key material in RAM on the reader side, the X25519 private key and the per-submission ECDH/HKDF secrets now live in locked, wiped memory instead of a plain zero-loop.
- Improved the submission form’s message field: it now has a self-hosted Markdown editor with a Preview/Edit toggle (headers, bold/italic, code, lists, quotes, links) no external JS library, output is escaped and link schemes are whitelisted before rendering.
More broadly,
we wish NymDrop to get in front of the people it’s actually built for journalists, sources, whistleblowers, anyone who needs to get something out safely.
Nobody should be prosecuted for what they say or write, and getting solid, easy-to-use tooling like this into more hands is exactly how that principle gets defended in practice,
not just stated.
Gab Virebent
–-
Hi Gabx, while my NymTransfer is intended for Alice and Bob, because the Nym addresses are known to each other you should also look into a CLI client for NymDrop, in case your site get’s blocked in other countries and then for the CLI client use SURB, so that journalists or whistle blowers do not transfer their Nym address to your platform, even if you do not log.
1 Like
Hi Gabx,
a little tip you may like, like Alexis service or my site you could design it also with purple buttons and use the official purple .ico (for the URL), so that the community see that your site is a Nym communtiy site. 
Best regards
Ch1ffr3punk
1 Like
Green is officially reserved for nym.com and the community should use purple, as once discussed on Telegram.
UPDATE:
dropped one of two base64 layers in the mixnet transport .
Submissions were going through two stacked base64 layers before hitting the wire (browser WebCrypto + a second one wrapping ciphertext in JSON for nym-client’s control websocket, ~1.78x combined).
Switched the server to nym-client’s native binary websocket protocol instead, dropping the second layer.
nym-client picks text-vs-binary for every later push based on the last request format seen on that connection, switching only the sender isn’t enough, the receiver has to request in binary too, or nym-client silently corrupts the now-unencoded payload via from_utf8_lossy.
Found this the hard way on first E2E test.
Verified live in production, same Nym address, no key rotation.
1 Like