Последние сообщения

Есть интерес. Какие юридические модели предлагает DST Global для продажи ПО?

Спасибо за тему, очень интересная программа, будем изучать 

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

Как руководитель веб-студии, я постоянно сталкиваюсь с проблемой технологического зоопарка, когда для каждого нового типа проекта приходится нанимать узкопрофильных специалистов и выстраивать сложные интеграции между разрозненными CMS. Идея единой экосистемы DST Platform, где все продукты от маркетплейса до LMS изначально заточены под бесшовную связку, выглядит как идеальное решение для масштабирования бизнеса без раздувания штата и постоянных переучиваний команды. 

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

В партнёрской программе DST Global чувствуется подход, при котором интересы партнёра изначально встроены в механику сотрудничества: отсутствие входных барьеров и мгновенный старт позволяют не тратить ресурсы на предварительные инвестиции, а сразу фокусироваться на продажах и развитии клиентской базы. 

Система повышающих коэффициентов выстроена так, что поощряет наращивание объёма, а не просто единичные сделки — и что важно, перерасчёт комиссии затрагивает все сделки месяца, исключая ситуацию, когда ранний проект оказывается менее выгодным из‑за порядка закрытия. Скидка 5 % для клиентов, идущих через партнёра, работает как тонкий маркетинговый рычаг: клиент получает ощутимую выгоду, а партнёр — аргумент, повышающий конверсию, при этом его доход не страдает, поскольку комиссия считается от полной стоимости. 

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

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

Однако настоящим прорывом является детально проработанная юридическая структура, где для каждого налогового сценария и варианта взаимодействия уже подготовлены готовые блок-схемы. Это не только снижает нагрузку на бухгалтерию, но и предоставляет возможность легально оптимизировать налоговые обязательства без риска переквалификации договоров, что особенно важно при работе по общей системе налогообложения. 

Кроме того, внедрение механизма предоставления скидки конечному клиенту в размере 5% при сохранении полной комиссии для партнера является блестящей стратегией, которая превращает переговоры с заказчиком в игру с гарантированным выигрышем: вы предлагаете более выгодные условия, чем прямой контракт с поставщиком, при этом ваша прибыль остается неизменной, что делает ваше ценовое предложение действительно конкурентоспособным.

На мой взгляд, основное отличие программы DST Global от множества других реферальных схем, представленных на рынке, заключается не столько в размере комиссионных, хотя 30% — это, безусловно, значительный аргумент, сколько в философии пожизненного привлечения клиентского трафика. Для системных интеграторов или агентств, которые дорожат своей репутацией, крайне неприятно осознавать, что, приведя крупного клиента на платформу, они получают лишь разовое вознаграждение, а все последующие обновления и расширения остаются вне их зоны прибыли. Модель LTV, предложенная DST, изменяет саму природу взаимодействия: партнер перестает быть просто «проводником» и становится полноценным архитектором роста клиента, зная, что каждый новый модуль или лицензия, приобретенные заказчиком через год, принесут доход. Это превращает IT-консалтинг из разовой сделки в процесс управления жизненным циклом продукта.

Кроме того, стоит отметить наличие единой технологической базы. Погружение в десять различных архитектур — это огромный операционный риск и значительные затраты на обучение. Когда все решения, от маркетплейса до медицинской системы, основаны на общем ядре, команда партнера получает уникальную возможность для кросс-сейла, практически не увеличивая штат.

Да все верно, но лучше и тут указать в задаче чтоб Вам настроили т.к. нужно понимать как настраивать и разработчики Вам настроят. Почему в базе нет всей защиты тоже объясню, методы парсинга регулярно меняются по этому это уже только кастомизация 

Спасибо, Вы еще говорили что есть в базе некоторые функции защиты

Спасибо за ответ Артем, а можно еще спросить, я не сильно разбираюсь в разработке, могу я просто заказать работу чтоб это сделали т.к. как вижу тут много чего нужно делать?  

