3.1 Use AI for HTML

Because this is a browser-based system, some of your code will me in languages we have not taught you (HTML, CSS, and JavaScript), and will not be testing your learning of course concepts. As such, we recommend having AI create these files for you.

Other tips here may mention HTML and JavaScript concepts, primarily to give you vocabulary to use when talking to the AI.

3.2 Sessions

A booth server will need to connect multiple HTTP requests into a single session. At a minimum, these are (a) the initial GET / that loads the game UI and (b) the player’s action in the booth after they pay their tickets.

One way to do this is to have identifying information (such as the memo) included in each subsequent HTTP request the player makes. That would look something like

• GET / would return an HTML page that has the memo included.
• Each user action results an HTML request that includes the memo, such as by using <input type="hidden" value="the memo"> inside an HTML form or adding the memo to the JSON object sent in a fetch.
• The user actions go to POST endpoint that checks the memo.

You can also use other identifying information instead of the memo, such as the hash of a block providing a ticket transfer from which the memo can be extracted.

Another way to implement sessions is to have only one normal HTTP request, then open a WebSocket and have all subsequent information use that. We have a desciption of WebSockets available if you are interested.

3.3 Telling the user where to send tickets

The user will need to send tickets to your booth using their wc_agent.py from MP10. That means they’ll need 3 pieces of information:

1. Your booth’s account name (which is your NetID followed by _b)
2. How many tickets to send
3. The memo to include in the payment

One way to send this kind of information to the user is to have a static HTML file with placeholder strings like BOOTH inside of it, and then in your @routes.get("/") callback use str’s replace method to replace those parts of that static HTML file for the current user.

Another way to send this kind of information is to have the HTML file use fetch or WebSockets to ask for this information from a separate booth endpoint and then add it to the webpage.

3.4 Learning if the user sent tickets

There’s no easy way to query the blockchain to discover if there’s some block with a given dst and memo: you could get the entire /chain and search every block, but that will become time-prohibitive as the blockchain grows.

We recommend that the booth have the user tell the booth the hash of the block that provides the payment. The server can then use /getlive to verify that that block is a precursor to the head and has the correct fields.

This idea would suggest a user experience that includes having two browsers open, with some back-and-forth action between them:

3.5 Booth communication with blockchain

Your booth will need to create blocks on the blockchain. This should be done as follows:

1. Run bc_agent.py from MP10 on the same server as your game.

2. In game.py,

   1. Load the booth name, passcode, and port from the private config file used by bc_agent.py.

   2. Create an HTTP client that uses the bc_agent.py’s host and authentication information, as follows:

      auth = aiohttp.BasicAuth(login=USER, password=PASS)
      client = aiohttp.ClientSession(f'http://localhost:{PORT}', auth=auth)

      where

      • PORT is the port on which bc_agent.py is running
      • USER is the booth name
      • PASS is passcode associated with that booth name

      We recommend doing this just once, during asyncstartup, and storing the resulting client inside app, as e.g. app["client"] = client. You can then get to the client from other methods using request.app["client"].

   3. To send tickets, use that authenticating client to send a POST request to the /transfer endpoint, as follows:

      async with client.post('/transfer', 
          json={'dst':PLAYER, 'n':AMOUNT, 'memo':MEMO}
      ) as resp:
          data = await resp.json()
          if 'error' in data:
              ... # the transfer failed; is bc_agent.py running and the USER/PASS correct?
          else:
              ... # the transfer succeeded

Some of this code is provided in the starter code, though you are free to modify it if you wish.

3.6 Testing your game

To test your game, you’ll need at least three concurrently-running aiohttp apps: two blockchain agents (one to be a player, one to be the booth) and your game:

• python3 bc_agent.py -v configs/priv_user1.json (the player’s agent)
• python3 bc_agent.py -v configs/priv_user2.json (the booth’s agent)
• python3 game.py -v ../mp10/configs/priv_user2.json (the booth’s UI)

You’ll also need at least two browsers open: one to the player’s bc_agent.py page https://localhost:34010 and one to your game https://localhost:20258. It might be nice to also having open a blockchain viewer https://localhost:34010/view and refresh it periodically to ensure the correct blocks are being added to the blockchain.

You’ll then need to follow the back-and-forth activity outlined above. If the result is a game with blocks being added