Add API to be able to have synchronized random seed per instance

some webxdc apps have a need to have some random seed per instance, for example Reactle game (wordle clon) would benefit from having some unique seed per instance to having different words of the day in every chat, so you can play the game with different groups of friends/family

the problem why it is not feasible to do the seed generation in one of the users is side, is because then it becomes a synchronization problem, and the seed could be different from one user to another, it needs to be a seed that is shared by all the group members,

one easy way to implement this is to use some of the unique properties of the message instance like its message id or the send date, and use that to generate a seed,

the sent date is interesting, because just exposing this field opens some opportunities for app developers:

  • it is common to set seeds in existing “random” libraries/APIs using a timestamp/date
  • if the sent date is set, the app knows it is actually in sent state, if it is null the app developer can detect the app is in staged mode and offer hints/help or prevent misuse/cheating
  • the app could also use the date for its logic like shared/synchronized/common “world creation” / start in a game, a game / content that expires, etc.
2 Likes

I see the problem. But it sounds like a specific issue that has a more generic solution (I don’t know what the solution would be).

A (not a fool-proof) workaround I suggest: The sender of the .xdc should also send an “init” message with webxdc.sendUpdate() immediately after sending the .xdc. This way it’s almost guaranteed that everyone who got the .xdc file will get the “init” message as well.
If multiple peers happen to send the “init” message at the same time, there could be conflict resolution code that makes the one with the earliest timestamp win.

that doesn’t warranty anything because you can’t force the sender to open the app before sending, in fact that is not even possible in delta chat desktop at the moment, I don’t think knowing the sent-date is something specific to delta chat, it is a property of any message in any chat app so I think it is fine to make this available to the app since it opens interesting possibilities, like the random seed per instance use case