Improve the first game to configure the number to guess by using the "terms" about documentation HOT 7 CLOSED

First part is easy

Second part is a bit tricker. It seems like currently the web part of cosmic-swingset is setup in a way that only one port is open and this is the only user interface taht can discuss with the solo-node. There also seems to be only a single solo-node setup while maybe there should be one for the person setting up the contract and one for the player

from documentation.

• Amethyst sets up the contract. It produces a game object and a handoffService
  => This is done via Amethyst's solo node
• Amethyst produces a corkboard using the handoffService
  => This creates a URL like https://example/corkboard/ng2oeg938vEgpoj9U (random at the end)
• Amethyst puts the guess function of the game as the "guess" key of the corkboard
  => The message can be retrieved via https://example/corkboard/ng2oeg938vEgpoj9U/guess
• Amethyst shares the url with Pearl
• Pearl opens the game (how?), then puts the url in a dedicated field
  => The url is sent to Pearl's solo node
  => Pearl's solo node retrieves the function and exposes it to UI
• Pearl plays the game

from documentation.

The framework seems right, but this mis-states how handoffService and corkboard work. I think your idea about events and notification (https://github.com/Agoric/ERTP/issues/112) is a good one, but it's not at the top of our list yet. In the meantime, people can use the handoffService to get a corkboard, which provides a 2-way connection. Amethyst stores an invite for the guess facet in the corkboard, and tells Pearl (out-of-band) what key she filed it under.

Pearl redeems the invite for a seat, and sends .guess(284) to it.

from documentation.

Ok, thanks for the feedback!
Things are getting clearer and clearer. New attempt:

• Amethyst sets up the contract. It produces a guessInvite object and a handoffService
• Amethyst produces a corkboard named "invites" using the handoffService (const corkboard = handoffService!createBoard("invites"))
• Amethyst puts the guessInvite as the "guessInvite" key of the corkboard (corkboard!addEntry("guessInvite", guessInvite))
• Out-of-band (maybe via a meeting or on the phone, or email or Signal, or Wire or whatever), Amethyst tells Pearl that the handoffService has a corkboard named "invites" and she can retrieves the game invite via the "guessInvite" key
• Pearl retrieves the invite (const invite = handoffService!grabBoard("invites")!lookup("guessInvite"))
• Pearl redeems the invite (const game = contractHost!redeem(invite))
• Pearl can now play the game (game!guess(298))

One thing that isn't clear to me is how Pearl has access to the handoffService and the contractHost
Are these objects supposed to be public?
How can Amethyst make these objects public?

from documentation.

The handoffService is in the initial endowments for every client of Cosmic Swingset. It's written up in that README.

The ContractHost should be treated the same way, I think. It's just an oversight that it's not already accessible. We didn't need it for any of the demos we've tried to date. I'll look into getting it added cleanly. It's certainly intended to be a widely-available capability.

from documentation.

The handoffService is in the initial endowments for every client of Cosmic Swingset. It's written up in that README.

I understand it is part of the initial endowments of every client of the Pixel Demo, but it's less clear to me that it's part of every client of Cosmic Swingset (which i interpret as "any contract that can run with Cosmic Swingset, not just the Pixel demo")

The fact that the handoff service is created in the same conditions than the gallery made me think that it's part of only the Pixel demo and not a necessary part of the smart contract choregraphy

But thinking about designing multi-participant contracts, i realize that a multi-participant secure smart contracts cannot happen realistically without an handoff service. That's because without a handoff service, there is no secure sharing of invite.
If secure smart contract cannot happen without a handoff service, then should the handoff service be part of ERTP core, and not just more? (unlike the Pixel demo which is really just an example)

[ContractHost] is certainly intended to be a widely-available capability

Do you mean "public"? (in the sense that anyone with access to the blockchain can communicate with it)
If not, i see a boostraping problem to redeem invitations

from documentation.

I think we agree that people will need the ability to share links and capabilities in order to get anything done, but we imagine that there will be a more sophisticated matching service. We may fall back to providing the handoff service, but we'll try to think of something better to allow users and programs to get in touch with one another.

from documentation.