MSC4320: Rich Presence - #4320
Conversation
tulir
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Matrix client receiving activity data and sending it to the homeserver
- External app sending activity data to the local Matrix client
|
could be turned on or off from people who dont want it |
|
Implemented rendering rich presences in Extera Next latest commit |
| - `player` containing the media player. | ||
| - `streaming_link` containing a link to the song on streaming services (i.e. Spotify, YouTube). Clients should warn the user before opening the link. | ||
|
|
||
| Optional fields if `type` is `m.rpc.activity`: |
There was a problem hiding this comment.
Maybe including a timestamp start_time and expire_time, if a user goes offline without clearing their status, the expire_time could be used to not render the activity
|
I would like to suggest the possibility of enabling third party services to stream rich presence data without the need to go through the client, this is something I thought lacked from Discord's RPC feature. For instance, I'm listening to my Jellyfin server on my phone using a client that does not support Rich Presence on phone, or a Desktop client that doesn't support matrix: I make a small program that runs somewhere, authenticated to my account and that syncs data from my Jellyfin server to the matrix RPC directly, without the need to have my computer running with matrix open. There is probably no need to change the proposal much as OAuth2 flow already exists in the matrix documentation and it could be used to authenticate on the Another change would be to allow presence concurrency, so that an app running on the client can decide to not override the existing presence and simply add another one. This could be handled by allowing providing a presence source header in the request, or in the body. (Although I think using the header would be cleaner) Discord does implement having multiple RPCs running on the client at the same time too. |
|
maybe communication with webclients can be done using iframes? like element does with widgets... |
|
| Discord, a popular instant messenger, has a feature where alongside normal presence (ie online/away/busy/offline, status messages) there can be current activities. For example, music shows album art, song name, artist and current song progress, games show the map and such, etc. | ||
| # Proposal | ||
| ### Data transport | ||
| JSON data will be sent over a websocket running on `http://localhost:{TBD}/rpc`. This will be easiest for native clients, web clients will require something running on the host. Clients will send data to the server via a `PUT` to `/_matrix/client/v3/profile/{userId}/m.rpc` with content explained in "data content". Servers should preform basic validation on `m.rpc` to ensure only the needed fields are included. After an activity is closed or a song is paused/stopped, a`DELETE` should be sent to `_matrix/client/v3/profile/{userId}/m.rpc`. Note that skipping a track should not delete the RPC, as long as there's music playing. In that event, the `m.rpc` field should just be updated. |
There was a problem hiding this comment.
We should avoid allocating a port for this, as there is no guarantee that a given port isn't taken - Discord for example uses /run/user/$UID/discord-ipc-N (where N is a number from 0 to 9, taking the lowest available value)
| } | ||
| ``` | ||
| ### Potential implementations | ||
| - Something using [arRPC](https://arrpc.openasar.dev/) to pretend to be Discord to get info. |
There was a problem hiding this comment.
This relies on automating a Discord user account to obtain application info (ie. resolving an application ID to it's name and other info) - this isn't available to bots as far as I'm aware.
| ### Data transport | ||
| JSON data will be sent over a websocket running on `http://localhost:{TBD}/rpc`. This will be easiest for native clients, web clients will require something running on the host. Clients will send data to the server via a `PUT` to `/_matrix/client/v3/profile/{userId}/m.rpc` with content explained in "data content". Servers should preform basic validation on `m.rpc` to ensure only the needed fields are included. After an activity is closed or a song is paused/stopped, a`DELETE` should be sent to `_matrix/client/v3/profile/{userId}/m.rpc`. Note that skipping a track should not delete the RPC, as long as there's music playing. In that event, the `m.rpc` field should just be updated. | ||
| ### Data federation | ||
| `m.rpc` data will be federated over a `GET` to `/_matrix/client/v3/profile/{userId}/m.rpc`, as per [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133). |
There was a problem hiding this comment.
Concern: what about homeservers/clients that enforce long TTLs on profile caching? (ie. 15 minutes doesn't seem unreasonable whatsoever, which would be eg. about 5x the length of an average song)
8 participants
Rendered