n1ght(o_O), Вы бы хоть сразу пояснили, что именно должна делать эта самая кнопка "Спасибо".
Если просто добавлять "+" в репутацию, то в принципе это можно сделать и сейчас имеющимися средствами. На http://helper.ucoz.ru , вроде бы, есть даже тема по этому поводу.

Добавлено (13-Авг-2009, 22:00:42)
---------------------------------------------
Дядя_Рома, сейчас данные uNet-аккаунтов не передаются между серверами Юкоза в реальном времени. Они просто периодически реплицируются с сервера unet.com на все остальные сервера. Таким образом, никакой связи между сайтами, расположенными на разных серверах, сейчас вообще нет, и что-либо "сообщить" друг другу в реальном времени без прикручивания каких-то дополнительных сервисов обмена данными они не могут.

Насчет "почему не получится через безопасный вход" - да просто потому, что "безопасный вход" - это всего лишь обычный POST uNet-логина и пароля на адрес http://домен_сайта/index/sub , с открытием результата (т.е. главной страницы сайта) в окне браузера, и больше ничего.
И как Вы представляете это можно использовать для того, что Вы хотите? Заставить сделать такой POST скриптом не позволят секъюрити-ограничения браузера.

Лично я вижу единственную возможность обойти эти ограничения: сделать специальный вход авторизации, работающий через GET. Но это будет не секъюрно, и от этого как раз всячески старались уйти.

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

Кроме того, куки и URL - вещи разные. В частности, URL часто светятся (и потом оседают на долгие годы) во всяких логах, сервисах сбора статистики и т.п. И если пароли передаются как часть URL, то они нередко становятся попросту видны через Интернет.

Это по поводу удалённых сообщений.

Суть предложения №1: Добавить возможность настраивать «Автоперенос» для нескольких групп.

Аргумент по предложению №1: Не мало сайтов, посетителей которых изначально можно разбить на несколько групп. Например сайт посвящен охоте и рыбалке. Его посетители могут выбрать для себя членство в группах «рыболов», «охотник», «охотник-рыболов». Для каждой из групп дизайн сайта и вспомогательные блоки настроены индивидуально. Но давать расширенные возможности вновь зарегистрированным пользователям глупо (натворят делов не разгребешся). Для этого можно создать группы «продвинутый рыболов», «продвинутый охотник» и т.д. Но переносить пользователей из одной группы в другую вручную долго и не оптимально. Действующий пример мой сайт посвященный армии (изнутри). На сайте в основном три категории – это будущие солдаты, бывшие солдата и девушки, которые ждут солдата. Мне приходится самостоятельно выискивать наиболее активных и переносить их в группы для продвинутых с расширенными возможностями… При этом поступают жалобы что те кто на сайте меньше чем другие уже в продвинутых а бывалые до сих пор еще нет и все потому что в таком объеме юзерв очень тяжело все сделать правильно.

Мысли по реализации предложения №1: Создать категории групп «пользователи», продвинутые пользователи» и «администраторы». В первую категорию входят группы пользователей с ограниченными возможностями. Во вторую категорию входят группы с расширенными возможностями. Все группы первой категории имеют функцию автопереноса в любую группу второй категории. Ну а третья категория это модеры, админы и прочие им подобные. Автоперенос в третью не нужен, так как тут нужно волевое решение админа (ИМХО).
___
Суть предложения №2: Добавить конструктор дополнительный полей при регистрации (или настройке персональных данных) пользователя.

Аргумент по предложению №2: Тем и направлений сайтов великое множество. Но персональные данные пользователя для все сотен тысяч сайтов едины (исключим сайты, где админы хорошо владеют JS и реализуют все сами, но таких очень мало). В сайте о кино пользователь может указать свои любимые фильмы или любимые жанры.
На примере своего сайта об армии (изнутри) - пользователь может указать часть, в которой служил, годы службы, войска. Все это я могу использовать в разработки сайта для более плотной персонализации. Да и прочих применений этим данным не мало.

Мысли по реализации предложения №2: По сути рабочий конструктор полей уже имеется в модуле почтовых форм. Все что нужно это добавить в настройках модуля пользователи галочку «Использовать конструктор дополнительных полей» и собственно сам конструктор в возможности модуля. Важно что бы он мог создавать как строки, текстовые поля, так и чекбоксы, комбобоксы и списки. Все это можно (а мне и многим нужно) использовать. Заполненные поля вызываются кодами $USER_DOPINFO1$ $USER_DOPINFO2$ и т.д.
___
Суть предложения №3: Добавить возможность создавать собственные переменные.

Аргумент по предложению №3: Возможностей которые открывает это предложение великое множество, а что самое главное сделает uCoz системой CMS, которая «заткнет» всех (вечно не довольных) php умников. Лично я не владею ни php ни JS, но принцип использования условных операторов мне понятен и таких как я очень много…
Приведу несколько пример использования. Ставим на персональной странице пользователя четыре кубика разных цветов. При нажатии на кубик, заранее созданной переменной присваивается значение и страница обновляется. В шаблоне прописано через условные операторы какой дизайн при каком значении переменной показывать и ПАБАМ сайт сменил дизайн (или цветовую схему).
Пример номер два – еще более интересный. Для каждого вспомогательного блока по бокам сайта создаем переменную, а в блоке значок или надпись «скрыть». Нажал на «скрыть» переменной присвоено значение, страница обновилось и блок не показывается (так как в шаблоне стоит условный оператор). В персональной странице добавляем надписи «отобразить …». Таким образом пользователь может настроить сайт по своему усмотрению. Оставить только нужные ему блоки и т.д. Так же изначально можно исключить какие либо блоки, а пользователь по желанию их потом откроет в своей персональной странице.

Мысли по реализации предложения №3: Реализуется в два шага. Первый конструктор переменных. Логично поместить его рядом с конструктором глобальных блоков при работе с шаблонами. Создаем переменную со свободным названием или $UV_IME$ (где UV – user variable, а IME – данное админом имя переменной). Все переменные могут хранить только текстовые значения. Можно сразу присвоить значение или же оставить его в nothing.
Шаг второй. В дезайнере в мастер ссылок добавить пункт variable (там где http, news и т.д.). При выборе появляется два поля «имя переменной» и «значение», а так же галочку «обновить страницу».
Теперь на любой объект сайта можно назначить обычную ссылку, которая присвоит переменной значение и обновит сайт!!!
Ну и для пущего удобства можно добавить в конструктор при редактировании блоков на вкладке "доступ" галочку "показывать при условии" и два поля "переменная" и "значение".
Реализовать это ИМХО не из ряда сверх и закрытости кода не повредит, а результат подымет систему на новый уровень!!!

Что касается расширения баз данных, то оно ИМХО не настолько существенно. Я не уверен что нет пользователей создавших кучу почтовых форм или информеров, используя при этом только пару. Ну а на крайний случай можно установить ограничение по количеству, как в ротаторе банеров или глобальных блоках...

Ну и это всего лишь предложения, которые позволят творить пользователям с не высоким знаниями JS....