meejah

Here are some fairly simple examples: testing port parsing https://github.com/meejah/fowl/blob/e8253467d7072cd05f21de7c...

...and https://github.com/magic-wormhole/magic-wormhole/blob/1b4732...

The simplest ones to get started with are "strings", IMO, and also gives you lots of mileage (because it'll definitely test some weird unicode). So, somewhere in your API where you take some user-entered strings -- even something "open ended" like "a name" -- you can make use of Hypothesis to try a few things. This has definitely uncovered unicode bugs for me.

Some more complex things can be made with some custom strategies. The most-Hypothesis-heavy tests I've personally worked with are from Magic Folder strategies: https://github.com/tahoe-lafs/magic-folder/blob/main/src/mag...

The only real downside is that a Hypothesis-heavy test-suite like the above can take a while to run (but you can instruct it to only produce one example per test). Obviously, one example per test won't catch everything, but is way faster when developing and Hypothesis remembers "bad" examples so if you occasionally do a longer run it'll remember things that caused errors before.

I am not a cryptographer, but can explain that Magic Wormhole uses SPAKE2 to negotiate a shared secret (RFC9382 claims equivalent to gap Diffie-Hellman), and then uses NaCl SecretBox to symmetrically encrypt all data between the peers.

(If using the newer Dilation protocol -- which is true for many of the non-file-transfer tools like ShWiM, Git-WithMe or Fowl -- peer traffic uses this shared secret with Noise, specifically "Noise_NNpsk0_25519_ChaChaPoly_BLAKE2s")

One tool that does now use Magic Wormhole for "introduction" like this is EtherSync: https://ethersync.github.io/ethersync/

Correct.

It does learn some metadata: the endpoints of the messages (unless you use Tor) and the number of bytes in those messages.

...and also "Git-WithMe" for peer-to-peer, one-off Git usage: https://sr.ht/~meejah/git-withme/

Note, too, that you may run your own "transit helper" (code: https://github.com/magic-wormhole/magic-wormhole-transit-rel... ) and then specify this via "wormhole --transit-helper tcp:<your host>:<port>" when doing a transfer.

You do need to run the helper on a public IP address, like a rented VPS for example.

You should probably first test and ensure that you're sending "directly" instead of via the relay -- but if that's true then yes.

One use-case could be for SyncThing to actually _use_ magic-wormhole as a way to introduce / join another endpoint to a SyncThing folder.

There are Rust and Haskell implementations too (not quite as feature-full as the Python code yet, though) as well.

In principal WebRTC communication could be added to magic-wormhole, but that work has not been done yet. There is WebSocket support in the relay (including "cross-protocol" so one client can be WebSocket and the other TCP). This is only deployed on the Winden.app servers (tcp://relay.mw.leastauthority.com:4001 and wss://relay.mw.leastauthority.com for the relay).

You'd need to use the Winden.app relay server if you want https://winden.app users to reach your Python CLI (e.g. via "wormhole --relay-url wss://mailbox.mw.leastauthority.com/v1 send" for example)

You might even use Magic Wormhole to securely transfer WireGuard keys!

There are several different clients available for Magic Wormhole, including GUIs and phone apps: https://magic-wormhole.readthedocs.io/en/latest/ecosystem.ht...

If two Magic Wormhole clients _are_ on the same LAN they should communicate directly that way (i.e. no relay required).

Yes, there are several alternative clients including several for Android: https://magic-wormhole.readthedocs.io/en/latest/ecosystem.ht...

Building on top of various Magic Wormhole features, "shwim" enables quick and easy 1:1 terminal sharing with durable, end-to-end-encrypted communications using tty-share.

Yes, all the implementations speak the same wire protocol.

The Python implementation has the most features. More about which implementations support what features is here: https://magic-wormhole.readthedocs.io/en/latest/ecosystem.ht...

The Haskell implementation uses the same protocol as the Python implementation. The main difference is that there are some features the Python implementation has that the Haskell implementation still lacks (most notable "Dilation").

See also https://github.com/magic-wormhole/magic-wormhole-protocols/

That is just using normal STUN/TURN via another server that one of those developers is running

Yes, it does -- via the Rust implementation.

There's also a Haskell implementation (besides the Go one pointed out above). They all interoperate.

There is also https://magic-wormhole.readthedocs.io/en/latest/ecosystem.ht... and if that is lacking anything please file a ticket or pull-request

Yes.

A technique like this is used to do "invites" in Magic Folder, and also in Tahoe-LAFS. That is, they speak a custom protocol over just the Mailbox server in order to do some secrets-exchanging. They never set up a "bulk transport" link.

There is also a Haskell implementation, if that's of interest.

I love to learn about "non-file-transfer" use-cases for Magic Wormhole, so please connect via GitHub (or https://meejah.ca/contact)

I think Pond had better-thought-out decoy traffic https://github.com/agl/pond with a statistical design and clients would always upload and download the same amount of data (so it was very hard to determine if they "got a message" or just checked and didn't get a message).

Yes, inter-packet timings are unfortunately pretty good at holding information. (e.g. https://www.freehaven.net/anonbib/cache/stepping-stones.pdf )

Note that Tor doesn't have "global passive adversary" in the threat-model (i.e. an actor that can monitor traffic entering and leaving the Tor overlay).

There is a Web client at https://winden.app (although it uses different servers than the defaults in the Python CLI, the latter can be easily configured to use the same servers).

However, see further discussion in this article about the difficulties of Web / JavaScript security in this context (i.e. you're depending on the people operating the Web server to not serve different JS on each and every visit).

"Without needing a server" but both parties have to visit a Web ... server ... to do the exchange. So there _is_ in fact "a server in the middle".

For sure making the _process_ public is a big plus!

(All companies should make their hiring process transparent and public).

Yes, I was making a more general comment (I think it does still apply whether there's actual code-exercises or not though).

If it's "too much work" for you, might be time to re-examine how much work you're asking for.

I also think these sorts of things select for candidates that have lots of time for "applying to places" (which will naturally select against people already in jobs, or who already value work/life balance).

Your process doesn't look as onerous as some I've seen for sure -- but perhaps you _should_ add a "screen" portion and thereby not ask for the "long form" work from candidates you'd reject anyway (also buying more time for meaningful feedback to those you do ask the work of).

Yes, 100%

Also, if "everyone" has a 1 hour interview (or whatever) then you're more-or-less comparing equal things. If some people use a week to craft their "asynchronous" responses while some have an hour to do so (because they're already employed, say, or have a family) then you're not comparing apples to apples.

Similar for "take home code exercises": it's impossible to compare them meaningfully because you have no idea if the better-looking one took the candidate an hour or several days (and yes, I've been on both sides of this).

If someone demands hours of free labour for "code exercises" or whatever, the absolute bare minimum is that you put some portion of that back into meaningful code review.

So you should probably be spending _more_ time on the feedback for rejected candidates. Be specific, tie it back to your evaluation criteria that you wrote down before asking for the exercises to be completed.

https://winden.app is a Web client

"Destiny" is an Android and iOS client https://github.com/LeastAuthority/destiny/

(These two use servers run by Least Authority by default so to talk to other clients you have to configure Destiny to use the defaults, or the other side to use the non-default servers).