Дискусия и съвети при изграждане на сайт за запознанства

FalcoSoft ITS

FalcoSoft ITS

Well-Known Member
Колеги , тъй като след няколко дни стартира нов сайт за запознанства

BGdating · Нещо хубаво започва тук

BGdating — български сайт за запознанства, хубави разговори и истинска връзка. Първа версия с личен чат и снимки. Само за пълнолетни.
bgdating.com bgdating.com
с всички екстри които липсват по другите сайтове в България , дайте насоки като потребители какво бихте искали да има като функции в сайта за да ги добавя навреме преди да е стартирал.

Част от екстрите досега които са направени допълително са:
1. Автоматични преводи в чата на 10 Европейски езика. При писане на съобщение на български език с някой чужденец той може да си направи превод директно с бутон Преведи директно с чата ако незнае езика. Същото важи и за обратния ред и междуезиково.
2. В самия чат могат да се ъплоудват или пействат снимки ( в другите сайтове за запознанства тази функция е забранена) Снимките не товарят сървъра защото се качват директно в R2 на Клоудфлеър.
3. Секция Ескорт в която всички работещи момичета и момчета могат да си пускат безплатно обяви без цензура както на текста така и на снимките.
4. В момента работя върху възможността за гласов месинджър ( видеото товари много ) между юзерите.

Споделете вашите виждания и насоки.

1793198115998.webp
 
Vladislaw каза:
Знаеш с какво ще започна.. нов дизайн!! :D
Ето едно предложение:
https://imgur.com/uKtRvti
Увеличете...
Ако дизайна, е като на едновремешния ретро facebook, които беше през 2010-2014г. ще избугне, хората ще се регистрират от носталгия :D
 
Основният проблем на дейтинг сайтовете винаги е бил един: липсата на реални жени.

Затова всички наливат фалшиви женски профили и някакви оператори ги управляват, демек пишат от тяхно име. Сега няма нужда от такива оператори, ама и хората по-трудно се лъжат вече.

... затова в крайна сметка пак опираме до формата "AI Girlfriend".
 
contra каза:
Основният проблем на дейтинг сайтовете винаги е бил един: липсата на реални жени.

Затова всички наливат фалшиви женски профили и някакви оператори ги управляват, демек пишат от тяхно име. Сега няма нужда от такива оператори, ама и хората по-трудно се лъжат вече.

... затова в крайна сметка пак опираме до формата "AI Girlfriend".
Увеличете...
не съм твърдял никога , че няма да има Ai Girlfriend в сайта , понякога е по разумен и знае как да подържа разговорите в такива сайтове, особенно на фетишистите :-) Измислил съм модела и дори няма да се познае , че е Ai . Освен това с гласовия чат месинджър който в момента пускам в сайта няма и да се познае , че не е човек. До толкова гласовите модели са се усъвършенствали , че са се научили и на ударението на българските думи и изречения все едно сладко сладко ти говори най сладката любовница :-)
 
Ще има ли страници, групи, каталог, пиксел, реклами и тн? Сериозно питам. То подобно нещо единствено за да прави пари е реклами и яко промотиране. Макрче с тия социални мрежи които има каквото и да се направи трудно става да се закачат хора. Трябва да имаш някакъв страхотен hook за да се използва. Какъв ти е бизнес плана за развитие на това нещо? Да привличаш аудитория? Или ще е софтуер за продаване? https://codecanyon.net/item/hifod-s...ejs-react-and-mysql-community-script/65132992

Чатове и подобни неща през websocket ли минават? Натоварвания ако има истински? И много интересно Wappalyzer не лови технологиите :D какво използваш отзад backend, frontend?
 
Със собствен GPU можем да пуснем AI модела на наш сървър и BGdating да комуникира директно с него. Използваме готов модел с отворени тегла; няма нужда да го обучаваме от нулата. Например семейството Qwen3 предлага модели с различни размери под Apache 2.0 лиценз.

