This document defines and explains design details for hRPC. Version This is hRPC specification version 1. Protobuf Version All hRPC implementations MUST support Protobuf 3. All references to Protobuf in this document are references to Protobuf 3.

Go ahead and try to hit me if you're able What is Harmony? A chat protocol which: is split into communities which contain channels which contain messages is defined entirely within the Protobuf format, using a simple RPC mechanism called hRPC. What are the design goals of Harmony? Harmony's protocol is designed to be as straightforward and pragmatic as possible. We do not make attempts at creating a "universal" design philosophy which the entire protocol is forced to follow, instead implementing things that make sense as a single cohesive system. Time has proven over time over that design idealism is often a limiting factor in services.

This week was pretty eventful for Harmony, for one the project now has an actual roadmap which you can follow here! Project planning aside, work this week has mainly been focused on clients, although there have been some changes in the protocol and server as well. Protocol Added an about endpoint which allows you to get some information about a server such as the name, version, description and a message of the day! (Yusuf Bera Ertan, 02c6d71) Added a EquipEmotePack endpoint because I somehow forgot to add that while writing the Emote API. (Yusuf Bera Ertan, 76c24f8)

Problem Currently, there is no way to receive data between two hosts. In addition, the guild list is currently implemented in a way that is prone to error, as it requires clients to manually invoke RemoveGuildFromGuildList after the client leaves a guild. Having a way to send messages between hosts would allow the guild list to be automatically managed between hosts, and for DM invites to work across hosts. Solution Provide an endpoint to post an event to a host, and additionally have a way to 'pull in' events from a target host in case the host was down and unable to receive events. This ensures that there is no loss of events if a host goes down. Implementation When a host wants to send an event to another host, they will first try to call PostEvent on the remote host. PostEvent notifies a host of an event. If a PostEvent fails, the origin host will add the event to a queue of pending events. When PostEvent is called, the host receiving the event needs to know what host it came from. The host sending the event must generate a random UUID of size 16, and sign it with its private key as a JWT. In the PostEvent, the token value will be set to the signed JWT, and the host value will be set to the hostname of the server.

Protocol changes Postbox [x] Draft protocol [x] Documentation written [ ] Feedback received [ ] Server implementation implements changes Lazy loading

# Postbox

# AppServices / Privileged integrations

# Abuse Prevention

Guild List Only the following events should be received by users: guild name/picture changes whether an unread message is received in a guild event will contain a message id so that clients can fetch it later without refetching the message list (will need a GetMessagesBulk endpoint) Channel List If we are in a guild, then these should be sent to users: