Social Services

Social

The AcceleratXR social system makes it easy to build rich player communities with features like real-time chat, public profiles, player-to-player messaging and relationships built-in.

This section provides detailed information about the social system within the AcceleratXR platform and how to use each feature, including examples and API references.

Concepts

User Profile

The user Profile is for storing social profile data about a user. The Profile object contains information such as the user’s current online presence, an alternate name or alias by which the user wants to identify to others as, as well as an arbitrary set of data that can contain any application-specific metadata.

Alias

Often times a user wishes to be identifiable by another name from their real name. The alias is a way for a user to provide this alternate name that can be displayed to others. The alias is not gauranteed to be unique within the system.

Avatar

The avatar property stores a UUID, URI or other identifier that the application uses to render or display an custom avatar for the user.

Presence

Online presence is application-specific data that allows other users to know what their friends are actively doing. The presence property takes an arbitrary data object that can contain any useful information that the application needs to identify and display the current state of the user. The value of this property does not have an expiration time associated with it. Therefore, it is the responsibility of the client application to update this property when the state changes, including during a logout event as the user logs offline.

Data

The data property allows an application to store any arbitrary social profile information that the user and/or application may care about. The value is stored as a key-value pair object whose keys are the names of the data properties desired.

For example let’s assume an application that stores links to various third-party social networking profiles for a given user. This may look like the following.

data: {
    "facebook": "https://www.facebook.com/acceleratxr",
    "linkedin": "https://www.linkedin.com/company/acceleratxr/",
    "twitter": "https://twitter.com/acceleratxr",
    "bio": "AcceleratXR™ technology enables teams of any size and experience to build the next generation of online and multi-player experiences at massive scale. With over 20 unique systems, including live cloud scripting, AcceleratXR is the most customizable, feature-rich platform, for building games, entertainment, the metaverse and beyond."
},

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.

Relationships

A relationship between two users in the AcceleratXR platform is referred to internally as a UserLink. Users can have any number of links to any number of other users. Each link describes the type relationship between two users in addition to an optional alias and arbitrary data map. This makes it possible to implement the following social network concepts.

  • Followers

  • Friends

  • Blocked Users

  • Recently Met Users

The alias allows users to provide a custom name for the other user that is specific to them within their list. This can be helpful in identifying the relationship among many other users with similar common names. Lastly, the data property is also provided in order to give you the ability to implement additional capabilities that may be app specific.

Encountering Users (ENCOUNTER)

When players encounter one another while interacting in the product it is possible to create an ENCOUNTER user link. This link is intended to track all players that a user may have recently met and desire to see again in the future.

Following Users (FOLLOW)

User links with the FOLLOW type describes relationships where a user is interested in being following the activity of another user. This relationship is one-way in that the source user (userUid) wants to follow the activity other user (otherUid). This makes it possible to create loosely coupled relationships between users which can be beneficial when needing to create and maintain a set of one-way relationships for users such as subscribing to a user’s feed.

Friending Users (FRIEND)

A user link with the FRIEND type is the two-way relationship whereby two users indepedently have chosen to follow the other. As this is a two-way relationship, requiring both users to participate, it is not possible to simply create a user link with the FRIEND type. Instead, any time two users create a FOLLOW link to each other the system will automatically upgrade their relationship to a FRIEND type. Should either side choose to delete their respective side of the relationship then the opposing link will be downgraded down to a FOLLOW link.

For applications implementing a friends list system it is recommended that each user creates a FOLLOW link to another and then sends a friend invite message to encourage the other user to create the needed opposite link to complete the FRIEND relationship. This can be accomplished via the following steps.

Given user A wants to add user B as a friend…

  1. User A creates a UserLink to user B with type FOLLOW.

  2. User A sends message to user B containing an invite attachment to add them as a friend.

{
    senderUid: <UserA_UUID>,
    receiverUid: <UserB_UUID>,
    subject: "UserA wants to be your friend!",
    body: "User A wants to be your friend.",
    attachments: {
        invite: "{ type: \"userlink\", userUid: <UserA_UUID> }"
    }
}

  1. User B receives message containing friend invite sent by User A.

  2. User B accepts friend invite. Creates a UserLink to user A with type FOLLOW

  3. System automatically upgrades both connections to FRIEND

Blocking Users (BLOCK)

Not everyone is going to want to be friends. In the event that a user wishes not to interact with another user they can create a UserLink with the BLOCK type. This relationship is always a one-way relationship however it is special in that the system will not allow a user to create an opposing FOLLOW link if an existing BLOCK exists. Similarly, if there exists a FOLLOW relationship between the two users then that link will be removed once a BLOCK link is created. This is true even in the event that a FRIEND relationship exists. In the event that a user attempts to follow a user that has blocked them an error is returned by the service. It is the responsibilty of the application to decide whether or not this error should be displayed to the user.

Online Presence

The online presence of a given user is application-specific data that allows other users to know what their friends are actively doing at any given moment. The user Profile data contains a special presence property takes an arbitrary data object. This object can contain any amount of useful information that the application needs to identify and display the current state of the user.

By default the AcceleratXR platform provides a default implementation of the online presence data format for common operations and states of a given user. These states are set by various backend systems when certain events occur. The exact format and messaging of the data is configurable on a per system basis. Consult the originating system’s documentation for more information about how to change the pre-defined presence data.

Online Presence

Event

Description

Data

Origin

Login

Occurs whenever the user signs in to the backend and establishes a push notification connection.

{ "status": "ONLINE" }

notification_services

Logout

Occurs whenever the user signs out of the backend and/or is disconnected for 10 seconds or longer.

{ "status": "OFFLINE" }

notification_services