Това ни дава:

  • Контрол върху поведението и характера на персонажите.
  • Разговорите могат да остават в нашата инфраструктура, ако и паметта, съхранението и останалите услуги са при нас.
  • Без външна API такса за всяко съобщение — вместо нея плащаме хардуер, ток, хостинг и поддръжка.
  • Един зареден модел може да обслужва всичките 30–40 персонажа с отделни характери и истории на разговорите.
Моят ориентир за първоначален тест е:

GPU паметВъзможен начален вариант
24 GBКвантован модел с 8–14 милиарда параметъра
32 GBПовече резерв за разговори или по-голям квантован модел
48 GBПовече място за модел и едновременни разговори
Това са инженерни ориентири, не гарантиран капацитет. Например RTX 5090 има 32 GB, а L40S — 48 GB. NVIDIA RTX 5090, NVIDIA L40S.

50 души онлайн е различно от 50 души, на които AI генерира отговор едновременно. Второто изисква реален тест с избрания модел, дължина на разговорите и желана скорост. Система като vLLM може да обработва заявките на общи партиди за по-добро използване на GPU.

Бих започнал с текстов чат, отделен GPU сървър и тест на български език под натоварване, преди покупката. Собственият GPU дава повече контрол, но поведението продължава да зависи от модела и лиценза му; персонажите ще останат ясно обозначени като AI.
 
Като отделен AI модул към BGdating, с GPU сървър за генерирането на отговорите. Сайтът, потребителските профили и реалният чат продължават да работят независимо от него.

Текущия код: BGdating използва React + Vite, Node.js 24 + Express, Socket.IO, SQLite и R2, с Docker deployment. Върху това можем да стъпим.

Конкретният стек, който предлагам:

ЧастТехнологияКакво прави
ИнтерфейсСегашният React + ViteВитрина с AI персонажи и чат
Основен backendСегашният Node.js + ExpressВход, права, ограничения и достъп до AI раздела
AI модулNode.js + TypeScriptУправлява персонажите, разговорите и заявките към модела
AI базаPostgreSQLAI съобщения, памет, настройки и състояние на генерирането
ОпашкаRedis + BullMQПодрежда заявките, ограничава натоварването и управлява повторните опити
ГенериранеvLLM + избран модел с отворени теглаЗарежда модела върху GPU и генерира отговорите
СнимкиСегашният R2Предварително подготвените снимки на персонажите
Обновяване на чатаSocket.IOПоказва отговора постепенно, докато се генерира
Отделната PostgreSQL база ще е за новия AI модул. Така няма да се налага да местим съществуващите профили и разговори от SQLite още при първата версия. BullMQ поддържа опашки, контрол на едновременните задачи и повторни опити; обработката трябва да е защитена от дублиране.

Едно съобщение ще преминава през следните стъпки:

  1. Потребителят избира например виртуалната „Елена“ и изпраща съобщение.
  2. BGdating проверява сесията, достъпа и лимита му. Съобщението се записва с уникален идентификатор.
  3. AI модулът създава задача в опашката. За един разговор допускаме само един активен отговор, за да се запази последователността.
  4. Worker процесът подготвя контекста: характера на Елена, езика, последните съобщения и разрешената памет за този потребител.
  5. Изпраща контекста към vLLM на GPU сървъра.
  6. Моделът генерира отговора постепенно. Частите се връщат към браузъра през Socket.IO.
  7. Готовият отговор се записва. При прекъсване остава ясно състояние „неуспешно“ или „прекъснато“, вместо да се показва като завършен.
30–40 персонажа означава 30–40 конфигурации, а не 40 заредени модела. Всеки има име, снимки, характер, интереси, начин на изразяване и правила на общуване. Един модел използва съответната конфигурация за всеки разговор.

Паметта също е отделна: разговорът на Иван с Елена няма да влиза в контекста на Георги. За начало бих използвал последните съобщения, кратко резюме на по-старите и запазени предпочитания по избор. Моделът няма автоматично да се дообучава от разговорите.

Deployment-ът бих разделил между две машини:

