<feed xmlns='http://www.w3.org/2005/Atom'>
<title>nymdrop/internal/relay/relay.go, branch main</title>
<subtitle>Nym-native anonymous submission system (SecureDrop-style), using the Nym mixnet as transport instead of Tor.
</subtitle>
<id>https://git.virebent.art/virebent/nymdrop/atom?h=main</id>
<link rel='self' href='https://git.virebent.art/virebent/nymdrop/atom?h=main'/>
<link rel='alternate' type='text/html' href='https://git.virebent.art/virebent/nymdrop/'/>
<updated>2026-07-11T11:37:23+00:00</updated>
<entry>
<title>Switch Nym WS transport to nym-client's binary protocol, drop second base64 layer</title>
<updated>2026-07-11T11:37:23+00:00</updated>
<author>
<name>Gab Virebent</name>
<email>gabriel1@virebent.art</email>
</author>
<published>2026-07-11T11:37:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.virebent.art/virebent/nymdrop/commit/?id=bec3734676faf3868ea225e0316e77ad5a7e4421'/>
<id>urn:sha1:bec3734676faf3868ea225e0316e77ad5a7e4421</id>
<content type='text'>
Client.Send now speaks nym-client's native binary websocket protocol
(tag || recipient || conn_id || data_len || data) instead of wrapping
the ciphertext in a JSON text message, which required base64-encoding
it a second time on top of the browser's own base64 layer.

The reader's self-address query also switched to the binary protocol:
nym-client picks text-vs-binary for every later "received" push based
on the format of the last request seen on a connection, so leaving the
reader in JSON/text mode would have made nym-client run a lossy UTF-8
conversion over the now-unencoded binary payload, corrupting it. Fixed
the binary Received-frame parsing along the way (previous code assumed
a fixed 16-byte tag with no length prefix, which never matched the real
protocol and was never exercised while the connection stayed text-mode).

Verified end-to-end against the real embedded nym-client 1.1.76 binary,
with the exact wire format cross-checked against upstream nym source at
the pinned build commit.
</content>
</entry>
<entry>
<title>Fix payload cap: double base64 inflation broke files near the old 10MB limit</title>
<updated>2026-07-03T13:51:07+00:00</updated>
<author>
<name>Gab Virebent</name>
<email>gabriel1@virebent.art</email>
</author>
<published>2026-07-03T13:51:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.virebent.art/virebent/nymdrop/commit/?id=4fd6b4fefa7243f68fae7e24df3da46ee1a8e356'/>
<id>urn:sha1:4fd6b4fefa7243f68fae7e24df3da46ee1a8e356</id>
<content type='text'>
The old 10MB cap was checked against the wire body, but two base64 layers
sit between the raw file and that body: crypto.js base64-encodes the file
before AEAD encryption, then nym.Client.Send base64-encodes the ciphertext
again to embed it in the JSON sent to the local nym-client over its control
WebSocket. A file at exactly the old cap produced a wire body just over the
limit after the first layer, and would have blown nym-client's own hardcoded
16MB WebSocket message limit after the second, surfacing as an opaque 500.

Lower the wire-body cap to 11MB, which keeps the second base64 layer with
real margin under nym-client's 16MB ceiling. Effective safe raw file size
is now roughly 8MB, not 10MB.

Reported by Ch1ffr3punk on nym.forum, reproduced with an exact 10MB file.
</content>
</entry>
<entry>
<title>Initial public release: Nym-native anonymous submission system</title>
<updated>2026-06-20T01:07:45+00:00</updated>
<author>
<name>Gab Virebent</name>
<email>gabriel1@virebent.art</email>
</author>
<published>2026-06-20T01:07:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.virebent.art/virebent/nymdrop/commit/?id=aa459e3b84cc4c5d908f3781c9253848c18640c3'/>
<id>urn:sha1:aa459e3b84cc4c5d908f3781c9253848c18640c3</id>
<content type='text'>
End-to-end verified pipeline (browser -&gt; HTTP relay -&gt; Nym mixnet -&gt; reader).
Client-side X25519+HKDF+AES-GCM-256, no-log blind relay, AGPL-3.0.
</content>
</entry>
</feed>