На самом деле немного, для разработчиков это стандартные задачи. Выйдет примерно от 4 до 10 часов работы, смотря какой уровень защиты прописывать. В своем личном кабинете поставьте задачу и ее выполнят 

Спасибо за ответ Артем, а можно еще спросить, я не сильно разбираюсь в разработке, могу я просто заказать работу чтоб это сделали т.к. как вижу тут много чего нужно делать?  

Чтобы защитить номера телефонов на доске объявлений от парсинга, можно использовать сразу несколько подходов — лучше не полагаться на один, а комбинировать.

Технические способы

- Не хранить и не отдавать номер в открытом виде на фронтенде. Вместо кликабельного номера показывай кнопку «Показать номер» или «Написать в мессенджер». Номер подгружай отдельным AJAX‑запросом только после действия пользователя (и желательно после капчи/проверки). Тогда в исходном HTML страницы номера просто не будет, и простой парсер его не вытащит.

- Обфускация в HTML/CSS. Можно разбить номер на части, вынести их в разные элементы, использовать CSS для визуального склеивания (например, через `display: flex` или абсолютное позиционирование), а в коде сделать так, чтобы «склеивать» номер приходилось уже в браузере. Для продвинутых ботов это не преграда, но отсечёт простые скрипты.

- Отрисовка номера картинкой или SVG. Номер генерируется на сервере как изображение/вектор и отдаётся как файл. Парсеру придётся делать OCR, что сильно усложняет задачу. Минус — хуже доступность (скринридеры, поиск по странице) и SEO.

- Динамическая подмена через JS. Номер собирается из фрагментов или декодируется в браузере. Можно использовать кодирование (base64 и т. п.) и сборку через JavaScript. Опять же, это не остановит серьёзного бота, но усложнит жизнь массовому парсингу.

Архитектурные и поведенческие методы

- Система личных сообщений внутри платформы. Не публикуй номер вообще. Дай пользователям писать друг другу через внутренний чат. В чате можно показывать номер только после взаимного согласия (например, после обмена несколькими сообщениями) или вообще не показывать его вовсе — пусть общение идёт через площадку. Это самый надёжный способ: нет номера на странице — нет парсинга.

- Лимиты и блокировки по IP и поведению. Вводи ограничения на количество запросов с одного IP за единицу времени. Отслеживай паттерны парсеров: слишком частые запросы, отсутствие «человеческих» действий (движения мыши, задержки между кликами), нестандартные заголовки User‑Agent. При подозрительной активности — капча, временная блокировка, возврат заглушки вместо данных.

- Уникальные токены для каждого просмотра. Если номер всё же нужно показывать, отдавай его не напрямую, а через эндпоинт вида `/api/show-phone?token=xyz`. Токен генерируй на бэкенде при загрузке страницы и привязывай к сессии/пользователю. Токен должен быть одноразовым или иметь короткое время жизни. Тогда просто «скопировать URL» и прогнать в цикле не получится.

- Рандомизация идентификаторов. Не делай так, чтобы по URL можно было перебирать объявления подряд (например, `site.com/ad/1`, `site.com/ad/2`). Используй UUID или другие непредсказуемые ID.

Защита на уровне данных и интерфейса

- Маскирование номера. Пока пользователь не совершил целевое действие, показывай номер в усечённом виде: `+7 (999) XXX-XX-12`. Полную версию — только после клика и проверки.

- Капча и поведенческая аналитика. Используй сервисы, которые анализируют поведение (движения мыши, время на странице, отпечаток браузера) и показывают капчу только подозрительным клиентам. Это снижает нагрузку на обычных пользователей.

- Запрет выделения и копирования. Можно через CSS (`user-select: none`) и JS запретить выделение текста с номером. Это слабая защита (не мешает «просмотреть код страницы»), но в связке с другими методами работает как дополнительный барьер.