МашинаУслуги
Сегашният web сървърBGdating, AI API, AI worker, PostgreSQL и Redis в отделни контейнери
GPU сървърътUbuntu LTS, NVIDIA driver, NVIDIA Container Toolkit и vLLM контейнер с модела
vLLM има официален Docker deployment, а NVIDIA Container Toolkit осигурява достъпа на контейнера до видеокартата. Ще фиксираме проверени версии на контейнера, модела и настройките. vLLM Docker, NVIDIA Container Toolkit.

Между машините ще използваме частна Tailscale/WireGuard връзка. GPU услугата ще приема заявки само от нашия backend. Браузърът няма да получава нейния ключ или пряк достъп до нея.

При натоварване опашката и vLLM работят заедно: опашката определя колко задачи допускаме, а vLLM групира генерирането върху GPU. Ако заявките станат прекалено много, показваме изчакване и прилагаме лимити. Ако GPU сървърът отпадне, AI разделът временно спира, но реалният чат и останалият сайт остават работещи.

Пускането бих направил първо в тестова среда с 5 персонажа и натоварване от 1, 5, 10, 25 и 50 едновременни заявки. Ще измерим времето до първия текст, скоростта на отговорите, GPU паметта и качеството на български. След това — ограничен достъп в сайта и постепенно отваряне за всички. Точно тези измервания ще определят дали една карта стига и кой модел да използваме.
 
FalcoSoft ITS каза:
Като отделен AI модул към BGdating, с GPU сървър за генерирането на отговорите. Сайтът, потребителските профили и реалният чат продължават да работят независимо от него.

Текущия код: BGdating използва React + Vite, Node.js 24 + Express, Socket.IO, SQLite и R2, с Docker deployment. Върху това можем да стъпим.

Конкретният стек, който предлагам:

ЧастТехнологияКакво прави
ИнтерфейсСегашният React + ViteВитрина с AI персонажи и чат
Основен backendСегашният Node.js + ExpressВход, права, ограничения и достъп до AI раздела
AI модулNode.js + TypeScriptУправлява персонажите, разговорите и заявките към модела
AI базаPostgreSQLAI съобщения, памет, настройки и състояние на генерирането
ОпашкаRedis + BullMQПодрежда заявките, ограничава натоварването и управлява повторните опити
ГенериранеvLLM + избран модел с отворени теглаЗарежда модела върху GPU и генерира отговорите
СнимкиСегашният R2Предварително подготвените снимки на персонажите
Обновяване на чатаSocket.IOПоказва отговора постепенно, докато се генерира
Отделната PostgreSQL база ще е за новия AI модул. Така няма да се налага да местим съществуващите профили и разговори от SQLite още при първата версия. BullMQ поддържа опашки, контрол на едновременните задачи и повторни опити; обработката трябва да е защитена от дублиране.

Едно съобщение ще преминава през следните стъпки:

  1. Потребителят избира например виртуалната „Елена“ и изпраща съобщение.
  2. BGdating проверява сесията, достъпа и лимита му. Съобщението се записва с уникален идентификатор.
  3. AI модулът създава задача в опашката. За един разговор допускаме само един активен отговор, за да се запази последователността.
  4. Worker процесът подготвя контекста: характера на Елена, езика, последните съобщения и разрешената памет за този потребител.
  5. Изпраща контекста към vLLM на GPU сървъра.
  6. Моделът генерира отговора постепенно. Частите се връщат към браузъра през Socket.IO.
  7. Готовият отговор се записва. При прекъсване остава ясно състояние „неуспешно“ или „прекъснато“, вместо да се показва като завършен.
30–40 персонажа означава 30–40 конфигурации, а не 40 заредени модела. Всеки има име, снимки, характер, интереси, начин на изразяване и правила на общуване. Един модел използва съответната конфигурация за всеки разговор.

Паметта също е отделна: разговорът на Иван с Елена няма да влиза в контекста на Георги. За начало бих използвал последните съобщения, кратко резюме на по-старите и запазени предпочитания по избор. Моделът няма автоматично да се дообучава от разговорите.

Deployment-ът бих разделил между две машини:

