currently, a "direct message channel" or "private channel" is a type of guild that contains a single channel. because of the simplicity of private channels as compared to full-on channels or guilds, I suggest a new PrivateChannel type:

// PrivateChannel is a private channel between a list of users, independent of a guild.
// It should be possible to use this channel for both text and voice communications.
message PrivateChannel {
  // The list of users that have access to this channel.
  repeated uint64 members = 1;
  // Whether it is possible to add or remove users to/from this channel.
  bool is_locked = 2;
}

(note that fully private, or "direct message", channels, have the is_locked type set - it is not possible to add more users to a DM between two users.)

Events for guild invites should be added (created / deleted).

users may want to force log out previous sessions (if they lost a device, for example), or see the list of current/past sessions

The website and documentation does not explain why Harmony does not reuse/extend XMPP.

Currently, clients can't receive events they missed, when they weren't connected to the server. This can happen for many reasons, but most notably because the user closed the client application, or because of an internet failure. This means that once they reconnect, their state will be out-of-date, and they will need to refetch all of the data instead of incrementally fetching what they need. This issue is for tracking potential solutions.

Solutions?

solution 1

1. introduce a new StreamEventsResponse.event variant:

   message StreamId {
   	uint64 stream_id = 1;
   }

2. StreamId lets the client know the ID of the current stream they are using. This will be sent to the client upon connection of the stream.
3. introduce a new StreamEventsRequest.request variant:

   message KeepTrack { }

4. KeepTrack lets the server know that after the current stream has ended, it should store any events dispatched to this user under the ID of the stream that ended.
5. introduce a new RPC to ChatService called SynchronizeEvents. it's request type will take a uint64 stream_id = 1;.
6. ChatService.SynchronizeEvents will return a list of events, ordered from oldest to newest, that the client has missed since the end of the stream the ID was bound to. After this is called, the stream ID should be invalidated, and all the events should be removed.

The events should only contain the newest state, and nothing in between. New messages should not be kept, only edited / deleted messages, as new messages will potentially take up a lot of storage. The client can fetch the new messages itself.

solution 2

1. servers attach a "last modification time" to basically everything (profiles, messages, guilds, channels, etc)
2. clients later can synchronize their state by sending a request with the last time they were connected. the server will figure out what's missing and send it to the client. the response can simply be a list of events, ordered from oldest to newest that the client can apply easily without writing new logic.

Unlike the first one, this doesn't require much protocol change aside from one new RPC, and doesn't require the server to store redundant state. However this is potentially much more complex for servers (?).

The formatting system we have now currently has clients provide text ranges to format in specific ways. This has a few flaws compared to markdown which should be addressed:

1. Harder to upgrade. Clients will need to update their text inputs to make it possible to use new formatting capabilities. Increases maintainer workload. With markdown, unsupported syntax could still be written with an outdated client and it would still work.

2. Impossible / Inconsistent on some platforms. Bridges from other services will face issues with formatting, because of how on most of them the formatting is fundamentally text-based.

Support metadata for harmony types, used for extensibility.

Guilds are an utter mess.

We need to figure out a way to make them less possible to screw up.

An embed field image field should include a resolution. This will help reduce layout shifts in clients.

In mediaproxy, media data (that are images) and site data image field should include resolution. This will help reduce layout shifts in clients.

• seperate stream service
• stream service will have a streaming rpc
• this rpc will take a stream events request where the request type takes an enum containing all possible streaming services and the serialized request data for the chosen streaming service
• the rpc returns the same as request except the data is replaced with event data

TODO: better wording

Some users may want to not see channels with NSFW content. It would be possible to put a warning in the channel name (or something similar), but a property on the channel type itself would let clients toggle displaying content from these channels altogether.

Currently, the highly dynamic nature of login makes it hard for clients other than web browsers that see "that's a username and that's a password field, let's autocomplete" to fill passwords, or better yet, save login details in the OS-provided wallet and attempt to create a new session when the old one expires

This service would do two things:

• have an RPC for checking API versions between client and server
• have an RPC for querying server capabilities (what services it runs and other information the client might need to display or not display certain stuff (but what?))

Instead of short circuiting on errors, errors should be returned separately for each request.