Player-to-Player Messaging

The social services system supports the sending and receiving of player-to-player messages. Each message has a senderUid of the user sending the message, a receiverUid of the user that the message is destined for as well as subject, body and attachments.

Inbox

Each user has their own inbox of messages that they have been sent by other users accessible via the /{userUid}/messages/inbox endpoint. Messages are considered permanent and will not be deleted or removed unless the application specifically removes them. To improve the user interface usability of your application a hasRead property is provided for each message that indicates whether or not a message has been read. It is the responsibility of the application to mark a message has having been read by either performing an update or calling GET on the /messages/{messageUid}/read endpoint.

Sent Messages

Each user can access the list of all sent messages using the /{userUid}/messages/sent endpoint. Like received messages the system will not automatically delete sent messages. It is the responsibility of the application to delete sent messages. Note however that messages are not duplicated therefore the sent message and the received message are the same. Therefore, if the receiving user deletes their message it will also be removed from the sender’s sent box.

Attachments

Messages can have an optional list of attachments appended to them. The actual storage is handled as a key-value pair mapping where the key is the name of the attachment. Values are always stored as strings. To encode binary data in the attachment it is recommended to use Base64 encoding for the value.

Example

attachments: {
    file: "lkfj098fu3oajf9083ufj2oij9p0a8ffujloiua9o8ubvf9p2ulijhqrlvfb98l26yqo9283yrh2r2=",
    invite: "{ appID: \"fa72de2c-77a4-494a-b6c3-b47f51d63a9a\", type: \"game\", sessionUid: \"49b58da1-61a1-4c8e-9f45-61b8007cb765\" }"
}

Privacy & Security Considerations

Only messages that have been specifically sent to or from a given user may be accessible through the REST API. The system will automatically filter out any messages belonging to another user. Similarly, any attempt to perform an action on a message that does not belong to a given user will be denied.