МашинаУслуги
Сегашният web сървърBGdating, AI API, AI worker, PostgreSQL и Redis в отделни контейнери
GPU сървърътUbuntu LTS, NVIDIA driver, NVIDIA Container Toolkit и vLLM контейнер с модела
vLLM има официален Docker deployment, а NVIDIA Container Toolkit осигурява достъпа на контейнера до видеокартата. Ще фиксираме проверени версии на контейнера, модела и настройките. vLLM Docker, NVIDIA Container Toolkit.

Между машините ще използваме частна Tailscale/WireGuard връзка. GPU услугата ще приема заявки само от нашия backend. Браузърът няма да получава нейния ключ или пряк достъп до нея.

При натоварване опашката и vLLM работят заедно: опашката определя колко задачи допускаме, а vLLM групира генерирането върху GPU. Ако заявките станат прекалено много, показваме изчакване и прилагаме лимити. Ако GPU сървърът отпадне, AI разделът временно спира, но реалният чат и останалият сайт остават работещи.

Пускането бих направил първо в тестова среда с 5 персонажа и натоварване от 1, 5, 10, 25 и 50 едновременни заявки. Ще измерим времето до първия текст, скоростта на отговорите, GPU паметта и качеството на български. След това — ограничен достъп в сайта и постепенно отваряне за всички. Точно тези измервания ще определят дали една карта стига и кой модел да използваме.
Увеличете...
Супер, само това SQLite няма място никъде, хубаво ще го разкараш. Слагай задължително PgBouncer
 
BGdating с чат, стена и AI workers предложението за PostgreSQL + PgBouncer е разумно. Бих променил предишния план към PostgreSQL за основната платформа и AI модула, с отделни таблици и права за достъп.

Но „SQLite няма място никъде“ е прекалено категорично. SQLite е подходящ за редица приложения и сайтове; ограничението за нашето бъдещо разрастване е, че дори в WAL режим има само един едновременен писател. SQLite: приложения, WAL и конкурентен достъп.
PgBouncer управлява връзките към PostgreSQL. Позволява много приложни връзки да използват ограничен брой действителни връзки към базата. Не ускорява автоматично тежките SQL заявки и не увеличава GPU капацитета. Настройката за transaction pooling трябва да е съобразена с използваните PostgreSQL функции. Документация.

BGdating API + AI workers → PgBouncer → PostgreSQL
AI задачи → Redis / BullMQ → GPU сървър
Снимки → R2

Особено важно: докато чакаме AI отговор, не държим отворена транзакция или заета връзка към базата. Записваме съобщението, освобождаваме връзката, генерираме отговора и после записваме резултата. Така 50 активни AI разговора не означават 50 постоянно заети PostgreSQL връзки.

Преминаването от сегашния SQLite изисква преработка на достъпа до базата и тестова миграция — със запазване на профилите, паролите, съобщенията, правата и ограниченията за запазване на данни. Това е правилният момент да го планираме, преди добавянето на AI модула.
 
Майко мила, каква архитектура, какво чудо :D
Ако оставиш джипитито да ти ги измисля всичките работи, ще те банкрутира, ще те закара у кереча и ще те остави по средата на блатото да се оправяш.

Това е наситена ниша. Инвестирай 10-20 кинта за токени към някой АПИ доставчик - колкото да пробваш преди да се вкарваш във филми с хоствания на модели.
 
contra каза:
Майко мила, каква архитектура, какво чудо :D
Ако оставиш джипитито да ти ги измисля всичките работи, ще те банкрутира, ще те закара у кереча и ще те остави по средата на блатото да се оправяш.

Това е наситена ниша. Инвестирай 10-20 кинта за токени към някой АПИ доставчик - колкото да пробваш преди да се вкарваш във филми с хоствания на модели.
Увеличете...
за този модел 10-20 кинта няма да стигнат само докато се зарежда. Разбира се всичко в сайта ще се случва поетапно, но като замисъл е много добро.
 
deepdoff каза:
Стига лъга хората, това е WordPress на 2 доларов хостинг.
Увеличете...
на 1 $ е с половин нишка процесор и 1 ГБ рам :-))))
 
Трябва да си влезнал или регистриран, за да отговориш тук.

Горе