<p>The answer might have been no by the time you asked, but now it is yes: Check out <a href="http://you-say-first.nomeata.de/" rel="nofollow"><strong>You Say First!</strong></a></p>

<p>I tried my best with the UI design, but any help there is welcome. Bugreports and feature requests can be submitted on <a href="https://github.com/nomeata/you-say-first" rel="nofollow">https://github.com/nomeata/you-say-first</a>.</p>

CC BY-SA 3.0
2013-04-30T18:37:15.223Z
Thanks!!! Had a quick try but I guess I am behind the wrong sort of firewall or something. I will have a closer look a bit later. PS: [tic-tac-toe](http://en.wikipedia.org/wiki/Tic-tac-toe) is _not_ another name for [rock-paper-scissors](http://en.wikipedia.org/wiki/Rock-paper-scissors) it is something else entirely, and doesn't need this system :-)
Fool
CC BY-SA 3.0
2013-04-30T20:40:49.777Z
Ah, got them confused, as I am working on formal stuff related to tic-tac-toe at work right now.
Joachim Breitner
CC BY-SA 3.0
2013-05-01T14:20:12.183Z
@Fool, did you get it to work? It was my first attempt to use Meteor; I don’t know how well it works in other browsers and stuff.
Joachim Breitner
CC BY-SA 3.0
2013-05-01T16:57:20.970Z
Tried yesterday, it sort of worked, but it's not persistent in the face of disconnection. And from where I am sitting right now, it doesn't work at all. I'll try again a bit later, and give feedback directly to you. Thanks again for doing this!
Fool
CC BY-SA 3.0
2013-05-01T20:55:07.413Z
It works great where I am; would be good to know what fails. For now, it is tailored towards live usage, e.g. where all player keep their browser window open. Oh, and now there is an in-game chat as well.
Joachim Breitner
CC BY-SA 3.0
2013-04-30T15:57:26.977Z
2013-05-01T12:58:39.830Z
2013-05-01T12:58:39.830Z
Joachim Breitner
<p>If it is fine for your to wait up to a specific time, sending delayed mails via a service like <a href="http://www.timecave.com/timecave/new.jsp" rel="nofollow">timecave</a> might be an option (although suboptimal).</p>

CC BY-SA 3.0
2013-04-28T20:20:14.470Z
Thanks. Yeah, if we set a specific time, then timecave would work by itself for 2 players. For multiple players, I guess also create a mailing list, everyone sends a delayed message to that list. Timecave includes the time the message was deposited in a mail header, so we can confirm that nobody deposited a message after any message was sent. Doable...
Fool
CC BY-SA 3.0
2013-04-28T16:07:12.030Z
2013-04-28T16:07:12.030Z
Joachim Breitner
<p>No arbiter is needed if you use encryption. Player A sends encrypted move Am1 to player B. Player B sends encrypted move Bm1 to player A. Once A receives Bm1, she sends the decryption key Ak1 to B, and B sends his decryption key Bk1 to A. This can be done over any messaging service, but does require a bit of overhead. (And you have to trust that the other player sends you valid move data, but you can set up the rules that if the initial message doesn't contain a valid move than the sender loses.)</p>

<p>Simple encryption tools can be found online. For example,
<a href="http://www.alltextencryption.com/" rel="nofollow">http://www.alltextencryption.com/</a></p>

CC BY-SA 3.0
2013-04-24T22:30:45.313Z
Thanks, but this would have the exact same problems as cryptographic hashing, which I already excluded. (1) Player education is one big problem, as I said. (2) "The sender loses" is not a good solution especially in multi-player games, and especially especially Diplomacy. Especially especially especially if the sender might have messed up by accident, see (1).
Fool
CC BY-SA 3.0
2013-04-25T21:36:42.867Z
@Fool: Isn't sender messing up by accident a problem regardless of technique described? How would an independent (hopefully automated) arbiter know whether the move data sent is valid without detailed knowledge of game rules and current state?
Marcin
CC BY-SA 3.0
2013-04-26T05:40:22.540Z
Yes, but you've introduced entirely new ways for a player to screw up. Also, Diplomacy has ways of dealing with partially or completely invalid moves. In the worst case the country goes into "Civil Disorder". Now you might think I could just have CD be the default if a player fails to decrypt his orders, but this is no good, it gives the player the option of either executing his original orders or pretending not to be able to decrypt and go into CD, and the player can get this option _after_ having seen everyone else's orders. This can make a difference!
Fool
CC BY-SA 3.0
2013-04-26T05:47:17.317Z
EG: even if it's not Diplomacy and the rule is "sender loses", if there are more than 2 players it can matter. Say there are three players, and one of them is about to lose anyway. You may be giving that player the choice of losing in two different ways _after_ having seen the other two player's orders, this choice may affect which of the other two wins. The losing player may be secretly colluding with one or the other (such collusion is permitted if not mandatory in Diplomacy), and this option may give the coalition an advantage.
Fool
CC BY-SA 3.0
2013-04-26T05:47:46.913Z
A third, unrelated objection is time: this is a two-phase protocol. Say it is played over email with players on opposite sides of the world. Now we have an extra delay of half a day or so each turn for no good reason.
Fool
CC BY-SA 3.0
2013-04-26T05:48:30.023Z
Long story short, I was aware of cryptography when I asked the question.
Fool
CC BY-SA 3.0
2013-04-24T21:49:16.333Z
2013-04-24T21:54:33.527Z
2013-04-24T21:54:33.527Z
Marcin
<h3>Background</h3>

<p>I am looking to play a variant of Diplomacy over email or other messaging system. The specifics of Diplomacy and of the variant are not important, suffice it to say that the root trouble is simultaneous moves. </p>

<p>Consider scissors-paper-stone as an example: how would you play that over, say, email? 
One possibility is a neutral person. Both players email their throw to the arbiter. He holds the first email until he has received the second, then he forwards each email on to the other player.</p>

<p>This neutral person could be replaced by a computer, as this function is pretty brain-dead. </p>

<p>I am aware there are services for online Diplomacy (and scissors-paper-stone for that matter), but they are specific to that game. The variant I am looking to play is not supported. I am also aware that this could be done using cryptographic hashing, but there are practical issues with that (like player education). </p>

<h3>Question</h3>

<blockquote>
  <p>Is there a simple service that just collects messages from a given list of recipients, and then forwards all messages, unaltered, once it has received a message from everyone on the list? </p>
</blockquote>

<p>This can be over any internet messaging system that would not require too much player education. (EDIT: I meant to include things like web interfaces also, as long as they're easy to use.)</p>

<p>It seems like the sort of thing someone would have already come up with.</p>

CC BY-SA 3.0
2013-04-28T16:00:13.097Z
Would you also need things like automatic time-out if someone does not submit a move?
Joachim Breitner
CC BY-SA 3.0
2013-04-28T16:05:21.490Z
This is also discussed at http://ask.metafilter.com/136502/How-to-simultaneously-exchange-information
Joachim Breitner
CC BY-SA 3.0
2013-04-30T15:32:53.187Z
I coudn’t resist; expect this to exist soon (implemented in Meteor). It is already working, it just needs a lot of UI polishing.
Joachim Breitner
<online><diplomacy>
Abstract "move holding" service for simultaneous-move board games
Fool
# Abstract "move holding" service for simultaneous-move board games

(Asked by: username_0 on 2013-04-24)

### Background

I am looking to play a variant of Diplomacy over email or other messaging system. The specifics of Diplomacy and of the variant are not important, suffice it to say that the root trouble is simultaneous moves.

Consider scissors-paper-stone as an example: how would you play that over, say, email?
One possibility is a neutral person. Both players email their throw to the arbiter. He holds the first email until he has received the second, then he forwards each email on to the other player.

This neutral person could be replaced by a computer, as this function is pretty brain-dead.

I am aware there are services for online Diplomacy (and scissors-paper-stone for that matter), but they are specific to that game. The variant I am looking to play is not supported. I am also aware that this could be done using cryptographic hashing, but there are practical issues with that (like player education).

### Question

> Is there a simple service that just collects messages from a given list of recipients, and then forwards all messages, unaltered, once it has received a message from everyone on the list?

This can be over any internet messaging system that would not require too much player education. (EDIT: I meant to include things like web interfaces also, as long as they're easy to use.)

It seems like the sort of thing someone would have already come up with.

**Tags:** online, diplomacy

> **Comments:**
> **username_1**: Would you also need things like automatic time-out if someone does not submit a move?  
> **username_1**: This is also discussed at http://ask.metafilter.com/136502/How-to-simultaneously-exchange-information  
> **username_1**: I coudn’t resist; expect this to exist soon (implemented in Meteor). It is already working, it just needs a lot of UI polishing.  

---

## 3 answers

### Answer by username_1 on 2013-04-30. Score: 5

The answer might have been no by the time you asked, but now it is yes: Check out [**You Say First!**](http://you-say-first.nomeata.de/)

I tried my best with the UI design, but any help there is welcome. Bugreports and feature requests can be submitted on <https://github.com/nomeata/you-say-first>.

> **Comments:**
> **username_0**: Thanks!!! Had a quick try but I guess I am behind the wrong sort of firewall or something. I will have a closer look a bit later. PS: [tic-tac-toe](http://en.wikipedia.org/wiki/Tic-tac-toe) is _not_ another name for [rock-paper-scissors](http://en.wikipedia.org/wiki/Rock-paper-scissors) it is something else entirely, and doesn't need this system :-)  
> **username_1**: Ah, got them confused, as I am working on formal stuff related to tic-tac-toe at work right now.  
> **username_1**: @username_0, did you get it to work? It was my first attempt to use Meteor; I don’t know how well it works in other browsers and stuff.  
> **username_0**: Tried yesterday, it sort of worked, but it's not persistent in the face of disconnection. And from where I am sitting right now, it doesn't work at all. I'll try again a bit later, and give feedback directly to you. Thanks again for doing this!  
> **username_1**: It works great where I am; would be good to know what fails. For now, it is tailored towards live usage, e.g. where all player keep their browser window open. Oh, and now there is an in-game chat as well.  

---

### Answer by username_1 on 2013-04-28. Score: 3

If it is fine for your to wait up to a specific time, sending delayed mails via a service like [timecave](http://www.timecave.com/timecave/new.jsp) might be an option (although suboptimal).

> **Comments:**
> **username_0**: Thanks. Yeah, if we set a specific time, then timecave would work by itself for 2 players. For multiple players, I guess also create a mailing list, everyone sends a delayed message to that list. Timecave includes the time the message was deposited in a mail header, so we can confirm that nobody deposited a message after any message was sent. Doable...  

---

### Answer by username_2 on 2013-04-24. Score: 1

No arbiter is needed if you use encryption. Player A sends encrypted move Am1 to player B. Player B sends encrypted move Bm1 to player A. Once A receives Bm1, she sends the decryption key Ak1 to B, and B sends his decryption key Bk1 to A. This can be done over any messaging service, but does require a bit of overhead. (And you have to trust that the other player sends you valid move data, but you can set up the rules that if the initial message doesn't contain a valid move than the sender loses.)

Simple encryption tools can be found online. For example,
<http://www.alltextencryption.com/>

> **Comments:**
> **username_0**: Thanks, but this would have the exact same problems as cryptographic hashing, which I already excluded. (1) Player education is one big problem, as I said. (2) "The sender loses" is not a good solution especially in multi-player games, and especially especially Diplomacy. Especially especially especially if the sender might have messed up by accident, see (1).  
> **username_2**: @username_0: Isn't sender messing up by accident a problem regardless of technique described? How would an independent (hopefully automated) arbiter know whether the move data sent is valid without detailed knowledge of game rules and current state?  
> **username_0**: Yes, but you've introduced entirely new ways for a player to screw up. Also, Diplomacy has ways of dealing with partially or completely invalid moves. In the worst case the country goes into "Civil Disorder". Now you might think I could just have CD be the default if a player fails to decrypt his orders, but this is no good, it gives the player the option of either executing his original orders or pretending not to be able to decrypt and go into CD, and the player can get this option _after_ having seen everyone else's orders. This can make a difference!  
> **username_0**: EG: even if it's not Diplomacy and the rule is "sender loses", if there are more than 2 players it can matter. Say there are three players, and one of them is about to lose anyway. You may be giving that player the choice of losing in two different ways _after_ having seen the other two player's orders, this choice may affect which of the other two wins. The losing player may be secretly colluding with one or the other (such collusion is permitted if not mandatory in Diplomacy), and this option may give the coalition an advantage.  
> **username_0**: A third, unrelated objection is time: this is a two-phase protocol. Say it is played over email with players on opposite sides of the world. Now we have an extra delay of half a day or so each turn for no good reason.  
> **username_0**: Long story short, I was aware of cryptography when I asked the question.  

---

