Игорь Неважно

if (text && text.length > 0 && !$(this).val()) {///<--убрать && !$(this).val()
			$(this).val(text); // set field data
		}

не рассматривай задачу в разрезе "А как делают все?"

У тебя есть три юзкейса - реализуй их, если есть доля клиентов с существенным доходом, то сделай и им интерфейс.

Идеально было бы с каждым крупным заказчиком переговорить и спросить, как им упростить заказ

К элементу #target

window.onload = function(){ 
var offsetY = document.getElementById('target').offsetTop;
window.scrollTo(0, offsetY);
}

Если просто вниз, то:

window.onload = function(){ 

window.scrollTo(0, 999999999999999);
}

но Вам определенно нужно jQuery

Пройдемся по пунктам:
1) WebSockets
2) Все что касается авторизации не относится конкретно к задаче чатика. Можно конечно замарачиваться, и выносить функционал авторизации в отдельный демон или поток и общаться через Pub/Sub (например ZeroMQ). По сути главное что бы во время верификации пользователя мы могли обрабатывать другие соединения
3) Если вы хотите p2p доставку сообщений с WebRTC, то сервер вам нужен будет только для авторизации и аунтефикации клиентов, ну и что бы клиенты могли найти собеседников. В этом плане серверная часть упрощается и снижаются требования по нагрузкам, но усложняется клиентская часть.
4) К сожалению вы не можете отправлять бродкастом сообщения, так как используется TCP. Можно конечно организовать что-то типа очереди, но я не вижу причин для выйгрыша в производительности. Тут больше вопрос архитектуры и каким образом вы синхронизируете списки пользователей.
5) Ну... тут не вижу проблемы. Если вы хотите иметь один сервер для всех виджетов, то просто добавить поддержку CORS и токены для запросов (в заголовках) что бы разграничивать по доменам.
6) А что именно вам надо хранить в базе? Сообщения у вас на сервере, как вы сказали, не хранятся... Пользователи - любой вариант, тот же MySQL (а лучше PostgreSQL, для которого есть возможность использовать асинхронные запросы в базу, что бы было интереснее). Текущих пользователей и прочее можно хранить в Reddis и т.д. Главное что бы хранилище было быстрым.

Вообще задумка интересная, вариантов реализации масса. Это можно спокойно и на PHP написать, есть ReactPHP + Ratchet для организации сети пользователей, а для доставки сообщений вы и так хотите использовать WebRTC. Просто на сервере в супервизор надо поставить парочку демонов (по одному на ядро) и сверху поставить nginx, который будет балансировщиком и проксей. Учитывая что вы нехило можете за счет WebRTC и каких-нибудь архитектурных трюков уменьшить итоговую нагрузку на сервер, проблем с производительностью быть не должно. Так же для ReactPHP было бы неплохо поставить libev/libeven, словом там по документации можно пройтись и почитать что да как.

Update:
отстал я от жизни, как раз таки UDP можно использовать в браузерах (во всяком случае в последних билдах хрома), в частности для передачи информации между браузерами (а не аудио и видио) можно использовать datachannels. Так что тут все упирается в то, как доставлять сообщения между клиентами. Остальное уже зависит от того, как вы все же решите все делать.

Задача не совсем ясна, но так как решать за вас ее все равно никто не будет, полная ее ясность и не требуется.

Если вы хотите показывать пользователю баннер раз в сутки, используйте, например, Cookie. При обращении пользователя читайте Cookie. Если в них не записано время вовсе или записано время показа баннера, отличающееся от текущего больше, чем на сутки, показывайте баннер и записывайте текущее время. Если в куках есть данные о том, что баннер последний раз показывался сегодня, ничего не выводите.