# Dealer When talking about the dealer, we are speaking about a websocket that represents the player as spotify-connect device. The dealer is primarily used to receive updates and not to update the state. ## Messages and Requests There are two types of messages that are received via the dealer, Messages and Requests. Messages are fire-and-forget and don't need a responses, while request expect a reply if the request was processed successfully or failed. Because we publish our device with support for gzip, the message payload might be BASE64 encoded and gzip compressed. If that is the case, the related headers send an entry for "Transfer-Encoding" with the value of "gzip". ### Messages Most messages librespot handles send bytes that can be easily converted into their respective protobuf definition. Some outliers send json that can be usually mapped to an existing protobuf definition. We use `protobuf-json-mapping` to a similar protobuf definition > Note: The json sometimes doesn't map exactly and can provide more fields than the protobuf > definition expects. For messages, we usually ignore unknown fields. There are two types of messages, "informational" and "fire and forget commands". **Informational:** Informational messages send any changes done by the current user or of a client where the current user is logged in. These messages contain for example changes to a own playlist, additions to the liked songs or any update that a client sends. **Fire and Forget commands:** These are messages that send information that are requests to the current player. These are only send to the active player. Volume update requests and the logout request are send as fire-forget-commands. ### Requests The request payload is sent as json. There are almost usable protobuf definitions (see files named like `es_(_request).proto`) for the commands, but they don't align up with the expected values and are missing some major information we need for handling some commands. Because of that we have our own model for the specific commands, see [core/src/dealer/protocol/request.rs](../core/src/dealer/protocol/request.rs). All request modify the player-state. ## Details This sections is for details and special hiccups in regards to handling that isn't completely intuitive. ### UIDs A spotify item is identifiable by their uri. The `ContextTrack` and `ProvidedTrack` both have a `uid` field. When we receive a context via the `context-resolver` it can return items (`ContextTrack`) that may have their respective uid set. Some context like the collection and albums don't provide this information. When a `uid` is missing, resorting the next tracks in an official client gets confused and sends incorrect data via the `set_queue` request. To prevent this behavior we generate a uid for each track that doesn't have an uid. Queue items become a "queue-uid" which is just a `q` with an incrementing number. ### Metadata For some client's (especially mobile) the metadata of a track is very important to display the context correct. For example the "autoplay" metadata is relevant to display the correct context info. Metadata can also be used to store data like the iteration when repeating a context. ### Repeat The context repeating implementation is partly mimicked from the official client. The official client allows skipping into negative iterations, this is currently not supported. Repeating is realized by filling the next tracks with multiple contexts separated by delimiters. By that we only have to handle the delimiter when skipping to the next and previous track.