mainheader

Ну во-первых, у тебя четыре задачи.
1. Фронт. На каких платформах планируешь клиенты? Веб-клиент позволяет охватить много устройств, но он также может оказаться наиболее прожорливым по ресурсам. Если планируешь отдельные клиенты под отдельные платформы - надо смотреть отдельно под каждую платформу. Сразу исходи из того, что универсального решения не будет.
Под веб, разумеется, надо учить веб-стэк - как вообще работает HTTP, основы HTML+JS+CSS, скорее всего, придётся ознакомиться с каким-то JS-фреймворком, потому что на голом JS удобно писать только достаточно простой клиент. Стоит также заглянуть в сторону вебсокетов.
2. Протокол обмена. Их много разных - и это если не изобретать свой велосипед. Текстовые протоколы проще в отладке. Бинарные - компактнее (экономит трафик). Некоторые протоколы работают строго в рамках модели запрос клиента -ответ сервера (как HTTP), некоторые позволяют любому концу соединения проявлять инициативу. В твоей задаче запрос-ответ будет работать так себе. Читай про существующие универсальные протоколы обмена, такие как JSON-RPC или gRPC. Загляни в сторону REST. Да хоть старичка IRC посмотри. Важны моменты: многословность протокола (сколько надо передать байт по сети на N символов текста? А на N байт бинарного контента?), ограничения на передаваемые данные (например, можно ли передавать произвольные бинарные данные?), наличие библиотек для работы с протоколом, устойчивость к разрывам соединения, и т.д.
3. Бэк (сервер). В твоей задаче бэку лучше быть событийно-ориентированным, поэтому надо понимать суть событийно-ориентированной архитектуры. Соответственно, исходя из выбора протокола, выбираешь язык, для которого есть библиотеки под этот протокол, и в идеале который тебе знаком. Разбираешься, как организуется работа с этими библиотеками.
Продумываешь, какими сущностями ты будешь оперировать. Например, у тебя будут только чаты 1 на 1, или будут групповые чаты? А если групповые чаты, они будут одноранговые, или будут иметь структуру, типа серверов в Дискорде? Затем продумываешь, как ты это будешь хранить в базе данных.
Да, с базами данных надо быть знакомым.

Ну и задача №0, которую я описываю последней. Определи, под какую нишу ты делаешь свой мессенджер, кто будет им пользоваться, что для них будет важно? Условно, мессенджер, который предназначен для координации действий группы людей на реальной местности, это не то же, что месседжер, предназначенный для общения внутри корпорации, и не то же, что мессенджер, предназначенный для домовой/общажной локалки, где может не быть одного выделенного сервера.
В частности, важным вопросом будет структура сети. Централизованная, как Телеграм? "Лес", где может быть несколько серверов, но они не вазимодействуют? Федеративная, как e-mail или matrix, где можно поднять свой сервер, и взаимодействовать с клиентами других серверов? Одноранговая (P2P), как Tox? Это сильно повлияет и на целевую аудиторию, и на устройство протокола.

Научиться читать электронные схемы и разбираться в схемотехнике. Открываете гугл, находите учебник/курс и изучаете. По мере изучения решаете свои реальные проблемы. Если не хотите самостоятельно это делать - есть фриланс.

Хочу напомнить, удостоверяющий центр, выдавший сертификат, способен полностью расшифровать и даже подделать ваш трафик (на сайты, чьи сертификаты он обслуживает). Думать, что удостоверяющие центры не отдают своему государству (а ведь еще есть межгосударственные договоренности, типа не отдашь ключи, 'отключим газ') все необходимые ключи, опрометчиво.
При условии если приватник он сгенерировал а не пользователь самостоятельно.

Владелец веб сервера (в т.ч. хостер VPS) так же при желании, способен получить доступ и к расшифрованному трафику, и к данным на диске и оперативной памяти, даже если это kvm/vmware виртуализация, даже если ты запускаешь полностью свою ОС со своим ядром... гипервизор все видит (на аппаратном уровне у intel и amd уже давно есть инструменты для защиты от некоторых атак, но вы уверены что они активированы в гипервизоре вашего хостера?).

Разработчики программного обеспечения, запущенного на клиенте, при желании могут получить доступ к вашим данным (и это эксплуатируется, за той же майкрософт с самого старта телеметрии замечали и хранение и передачи всех нажатых клавиш, и отправку данных с видеокамеры и прочее прочее). Открытый софт? да, один из аргументов его появления был именно этот момент, но помним, что софт то ты открыл, а вот драйвера... напомнить что производитель материнской платы через efi биос имеет полный доступ к всему что у тебя в ОС происходит. И это я еще молчу про бэкдоры и не закрытые ошибки в легитимном и защищенном софте...

И на засыпку, производители оборудования, начиная с клавиатуры с мышкой (точнее любой usb), и заканчивая любой pci-e переферией, имеют доступ к данным, с разной степенью полноты, например usb мышка способна подслушивать нажатия клавиш на клавиатуре, подключенной к тому же контроллеру, обычно на материнской плате порты от одного контроллера размещены парами или по 4, а вот pci-e устройства имеют полный доступ даже к оперативной памяти (под вопросом многоядерные сервера, там кажется доступ разделен на группы по физическим процессорам).

p.s. в наших реалиях доверять приходится слишком многим, и скорее всего выбор у нас как пользователей, только в том, можем ли мы исключить из списка необходимости доверять только некоторых участников, собственно шифрование позволяет хоть немного исключить из этого круга местных провайдеров, оставляя информацию тем кто далеко...

1. Кроме утечек посередине данные могут утекать и со стороны браузера и со стороны сервиса.
2. mitm вполне себе возможен при помощи подставного сертификата. С введением сертификатов минцифры на уровне браузера - это уже не выглядит как что-то невозможное.

Скажите, правильно ли я понимаю, что провайдер и все промежуточные узлы видят только IP адрес на уровне L3 (и мак на уровне L2), а сами данные L4 на сеансовых и следующих уровнях для них зашифровано и недоступно? (из-за шифрования HTTPS) Т.е. в худшем случае мы можем только засветить свой белый айпишник, который привязан к географическому положению (и также хранится на логах сессий в маршрутизаторе у провайдера), но сами данные никто увидеть не сможет?

Да, но как уже выше написал - если ты сделаешь что-то нелегальное на площадке, которая сотрудничает с госорганами (а это не только лишь отечественные сервисы), то все твои данные по одному запросу передадут куда следует.

И если это так, то то же замедление ютуба или недавнего Дискорда- DPI (Deep Packet Insepction почему-то именно слово "Deep" настораживает.) - Как система может определять тип пакетов/траффика и исходя из этого делать уже какие-то выводы/принимать действия?

Это уже надо читать, как работают те самые DPI. Кроме ip есть ещё куча других эвристик, по которым можно определить, что за трафик идёт. Для большинства блокировок/замедлений достаточно ip.

В таком случае как тогда это стыкуется с безопасностью и шифрованием данных в HTTPS, если DPI может блочить по контенту?

dpi не может блочить по контенту, иначе бы мы видели блокировки отдельных страниц с запрещённым контентом.

Но впрочем для корпоративной сети это наверное нормально...

В корпоративной сети работает п2

Briar - для своего круга общения вообще замечательная программа.