Marshall overall takeaway

1. phil seemed engaged and asked good questions. he talked about technical stuff in a kind of "vague agreement" way that makes me think he doesn't have a super crisp understanding of what he is talking about. however i get the impression that he will hack together something working, even if it's a little messy. having demo of bot responding ready signals interest in the job.
   1. I would hire him to do this and see how it goes
2. my other takeaway: twitch bot seems to have UI challenges, but i believe you salty if you say that you don't think it's important to have the betting be super tight and people can just have fun with it

David takeaway

1. A bit less convinced the initial prototype would be worthwhile to use over Twitch’s integrated betting. Probably would be “just as good” which isn’t good enough.
   1. Main upside is being able to leave the question open for the whole event with our AMM, not sure if most people care though. (another small upside is viewers can go to our site and make questions and have multiple bets going at once)
   2. Twitch streamers really care about trying to find ways to engage with their communities when offline. There is still a big use case for Manifold with respects to this.
2. Still worth making, even if just as a marketing tool from a first prototype
3. If we can make Mana be more valuable (redeem it for subs etc) then becomes significantly more interesting

• [p] asked about our monetisation strategy
  • [d] Not too focused on that, mentioned people buying mana and us holding it. We have plenty of funding and aim is user acquisition, Twitch bot is a fun game that increases engagement with our product
• Research phil has done which presents limitations of a bot
  • Can’t send dms unless partnered bot (no easy work arounds), restricted to global chat
    • Apparently hard to get a bot partnered?
  • Twitch chat rate limits
    • Image of rate limits (100msg per 30seconds shared across everyone using the bot)
    • Bot can still read all the messages without limits
    • Won’t be a problem for now
    • Might just not give feedback messages saying a user’s bet has been successful, instead show that through the onscreen betting history and when the market resolves by mentioning all the winners in one grouped message.
• Phil demoed his example. He showed that he had an OBS overlay working with some interactive demo data and he had a bot responding to chat commands. He hasn't actually integrated with the API yet.
• We talked about hosting the bot.
  • [M] suggested that he didn't know how we would implement a bot using our existing serverless function infrastructure, and we probably had to host it in some new way.
  • [P] broadly agreed and thought we would have to have a server with a web socket open somewhere.
• We talked about betting latency and failures for a while. Phil had reasonably good questions.
  • [M] explained to him that we couldn't handle much throughput right now, but if it becomes a problem, we could probably move it to a more scalable implementation in a few weeks.
  • [d] The delay from a streamers upload to arrive on a viewers screen is a few seconds anyways which could make Manifold latency more negligible
• We talked about finding out what happened with your bet, if we don't necessarily have the bot throughput to make a confirmation message with every bet.
  • SirSalty mentions that on resolution you could post a big message saying who won and who lost. I suggest that perhaps the overlay should be designed as a place you can look after your bet to see what happened.
• SirSalty pointed out that with Twitch's existing system, the "rush at close" is driven by the fact that odds aren't locked in.
  • [M] pointed out that in our system, we will instead get a "rush on news", so still a rush, but at different times.
• SirSalty: All these things are good to think about but I don't think we need to worry. I think they can become part of the fun.
• Phil seems satisfied and thinks he can basically make a good prototype of this in a week. Is happy to agree to a fixed rate in advance. If further optimisation, building an actual Twitch extension, updates/maintenance needs to be done would need to look at whether we do that internally or have Phil do more work on some sort of hourly rate.
• Phil is flexible right now and has no constraints regarding other projects/work. Could change though so would like to hear back asap
  • [d] Said we would try to get back to him Tuesday/Wednesday at the latest

Twitch integration