44 karma · joined February 22, 2025
This isn't true. Particularly, if an attacker attempts to connect with the wrong password, this will be seen by the client, which then aborts the connection. So an attacker can only try one password. You can test this yourself:
A: $ wormhole send foobar
A: Wormhole code is 1-whimsical-klaxon
B: $ wormhole receive 1-klaxon-whimsical # wrong password
B: ERROR: Key confirmation failed. Either you or your correspondent
B: typed the code wrong, or a would-be man-in-the-middle attacker guessed
B: incorrectly. Try sending the file again.
B: <exit>
A: ERROR: Key confirmation failed. Either you or your correspondent
A: typed the code wrong, or a would-be man-in-the-middle attacker guessed
A: incorrectly. Try sending the file again.
A: <exit>
So if you receive this error (potentially repeatedly), you learn that there is an attacker trying to guess passwords. You can then choose to increase code length or simply stop using that channel.The CLI also has an option to further mitigate MITM attacks with the `--verify` flag -- this shows to both clients a hash of the transcript, which can be verbally verified before proceeding with the transfer. This allows detecting an attack even if the attacker gets the password right on the first try (which has probability 1/65536).
Yes; you can take the producer side of an `N32` wire `x` and link it to the consumer side of an `N32` wire `y`; that just means that the value that is sent across `y` will be sent across `x`.
> Should ~ be considered part of the type signature? Does `let ~x = y` work as destructuring?
In `let ~x = y`, the `~` is part of the pattern, and is destructuring, yes. So assuming `y` is some `~N32`, that statement declares a new variable `x`, with no initial value, and whatever the final value of `x` is, that's what passed along the wire. So re: what happens when a variable is assigned more than once, the last assignment wins.
IVM is architecturally similar to HVM-64 (which I was the lead developer of). The most major difference is how they handle IO. IVM uses its extrinsic system, where all side effects are mediated through an IO handle, which provides a number of useful properties, and is greatly simpler to implement / use. Interactions with side effects are small and low-cost, and can happen in parallel with the rest of the program.
HVM-64 had built-in net definitions that had side-effects when expanded, which was very messy to use in practice. HVM2 has a monadic IO interface, which requires stopping the whole program on every single IO call. (And also requires writing things monadically.)
Using extrinsics for IO handles in IVM creates a very nice API for IO in Vine; side-effect-ful functions simply take a mutable reference to the IO handle. It's also very easy to support multiple 'threads' of parallel IO effects – simply duplicate the IO handles.
In that context, then, the inverse operator switches which side of the wire you're talking about. If you have a parameter of type `N32`, you're on the 'consumer side'. But if you have a parameter of type `~N32`, that can be viewed as being the 'producer side' of an `N32` channel. Since `~` just swaps the sides, `~~T` is the same as `T`.
Of course, the intrinsic parallelism is useful there (especially since it is emergent from the structure of the program, rather than needing to be explicitly written). In terms of other interesting properties: interaction nets don't rely on linear memory, instead being based on a graph, which can naturally be chunked and distributed across machines, with synchronization only being necessary when wires span different chunks.
> And synchronization primitives?
The initial answer to this question is: interaction nets don't need synchronization primitives, as all parallelism is emergent from the net structure.
Now, in practice, one may want some additional synchronization-esque primitives. For example, a parallel shortcircuiting or is not expressible in vanilla interaction nets (as all computation is deterministic, and such an operation isn't deterministic). There are extensions to interaction nets for non-determinism, that allow some of these use-cases, which start to look more like synchronization primitives. Vine doesn't support any of these at the moment, but it may in the future.
> I wanted to also say I loved reading the documentation. Your idea of places, spaces and values feels like a waaay more intuitive naming scheme for than what's common in CS.
I'm glad to hear it! I spend a lot of time trying to come up with good names for things, so it's nice to know that that pays off. Though I suppose it's not too hard to improve on the status quo, when it's 'lvalue'/'rvalue', lol. (I did, however, steal 'place' and 'value' from Rust.)
> The time-travel example also felt oddly intuitive to me. I don't really care that it uses black magic underneath, it's quite elegant!
Yeah, the 'time-travel' stuff sounds wacky, but I do think it can be really intuitive if one is willing to accept it. I wrote a really cool algorithm a little while ago that really uses this 'time-travel' idea; I [wrote about it](https://discord.com/channels/1246152587883970662/12461564508...) on Discord. (I should really type that up into a blog post of sorts.
Interaction nets are an alternate model of computation (along the lines of the lambda calculus or Turing machines). It has several interesting properties, one of the most notable being that it is fundamentally parallel. https://en.wikipedia.org/wiki/Interaction_nets https://t6.fyi/guides/inets
I think there are many potential applications for interaction nets in parallel & distributed computing, among other fields; and such applications will need a language – hence Vine.
(re your edit – that's fun lol; Totally Cubular is one of my favorite projects)
Yes, this is correct. Though it's worth noting that this is not some transformation being done by the compiler, but an emergent property of the interaction net.