ADR-113: Social service

More details about this document
Latest published version:
https://adr.decentraland.org/adr/ADR-113
Authors:
jmoguilevsky
Feedback:
GitHub decentraland/adr (pull requests, new issue, open issues)
Edit this documentation:
GitHub View commits View commits on githistory.xyz

Abstract

All current social features are implemented via abstractions on the client side, this poses a big problem when trying to add new features or apply business logic on top of features (i.e. max amount of friends) since with an API call any change can override any logic that the client has. This RFC proposes to have a new service on top of Matrix that will contain business logic, security policies, and will allow extracting the current abstractions from Matrix.

Need

Whenever a new feature regarding social interaction between users is envisioned currently, Matrix is seen as a blocker (or the integration with it), for example there’s currently no way to know the friends of a certain user, the only user case currently supported is knowing a users’ own friends (when logged in)

Some features that can’t be correctly implemented with the current status of the feature:

Approach

We propose to have a new service that will maintain every current feature of the chat but will also have support for the social features, for chat features it will work as a proxy but will first apply any business logic designed by us.

sequenceDiagram
    Social client ->> Social service: send message to user 2
    Note over Social service: Verify user 2 hasn't blocked owner
    Social service ->> Matrix: send message

Fig 1.1 Flow of sending a message, social service as proxy with business logic

sequenceDiagram
    participant Social client
    participant Social client 2
    participant Social service
    participant Matrix

    Social client ->> Social service: Add friend (new friend request)
    Social service ->> Social client 2 : New request from user 1
    Social client 2 ->> Social service: Accept friendship
    Social service -->> Social client: User 2 accepted friendship
    Social service ->> Matrix: create room

Fig 1.2 Simplified flow of a friendship

sequenceDiagram
    participant Social client
    participant Social service
    participant Matrix

    Social client ->> Social service: Create channel
    Note over Social service: Verify max channels allowed
    Social service ->> Matrix: create room
    Matrix -->> Social service: roomId
    Social service -->> Social client: roomId

Fig 1.3 Simplified flow of a creating a channel (success case)

sequenceDiagram
    participant Social client
    participant Social service
    participant Matrix

    Social client ->> Social service: Create channel
    Note over Social service: Max channels was reached
    Social service -->> Social client: 400 Max reached

Fig 1.4 Simplified flow of a creating a channel (failure case)

This service will need to be deployed along a Matrix instance since we’ll still leverage it as our Chat and main communication motor.

The communication between the social client and the new Social service will be implemented via web socket to be able to send real time notifications to the social client.

The friendships and friendship requests will be stored in a database managed by us.

graph LR
    A[Kernel] -.-  B(Proxy)
    B --> D[Social Service]
    B --> C[Matrix instance]
    D[Social Service] --> C[Matrix instance]
    D[Social Service] --> E[Relational Friendships DB]
    D[Social Service] --> F[KV Requests DB]

When a request doesn’t have any business logic on our side, it should reach Matrix directly, otherwise it will first go to the new service.

The main use cases for Matrix are the chat, so the endpoints that still will go to Matrix are:

There might be others, but these are the most important endpoints that won’t be affected and will continue as they are today.

The endpoints that we will override:

Even though it’s not an override it’s important to notice that /sync won’t be used for friendships and friend requests anymore and will be replaced with new endpoints for this logic.

Due to the service being critical for communication between the users, it will need to be highly available, so we will need:

We will need to refactor the dcl-social-client since we won’t be using the full scope of the matrix or some methods might change. On the kernel side there shouldn’t be too many changes since the API is abstracted via the client.

An important thing to note about this service is that it won't be decentralized to protect user data, we will enable the community to run their own instance of the social service and chat so that they are able to own and choose from the explorer whose server they want their data to be stored in.

Benefit

In the long term we might see that Matrix is not able to cope with the amount of users that we want (or we might need a huge investment in servers due to their cost) with this new architecture we could eventually replace it with an in-house built messaging system that only needs to leverage a little part of the procol (or could be a totally new one) with little to no overhead.

Competition

Doing nothing

A valid option is to keep Matrix as is, but lose the ability to implement the new social features and continue to modify the client or use our own modified synapse instance with the business logic coded by us.

Pros:

Cons:

Non-goals

Replacing Matrix is not part of this proposal, it's just changing the scope and impact of the feature. Matrix will remain as the engine for our private messaging infrastructure.

Key Dependencies and Open Questions

Q: Would the chat and friends be down if this service goes down?

A: Yes, since this service will work as a proxy to send messages, if it's down the chat will be down. That's why it's so important for it to have such a high uptime.

Q: Do we really need to expose users' friends? Isn’t it an issue on the privacy side?

A: Since exposing users' friends is a privacy intrusion, this service won't expose them to anyone, only the same user will be able to query their own friends.

Q: Does this service having access to messages poses a threat to users' privacy?

A: This service will only have access to the request sent from the UI, once we have E2E encryption support nor this service nor any other one will be able to read the content of the message. In the meantime, this service won't use nor read the content of the message for anything.

License

Copyright and related rights waived via CC0-1.0. Review