agoric-labs / playgroundvat Goto Github PK

At the moment, code loaded into a Vat must use log() to emit message to the host's stdout, rather than console.log(). This is annoying, and we should fix it.

It's non-trivial because something (maybe rollup) is rewriting the word console, and each time I try to create an endowment by that name, the vat code can't find it. I don't think this is impossible, but so far it's taken more time than I've had to find a fix.

Github has an archiving feature

This makes the repo read-only. Example in one of my repos : https://github.com/DavidBruant/OoI

Hi Agoric Team!

Congratulations on your PoC Release 👏🏽👏🏽👏🏽. We were very excited when we saw the announcement and extra to see that you decided to give libp2p a try and wrote down some very useful notes on issues that you are hitting.

Following up on your notes:

However js-libp2p is missing a lot of features that the flagship Go implementation provides. One feature we would like is the DHT that disseminates host addresses.

This has been a long time coming and one that we are close to the finish line -- https://github.com/libp2p/js-libp2p-kad-dht/.

@vasco-santos and @jacobheun have been solving some last mile interoperability issues with the go-ipfs implementation and testing it on larger networks to make sure the implementation is sound. This is one of the big priorities for Q4 2018.

You can see how to activate it at -- https://github.com/libp2p/js-libp2p/tree/master/examples/peer-and-content-routing -- and experiment with it. Feedback and bug reports are welcome!

We might address this with embedded address hints, "redirectories", and/or by running a central server that can distribute address information.

If you use the WebRTC transport we have available, you will be using this central point (aka rendezvous) that provides an exchange for SDP offers and automatic Peer Discovery.

You can check the example at -- https://github.com/libp2p/js-libp2p/tree/master/examples/libp2p-in-the-browser -- to try it out.

Note: If you need WebRTC in Node.js, there is also a module that can be used and libp2p knows how to use it -- https://www.npmjs.com/package/wrtc --, however, it isn't the most stable thing yet.

Closely related to this is the NAT-bypassing relay behavior that allows IPFS servers to work behind firewalls. The consequence of this being absent from the JS port is that Vat nodes behind a firewall will not be able to accept connections from other Vats outside that firewall. Once a connection is made, it is used for messages in both directions, so certain topologies will work anyways.

We need to prioritize TCP hole punching (hint @jacobheun, @vasco-stantos). Until, there are two other ways to pierce through NATs, either using the WebRTC transport (which uses NAT hole punching natively) and/or use libp2p Circuit Relay.

We have a full tutorial on how to use it inside the js-ipfs examples folder, but it is an actual js-libp2p feature.

js-libp2p defaults to using (2048-bit) RSA keys for the node identities, which is adequate, but I'd prefer Ed25519 elliptic-curve keys, which are smaller and much faster. We may rewrite VatTP to use an entirely different wire protocol, in which messages are individually encrypted and then signed (so the signatures could be checked by third parties). In that case, the transport-layer encryption would be redundant, and we wouldn't care so much about the details.

We've been wanting to support Ed25519 Keys for a while (in fact, js-libp2p started with Ed25519 keys and then later changed to RSA to match go-libp2p/go-ipfs). We haven't prioritized this as it would be a significant change for the IPFS network that we have to plan for, however, we can totally add support for these in js-libp2p and let other disjoint networks use them.

@vasco-santos, @jacobheun, let's chat about this and see if we can make it happen this quarter.

The networking code currently brings up connections on demand: the TCP connection for each target host is initiated as soon as the first outbound message is generated for that host. An additional one-second loop is used to retry any failed connections. This is a bit too aggressive, and should be changed to use an exponential backoff algorithm, with random jitter to avoid the "thundering herd" problem.

Agreed, this should be configurable. Our dialer has been going through a refactor recently. @jacobheun, can you look into this?

In addition, until we have ACKs, we will try to make a connection even after all the messages have been delivered. Status messages are displayed to stdout each time the loop runs, making the console somewhat noisy (but we should display at least one message when the connection fails, to help diagnose problems).

I'm not 100% sure if I understand this point . Is this specific to the libp2p internals or your own wire protocol over libp2p?

Thaaaank you so much for this report ❤️ It is super useful for us to learn what are the pain points of our users. It helps us make better prioritization. If you don't mind, we can continue using this issue (or other issues) to keep the conversation going and let you know when this situations have been solved.

Also, feel welcome to join the libp2p our channels (GH, IRC) to report issues or chat with the js-libp2p team. @vasco-santos, @jacobheun and I have been planning our goals for Q4 and we are still on time to incorporate some of the needs here.

bob ! foo(carol)

is an eventual send using the proposed infix bang syntactic sugar. It needs to expand to something. For present purposes, we also need to write out code without sugar. The expansion currently supported by this repository

Vow.resolve(bob).e.foo(carol)

serves neither of these purposes well. For manually written code, I suggest

E(bob).foo(carol)

where E is equivalent to

function E(target) { return Vow.resolve(target).e; }

We have PRs for:

all files

Changes are merged for:

All files 🙌

Many tests will appear to fail if the user has an old version of node installed (pre 10?). Please add a unit or configuration test to report that accurately when they run npm test rather than appearing to have a lot of failing tests.

This article describes variants of how to do this, but adding an appropriate tape test might be the most convenient.

Once SES has a way to ask for a require() global (https://github.com/Agoric/SES/issues/51), and it is wired into copies of Nat and def/harden, we can change all the Vat code (as well as the examples and contract tests) to use require(@agoric/nat) instead of a global Nat object.

Dean pointed out it'd be a lot easier to play with this if we had a docker container that included the right/recent version of Node and the dependencies pre-installed.

https://github.com/Agoric/SoloVat/blob/e693aa5d71df6b475c1d59625174e9a026cd4b6c/examples/contract/makeAlice.js#L61

In the bugForDean branch, here's another bug from me: This line makes the .moneySrcP into a payment rather than a purse. However, the refund behavior of the escrow deposits the refund back into it, which will fail because it doesn't have a .depositAll method.

Likewise with .stockSrcP in makeBob.js

Attn @dtribble

While we process an inbound message, we want to detain all outbound messages until the turn has ended. At that point, we write out a checkpoint, then release the messages. With our current "output-transcript" scheme, we'll write the message bodies to the transcript as they are generated, but we won't write a "end of turn" message until everything has settled down. The next time the vat comes up, as it reads the input transcript, it will ignore any lines that aren't followed by an end-of-turn message, so end-of-turn serves as our checkpoint marker.

But how can we know that everything has settled down? There may be an arbitrary number of turns scheduled by the target method.

I'm thinking that Node's IO queue priorities might help. Hopefully it drains the pending-Promise queue before it goes to the IO queue for more work. If so, then when we've finished running the inbound message, we set a flag to put us into the "flushing" state, then we write a byte to a pipe-to-self. When that pipe becomes readable, we move to the "flushed" state, write the end-of-turn marker, and release the outbound messages. We need to not process any inbound messages while we're in the "flushing" state, so the transition to "flushed" must also examine the input queue for work that was deferred earlier.