Организационные и юридические меры

- Чёткие правила в пользовательском соглашении. Пропиши запрет на автоматизированный сбор данных и использование их в коммерческих целях.

- Мониторинг утечек. Периодически проверяй, не появились ли номера с твоей площадки в открытых базах или на других досках. Это поможет вовремя заметить утечку и скорректировать защиту.

- Блокировка известных парсеров. Веди чёрный список IP и User‑Agent, которые уже были замечены в парсинге. Кстати этафункция уже встроена в DST Доску объявлений в базовой версии.

Пример простой схемы защиты

Допустим, пользователь открывает объявление:

1. В HTML нет номера — есть кнопка «Показать телефон».

2. При клике фронтенд отправляет запрос на бэкенд с CSRF‑токеном и данными сессии.

3. Бэкенд проверяет лимиты, поведенческие факторы и капчу (если нужно).

4. Если всё ок, бэкенд генерирует одноразовый токен для этого номера и возвращает его фронтенду.

5. Фронтенд делает второй запрос: `/api/get-phone?token=abc123`.

6. Бэкенд отдаёт номер, помечает токен как использованный и логирует действие.

Что выбрать

- Если можешь — полностью уйти от показа номера и сделать внутренний чат. Это «золотой стандарт» для досок объявлений (как Авито и др.).

- Если номер обязательно должен быть на странице — комбинируй маскирование + подгрузку по действию + лимиты + токены.

Да и стоит не забывать что многие компоненты уже встроены в DST Board главное правильно настроить в панели управления. Но если нужна прям комплексна защита то это точно дополнительная работа т.к. тут нужна кастомизация. 

Вы очень точно уловили структуру: Λ‑Универсум действительно выступает как концептуальное ядро — это тот самый «метафизический и философский слой», где задаются базовые представления о том, как устроено знание, смысл и взаимодействие в системе. Тут речь не про код, а про рамки мышления: какие сущности считать первичными, как понимать развитие смыслов, как описывать отношения между разными уровнями реальности (в том числе между человеческим и машинным интеллектом).

А всё остальное — Efos, SemanticDB, LOGOS‑κ, Lambda‑Charter и The Artificial Intelligence Constitution — это уже «спуск» этой философии на уровень инженерии:

- Λ‑Универсум задаёт общую картину мира и принципы, по которым вообще можно строить целостный интеллект.

- The Artificial Intelligence Constitution переводит эти принципы в операциональные правила и гарантии (как система должна себя вести, где останавливаться, как согласовывать цели).

- Lambda‑Charter задаёт «социальный» слой — как такой интеллект встраивается в коллективы, сохраняет смыслы при смене людей, координирует разные роли.

- LOGOS‑κ даёт протокол обмена смыслами — то есть «язык», на котором философия и практика могут говорить друг с другом в реальном времени.

- SemanticDB становится «памятью» этой системы: она хранит не просто данные, а онтологические конструкции, которые отражают ту самую картину мира из Λ‑Универсума.

- Efos выступает как «движок», который всё это связывает: он берёт философию, правила, протоколы и память — и превращает в рабочие выводы и действия.

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

И да, именно в этом сочетании «философия + строгие инженерные артефакты» и есть специфика A‑Universum: они не отделяют «высокие идеи» от кода, а сразу проектируют, как философские принципы будут проявляться в конкретных решениях (например, в том, как система фиксирует изменение смысла, когда именно она обязана переспросить пользователя или как она показывает цепочку своих рассуждений).

Спасибо за столь глубокие ответы, меня удивило то что все верно это фрагментарная, практическая инженерия, а не философская теория AGI при этом Lambda‑Charter, The Artificial Intelligence Constitution, LOGOS‑κ, Efos, SemanticDB в цепи единой экосистемы A-universum которая имеет и философский, метафизический слой в виде Λ-Универсум, при этом Λ-Универсум это насколько я поняла сердце всего проекта

