Lodge Chat Spec/Docs

Overview

Build out a new community chat system, possibly including ability to even reproduce visual chat like The Palace. Hoping to make it flexible in being able to be more general purpose community text chat as well.

General Architecture

• Server-Client architecture over TLS, possibly QUIC
• MessagePack or Protobuf?
  • CBOR seems to be not as robustly maintained Rust crate wise, except maybe minicbor?
  • MessagePack & Protobuf options seem more widely supported & updated
• MLS for e2ee chat (probably optional per room?)
• Possible limited federation for identity/authentication, matrix like home server concept
  • Keep rooms etc likely off federation though
• Palace style visual presence, optional as I just want that for nostalgia, but underlying tech really can do both I think
  • 2D rooms, custom avatars, can move around in the space
  • Interlinking room/interactivity
  • Lua scripting in place of Iptscrae, but more limited/secure angle (server wouldn't see e2ee room chats for one)

Configurability

Originally was thinking of making a new The Palace like chat for fun, but thinking there isn't really hard reasons why there can't be flexibility in allowing multiple-room joining, disabling of visuals, etc to also provide more Discord-ish chat as well.

• Rooms can be e2ee or not, history likely only allowed on open rooms
• Possibly setting for allowing guests/anonymous
• Whether server follow spacial metaphor, requiring users to only exist in 1 room at a time (The Palace, voice chat app style, etc)
• Whether server is visual/spatial enabled
• Room directory allowed or not (probably by default on, disable for more experience based spatial/visual servers)
• Room organization, allow some hierarchy/grouping

Likely Reference Languages

These are chosen both for their advantages & my knowledge of them. Others can always build in other languages to be compatible. There's C++, TypeScript & Rust libraries for MLS at least.

• Elixir for server, being able to leverage it's green threads, pubsub, supervision trees and what not
• Rust for client using OpenMLS for e2ee
• May want to consider Rust on both to leverage library code in both client & server?

Open questions

• Server's backend storage, SQLite? serialized file formats?
  • For keeping the room layout & organization
  • Asset storage & information for spatial mode
  • Registered users
• Should how we store rooms/structure be identical to wire protocol?
  • Like wire protocol would provide room information with users present
  • But the structure/organization state of the server would just be room description/etc
• How should we handle user avatars?
  • Do we want to mimic Palace props & smileies? the grid prop system etc.
  • Do we want to just have avatars be single image with a size limit?
  • What format do we transfer these images?
  • Should server cache any of this or p2p send avatars?
  • Animation support in avatars?
• How would we handle returning visitors & multi-room join support?
  • Palace/spatial mode is more default/entrance room arrival & then you navigate away
  • If multi-join is enabled, we'd want to preserve a user's joined rooms?