Noel/libp2p entrypoint

[kwannoel]

Implement Barebones of: #106.

Run buy_sig over libp2p

To run the buy_sig interaction over libp2p, in one terminal run:

a_addr=/ip/127.0.0.1/tcp/10333
./glow start-interaction -O $a_addr -E pet -C libp2p -W

You will be prompted:

Starting libp2p client
I am /ip4/127.0.0.1/tcp/10333/ipfs/<PeerId>
...

Copy that into dest in the second terminal, and run:

b_addr=/ip/127.0.0.1/tcp/10300
dest=/ip4/127.0.0.1/tcp/10333/ipfs/<PeerId>
./glow start-interaction -O $b_addr -C libp2p -E pet -D $dest --database alice

Select the relevant options to run the buy_sig interaction.

Run the buy_sig over libp2p test case locally

./unit-tests.ss test t/buy-sig-libp2p-local-integration-test.ss

Progress

• Use user-supplied keypair to derive peerid.

  • Supply user keypair to daemon via gerbil-libp2p.
    • Figure out where to pass this option to go-libp2p-daemon via gerbil-libp2p.
      See: Noel/libp2p entrypoint #398 (comment)
    • Extract privatekey using methods from gerbil-ethereum/known-addresses.ss.
    • Convert privatekey into protobuf format.
    • Store protobuf into file.
    • Pass filename to libp2p daemon using options: ["-id" filename].

• Backend support and CLI to ensure the go-libp2p-daemon and/or JS library is started with the correct parameters (toggling libp2p, keypairs).

  • Update CLI start-interaction entrypoint to take in an option, which toggles off-chain communication between stdout and libp2p.
  • Q: Should the off-chain channel be part of the agreement?
    A: No, it is determined before the agreement itself,
    Since it specifies the channel through which the agreement is sent.
  • Store this into runtime object.
  • Add a wait-for-agreement flag, which waits for other party to supply interaction agreement.
  • Initialize libp2p-client

• Backend support and CLI to send and receive handshakes and agreements.

  • Parameterize outgoing message handlers over channel.
  • Parameterize incoming message handlers over channel.
  • Stub handlers for outgoing messages over libp2p
  • Stub handlers for incoming messages over libp2p
  • Listen for handshake / agreements
    • Persist listening thread
    • store things in a buffer
      • store, push for buffer.
    • store this message buffer in channel object
  • Implement outgoing message over libp2p
  • Implement incoming message over libp2p

Polishes

Priority

• Purge keypair file once client has been initialized.
  - [] Randomly generate keypair file.
• Review and cleanup code (FIXMEs, TODOs, repeated parts).
• If alice starts first, poll until bob comes online.
• Cleanup output
• Documentation
• Write integration test (buy_sig).

[kwannoel]

How to initialize libp2p daemon with participant keypairs

See https://github.com/libp2p/go-libp2p-daemon for installing p2pd, p2p-keygen.
Use the -id flag to configure private-key when starting daemon:

p2pd -id <private_key_file>

Use the following command to generate sample private keys:

p2p-keygen -f <private_key_file

[zenhack]

Some comments in-line. Seems reasonable at a high level.

[zenhack]

I think the fixme could stand to be spelled out a bit more; what exactly needs to happen? (It looks like there's something related in the finally block).

[kwannoel]

Was already fixed in the finally block, forgot to remove the FIXME.
Have removed it.

[zenhack]

Should probably add urlsafe?: #t here; default base64 can include slashes.

[kwannoel]

Removed this function (make-libp2p-socket-path), it has become obsolete.
For future reference, if I were to use u8vector->base64-string, the urlsafe option can be found here: https://cons.io/reference/text.html#subu8vector-base64-string

[zenhack]

The variable name c seems like an odd choice here; maybe something more descriptive?

[kwannoel]

Updated.

[zenhack]

In general, use hash-ref instead of hash-get unless you actually want it to return #f if the key is not present (hash-ref throws an exception). This has been the source of more than one bug in the past.

[kwannoel]

Updated. Thanks!

[zenhack]

There are a couple things wrong here:

• Conceptually, this is really supposed to be doing shell escaping; it has nothing to do with json per se.
• More importantly, it does not correctly escape things for the shell. E.g:
  • "$(rm -rf /) ''" would be passed through unchanged, since it contains a single quote.
  • If you got rid of that first case, then "'$(rm -rf /)'" would still slip by the escaping in the second case; due to the way shell escaping works, you can unquote back into an interpreted context. So you also need to substitute out any single quotes in the middle of the string.

[kwannoel]

Renamed this function to be more specific, and added your remarks inline as a TODO, before this can generalized as a way to shell-escape json strings.

[zenhack]

This could do with a link to some relevant documentation; this all seems very magical, not knowing a-priori much about the protocol.

[kwannoel]

Added more documentation, thanks for pointing this out.

[zenhack]

Should probably just get rid of commented out code like this (and similarly in chat-handler below).

[kwannoel]

Removed

[zenhack]

Should not leave code commented out like this.

[kwannoel]

Removed

[zenhack]

I'm kindof wary of continuing to copy & paste the bulk of the logic for these integration tests; it might be prudent to try to factor some of this out into a function.

[kwannoel]

Refactored the boilerplate for setting up the test environment into a function. The other areas seem to be specific to the integration test itself (options we pass in etc...)

[zenhack]

A more direct way to print the executed commands would be to just pass -x to the shell.

[zenhack]

A couple more minor things, but this mostly looks reasonable to me.

[zenhack]

These lines are very long and it makes it hard to read; maybe wrap them, with one key/value per line?

[zenhack]

You seem to have lost part of this sentence.

[fare]

What does the conversion from string to symbol?

[fare]

maybe validate that?

[bennewhall]

I was having issues running this initially, however it worked when I did
a_addr=/ip4/127.0.0.1/tcp/10333
and
b_addr=/ip4/127.0.0.1/tcp/10300

I think something having to do with /ip not being a protocol