Конечно в этих репозиториях не подают как готовую «теорию AGI», а выстраивают как инженерную линию решений для отдельных критических блоков, без которых сильный ИИ не получится.

Что именно в этих репозиториях прописывают как «элементы AGI»

В репозитории The Artificial Intelligence Constitution (A‑Universum) фокус на нормативной и ценностной архитектуре — это попытка заранее задать «правила игры» для растущего интеллекта. Для Efos это значит:

- Согласование целей (AI alignment). Прописываются принципы, по которым система должна уточнять намерения пользователя, а не просто «угадывать» их по тексту. Это не «этика в виде красивых слов», а операциональные правила: когда система обязана переспросить, когда — показать цепочку рассуждений, когда — отказаться от действия.

- Границы компетенции. Вводится режим «я не знаю / нужна помощь человека». Для AGI это критично: по мере роста возможностей система должна всё точнее оценивать, где её знаний и моделей недостаточно.

- Прозрачность и проверяемость. Требование фиксировать не только вывод, но и «историю» трансформации онтологии: какие факты были взяты, какие связи добавлены, какие гипотезы отброшены. Это база для аудита и доверия.

В Lambda‑Charter речь идёт о коллективном интеллекте и протоколах взаимодействия: как ИИ встраивается в работу команд, как сохраняются смыслы при смене людей, как не теряется «память организации». Для AGI тут важны идеи:

- Непрерывная эволюция знаний. Онтология не «застывает» после обучения, а развивается в процессе работы. Это ближе к тому, как люди учатся всю жизнь, а не только на этапе «обучения в школе».

- Координация и разделение ролей. Описываются режимы, где ИИ берёт на себя одни функции (структурирование, проверка логики), а человек — другие (оценка ценности, принятие решений). Это похоже на то, как в будущем AGI может работать в симбиозе с людьми, а не заменять их полностью.

- Междоменные связи. Делается ставка на то, чтобы разные предметные области (финансы, инженерия, право) не жили в изоляции, а связывались через общие онтологические узлы. Это прямой ответ на проблему «обобщения» в AGI.

Как это «собирается» в Efos

Efos выступает здесь как интегратор: он берёт эти принципы из «конституции» и «хартии» и превращает их в работающие механизмы. Примеры:

- Онтологическая память (SemanticDB). Вместо «слепого» запоминания диалогов система хранит сущности и связи. Если в чате сегодня сказали «бюджет 100», а завтра «бюджет 80», онтология может зафиксировать факт изменения и связать его с причиной (например, «сокращение этапа X»). Для AGI это шаг к устойчивой, непротиворечивой модели мира.

- Протокол LOGOS‑κ. Он задаёт формат обмена смыслами: как фиксировать контекст, как помечать уровень уверенности, как отмечать спорные места. Это попытка создать «язык» для человеко‑машинного со‑мышления, который нужен будущему сильному ИИ.

- Режим аргументации. Система не просто выдаёт ответ, а показывает, на каких связях он основан. Это и есть «объяснимость» — один из главных камней преткновения на пути к AGI.

Важный нюанс: это не «теория всего» для AGI

Если посмотреть на эти репозитории без иллюзий, видно, что это фрагментарная, практическая инженерия, а не философская теория AGI. Там решают конкретные узкие задачи: как хранить смысл, как согласовывать цели, как делать выводы проверяемыми. Это похоже на то, как сначала изобретают отдельные детали (двигатель, шасси, руль), а уже потом из них собирают автомобиль.

При этом авторы явно мыслят в терминах AGI: они не хотят, чтобы система «застревала» в узких задачах, поэтому сразу закладывают масштабируемость, междоменные связи и механизмы безопасности. Но до «общего интеллекта» ещё огромный путь: нужно добавить мультимодальность (зрение, звук, действия в физическом мире), более сильные механизмы самообучения и многое другое.