Actor Open Messaging Platform от разработчика Telegram

    Всем привет!

    Наша команда недавно выпустила небольшой продукт — открытую платформу для создания мессенджеров — Actor Messaging Platform.



    Всего за несколько дней после запуска мы оказались на главной Hacker News (кто из разработчиков не читает — зря), на Reddit и собрали больше 600 звезд на GitHub от разработчиков со всего мира. У нас появилось небольшое сообщество, участники которого помогают друг друге в работе и улучшении продукта. Один из участников уже реализовал несколько важных вещей, необходимые Актору. Например, достаточно высококачественные звонки.

    Если вы хотите поднять у себя платформу, то сделать это можно очень просто с помощью двух команд в Docker. Также вы можете сразу заходить в группу Actor Open Source и спрашивать совета по работе с платформой (общение идёт на английском).

    Также мы проводили эксперимент и создали публичные группы для обсуждения различных вопросов вокруг технологических проектов. Даже я, человек который уже больше 6 лет программирует под Android, подчерпнул для себя что-то новое. Наверняка, сможете и вы.
    Метки:
    Поделиться публикацией
    Комментарии 66
    • –2
      Это называется открытая платформа github.com/actorapp/actor-js/blob/master/actor.nocache.js?

      И можно много много вопросов к вашему фронтенду, github.com/actorapp/actor-js-old. Чем был аргументирован выбор coffescript?

      Почему не использовали AMD, CommonJS, es2015 (requirejs, browserify, webpack/requirejs)?

      И где когда же можно посмотреть исходники веб версии?

      PS: выглядит очень интересно и даже очень очень.
      • +5
        Это называется открытая платформа github.com/actorapp/actor-js/blob/master/actor.nocache.js?

        И можно много много вопросов к вашему фронтенду, github.com/actorapp/actor-js-old. Чем был аргументирован выбор coffescript?


        actor-js и actor-js-old – устаревшие репозитории. Все актуальные исходники лежат в github.com/actorapp/actor-platform.

        Почему не использовали AMD, CommonJS, es2015 (requirejs, browserify, webpack/requirejs)?


        Весь фронтенд написан на ReactJS, Flux собирается с использованием Webpack.

        И где когда же можно посмотреть исходники веб версии?

        github.com/actorapp/actor-platform/tree/master/actor-apps/app-web
        • 0
          brainsmith спасибо!
          Весь фронтенд написан на ReactJS, Flux собирается с использованием Webpack.
          Вот другое дело, есть где подсмотреть бестпрактис что собственно и хотел с самого начала :)
        • 0
          Весь фронтенд написан на ReactJS

          В документации написано Angular, кому верить?
          actor.readme.io/docs/apps#section-web
          • +1
            Устаревшая инфа, спасибо, поправили.
      • 0
        del
        • 0
          Спасибо нашел уже — копаюсь…
    • 0
      У вас есть аудио/видео звонки?
      • +3
        Мы сделали интеграцию с voximplant (пока без документации), а один разработчик из турции реализовал аудио, интегрировав платформу с SIP. В течение нескольких недель эта функциональность будет в основном репозитории.
        • 0
          Коллеги, если нужна будет помощь с VoxImplant — пишите, проект у вас очень интересный, будем рады помочь.

          P.S. Через VoxImplant с SIP тоже можно интегрировать при желании — все для этого есть
    • +1
      Я продолжу задавать вопросы если это вас не раздражает.

      Почему выбрали sass о переходе на bem и postcss думали?

      Не страшно использовать context с react 0.13.3 ведь context обещали только после 0.14?

      Почему не использовали flexbox ведь у вас автопрефиксер на последние три версии браузеров?

      Зачем использовали свой css grid, а не взяли существующий?

      PS: Простите, простите, мне правда очень интересно :)
      • +1
        Почему выбрали sass о переходе на bem и postcss думали?

        С sass, так сложилось исторически. Про postcss сейчас думаем, возомжно позднее перейдем на него.

        Зачем использовали свой css grid, а не взяли существующий?

        Своего грида нет, используется flexboxgrid
    • +6
      Ну раз описываете продукт, могли бы уж в статью короткое описание добавить с возможностями и требованиями. А то описание звезд и прочего, а про продукт ничего нет.

      А как связан данный продукт с Telegram? Вроде протокол называется MTProto V2 и при этом «MTProto V2 doesn't contain any kind of encryption and securing data is implemented by encapsulating of MTProto V2 in TLS.»
      Довольно странно.
      • 0
        Только историей. Я работал в Телеграме (этот акк не мой — мой забанен) и мы хотели сделать более developer-friendly телеграм что бы мы могли делать с ним какие-нибудь интересные штуки. MTProto V2 потому что это и етсь MTProto, только без шифрования. MTProto главным образом интересен своей структурой, а не шифрованием. Слой шифрования можно и заменять.

        Мы доработаем доки в будущем. Хотя у нас никто кроме как в рунете не спрашивали это.
        • 0
          Сомнительное решение. Взяли чужой протокол, урезали функционал и назвали это второй версией. А если команда телеграма доработает протокол и выпустит MTProto V2, то что будете делать? Будет два протокола с одинаковым названием?
    • +1
      Очень бы хотелось больше технических подробностей, Ваша документация достаточно скудна, особено по серверной части.
      • 0
        Просто мало кто про нее спрашивал что. Мы и не писали.
        • +1
          Просто Ваш заголовок и статья намекают, что у Вас готовый к использованию продукт — качай (покупай), ставь и работай. А получается, что это не так, взять и развернуть просто так не получится.
          Документация очень важна, хотя бы базовая, и особенно по серверной части (системные требования и требования к окружению, javadoc и пр.).
    • 0
      А насколько это именно платформа? Пока я вижу скорее вполне конкретный готовый продукт, который, да, можно развернуть на своём сервере и т.д.
      А насколько реально создать на этой основе свой проект БЕЗ переписывания собственно кода актора? Ну или скажем встроить в существующую ERP или что-то подобное, желательно не iframe-ом.
      • 0
        Вы можете взять веб-версию и адаптировать ее. Конечно нужна работа для этого (которую, кстати, можем сделать мы), кудаже без этого?
        • 0
          Так это плохо: брать готовый код и переписывать под себя. Выйдет следующее обновление и начнёт конфликтовать с моим кастомным кодом. Это вроде очевидные вещи.
          • 0
            Ниже brainsmith написал более подходящий вариант, но надо будет делать UI самим.
      • 0
        Как я уже писал ниже, имеется headless JS библиотека, реализующая апи всего месседжинга.
        В процессе интеграции можно как раз получившееся выделить в апи виджетов, чтобы иметь возможность легко интегрироваться с другими продуктами, не разрабатывая UI.
        • 0
          Ну headless js библиотека — это понятно, она в принципе и не так нужна если есть нормальный API.
          Просто получается, что если нужна какая-то минимальная кастомная функциональность (не на уровне весь UI переписать, а буквально пару элементов добавить), есть всего два варианта:
          1) переписывать существующий код и получить кучу проблем с обновлением и т.д.
          2) вообще выкинуть существующий front-end код и писать его с нуля под себя
          Как-то оба варианта выглядят немного странно.
          Вот виджеты или компоненты или что-то такое — было бы хорошо. Или наоборот, гибкая система плагинов. То есть чтобы или 1) код актора можно было относительно безболезненно встроить в существующее окружение, или 2) наоборот, кастомную функциональность можно было дописать поверх существующего кода. Второй вариант выглядит лучше, т.к. предоставляет больше возможностей, но видимо сложнее в реализации.
          • –3
            Если вы боитесь совместимости, то вы явно не слишком увлеченный разработчик. Месседжинг — большая штука и над ней надо думать и думать много. В бесконечности может быть и появится что-то, но пока нет. Второй вариант — это и есть сделать форк и разрабатывать, а потом регулярно делать rebase.

            Почему-то целому ряду проектов это оказалось полезным, а Вам кажется что нет. Сомневаюсь, что с таким подходом вы можете платить деньги.
            • +2
              Слушайте, ну это несерьёзный ответ. Речь вообще не о том, полезно это или нет. Речь о том, что вы себя позиционируете как ПЛАТФОРМУ.
              Из ваших ответов я понимаю, что речь идёт не о платформе, а просто об опенсурсном мессенджере. Что тоже неплохо и полезно и т.д., но просто совершенно другая по сути вещь. Не было бы слова «платформа» в заголовке темы, я бы и вопросы эти задавать не стал.
              • 0
                Платформа позволяющая реализовывать новые проекты на базе наших технологий. Грубо говоря вы берете Актор и на его базе строите любую возможную коммуникационную платформу. Для начала можно на отдельных вкладках держать месседжинг и ERP. А приложения точно должны быть отдельными.
                • 0
                  Нет, всё что я хотел выяснить я уже выяснил, в принципе можете дальше не объяснять, концепция понятна.
                  Можем разве что поспорить по формулировкам, хотя думаю большой пользы в этом нет. Но: если я могу создать новый продукт на базе вашего только путём форка и изменения его кода — то это не платформа, а классический опенсурсный продукт.
                • +1
                  Ну то есть: я могу взять любой опенсурсный проект, форкнуть его и на его базе создать новый. В этом вся суть опенсурса. Но это не делает из любого опенсурсного проекта платформу для создания <нужное подставить>.
                  Но ещё раз, это чисто терминологическая претензия, никаких других вопросов у меня не осталось.
                  • 0
                    Вопрос в подготовленности системы к изменениям, Актор готов для любых доработок и в ближайшем будущем появится определенная модульность.
                    • 0
                      Ну то есть модульность планируется всё-таки? Боюсь даже спрашивать когда и в каком объёме, чтобы не перевести снова разговор на вопрос о том насколько я увлечённый разработчик и сколько могу платить.
                      • 0
                        Подозреваю, что traneblow спутал контекст с соседней дискуссией. Перейду к конструктиву.
                        Да, модульность планируется.
                        Сервер уже разбит на модули, готовится апи для удобной разработки и подключения своих модулей без вмешательства в основную кодовую базу.
                        С клиентами, особенно мобильными, все сложней, но, конечно, мы активно работаем и в этом направлении. Нам самим не супер удобно поддерживать разные кодовые базы под разных клиентов.
                        • 0
                          Ну вот гляньте мой комментарий к ветке ниже, не знаю насколько будет полезно в вашем конкретном случае, но в теории проблем с такой реализацией не вижу.
            • 0
              И да, я не понял в какой момент и на каком основании разговор перешёл на деньги. Я что-то упустил в этом тексте?
              Actor OpenSource edition and Cloud solutions will be always free. We believe that communications can't have any limits.

              Или я уже что-то должен вам заплатить?
              В общем довольно странно вы реагируете на вопросы, которые вытекают из ваших же размытых формулировок.
            • 0
              Кстати да, про деньги не очень уловил. На гитхабе указана лицензия распространения MIT. За что и куда еще надо платить?
            • 0
              Присоединяясь к вопросу про «платить деньги». Вообще, это конечно нормально и все такое, но все же лучше в таком случае озвучивать ценик и условия. А то сперва говорите, мол «пользуйтесь кто хочет, велком», а потом вместо ответов на простые вопросы начинаете сегментированием заниматься, типа «так, этот скорее всего платить не будет, можно не отвечать». Не красиво.
              • 0
                Актор бесплатный и всегда будет, но нам нужно дорабатывать функционал что бы всем было хорошо. Когда человек с пеной у рта с первых слов начинает обвинять проект в том что он бесполезный, то такой человек просто напросто не сможет а) доработать опенсурс проект самостоятельно б) он никогда не заплатит что бы команда спецов для него что-то сделала. В данных запросах сквозит то, что Актор ему что-то должен. Но Актор никому не должен. Тем более, мы видим большое число тех, кто реально ставит себе решение и пользуется им и доволен и дорабатывает его. В данном случае мы должны кому-то что-то сделать. В нормальном мире — no money, no honey. Это, конечно, не привычно русскому человеку осознавать. Без денег — можете проголосовать о фиче и когда-нибудь мы ее сделаем, да и если еще увидим большое число запросов. Данный человек не готов инвестировать сравнительно немного сил в то что бы встроить такой жирный и сложный функционал как мессенджер. Точнее estimate его вложений — это не больше недели чистого времени одного программиста. Это довольно типичное желание в россии — не хочу ни за что платить, не хочу ничего делать — принесите мне сразу готовое.

                Интересен тот факт, что это единственое во всем интернете обсуждение правомерности называть Актор платформы, тк никто (кто действительно чего-то добился во всем мире) не считают это слово неправомерным. К слову, Телеграм — это тоже платформа, на базе которой можно много чего делать.
                • 0
                  Один я не увидел обвинений в бесполезности?
                  Ребят, без обид кончено, опенсорс это очень круто и спасибо вам, но у вашей компании слегка завышено самомнение.
                • 0
                  Ну я примерно понимаю за что вам предыдущий аккаунт забанили.
                  Такой поток неадеквата (на уровне неумения читать комментарии так как они написаны, а не как они вам привиделись) в ответ на вполне нейтральные (а вообще-то даже благожелательные изначально) по тону вопросы — это показатель того, что вам явно противопоказано общаться с аудиторией.
                  В общем я в этом сеансе публичной психотерапевтии дальше участвовать не готов, так что adieu, далее оставляю тему в ваше полное распоряжение.
                • 0
                  На самом деле также не увидел обвинений в бесполезности. Сорри. Не уверен, что вообще есть Open-Source код, который делает что-то понятное всем, который можно было бы назвать бесполезным и к вам это точно не относиться.
    • +1
      Идея прекрасная, но английский текс на сайте ужасен. Нужно вычитывать и исправлять
    • +2
      Для чего это нужно и как это можно использовать?
      • 0
        Чтобы сделать, например, свой корпоративный телеграм с блекджеком и на своём сервере.
      • 0
        Для любителей поразмыслить профессор Инъязов, нынешний, как мне известно, завкафедрой антиконспирологической конспирологии НИИ Истинной Истины советует мне сообщить вам, что возможно спрашивать «зачем» в этом случае не совсем корректно. Возможно, стоит спросить не «зачем это стало публичным», а «почему это стало публичным».
        • 0
          Подозреваю, что сделать сделали, а вот продать никому не смогли. Распространённая ситуация у стартапов разного рода.
          • 0
            Не совсем. Мы действительно не смогли продать. Точнее почти смогли, но мы просто не выглядим серьезно и нужно больше времени для компании.
            Open Source оказалось лучшим решением которое мы принимали и делалось оно не как «способ выжить», а как опробация идеи. Через это любая компания проходит и должна проходить. Вынудило нас действительно то, что кончаются деньги, но скорее просто потому что мы были глупы и ничего не делали, а тут начали делать. С инвесторами мы вообще с самого начала обсуждали что будем скорее всего делать Open Source.
        • 0
          прежде чем спрашивать «почему это стало публичным» надо сначала понять что это такое и для чего нужно.
    • 0
      Простите, но у вас билд фейлится

      image
      • 0
        Это просто ветка, мастер норм + иногда сам travis просто не собирает что-то без определенной причины.
    • +1
      Я не очень понял сущность продукта и хотел бы запросить у автора краткое описание, что именно понимается под open-source messaging platform.

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

      Вроде бы, все работает, но мне бы хотелось вместо протокола jabber использовать более современный протокол, хотя бы тот же mproto — 2015 год на дворе. Ну и OTR для меня так уж не принципиален, ибо шифруюсь не от спецслужб, а просто от чужих любопытных глаз. Так вот, вопрос: может ли Actor Platform полноценно заменить в данной конфигурации старый добрый jabber-сервер?
      • 0
        Я бы даже уточнил свой последний вопрос – какие примерно шаги следовало бы выполнить, чтобы Actor Platform полностью заменила в данной конфигурации старый добрый jabber-сервер?
        • 0
          Все просто, вы можете создать группу и там есть токены интеграции (лучше всего сделаны только в Android/iOS приложениях) и туда можно посылать простым POST-запросом любое сообщение в этот чат.
          • 0
            Стоп-стоп-стоп, а можно не так стремительно? Где создать группу, что такое токены интеграции, и что этому предшествует?

            Я пока что споткнулся на шаге

            You can install server with
            [ ] Docker
            [x] Directly to local machine

      • +1
        Вы можете воспользоваться Leecero — там такой сценарий строиться за пару минут.
        Более того, можно нарисовать что-то посложнее, чтобы вы спрашивали бота «что с со стойкой номер 134543» и он вам отвечал
        Но он денег стоит конечно и через себя сообщения прогоняет.
    • +4
      Вот да. Люди, опишите пожалуйста подробно с самого начала: что это вообще, зачем, что умеет и как с ним работать.
      На всякий случай: нет, сайт и документация на эти вопросы не отвечают.
      • +1
        Лучше всего сделайте несколько готовых примеров использования.
        Реквестирую вот такой: нужен мессенджер, интегрированный в некоторый абстрактный корпоративный портал.
        Интегрирован — это в плане:
        1. Использует уже существующие аккаунты
        2. Содержит элементы UI этого портала, ну в простейшем случае — главное меню хотя бы
        3. Скажем отображает какую-то кастомную информацию у контактов, вроде: должность, отдел, непосредственный руководитель
        4. Ну и получает какие-то хуки, хотя вот этот пункт я в документации как раз нашёл
        Если что-то из этого сейчас невозможно, планируется ли реализовывать?
        • 0
          Спасибо за конструктивный интерес к проекту!

          1. Имеется поддержка oauth, на данный момент – только для gmail. Доработка поддержки других провайдеров – вопрос пары часов.
          2. Имеется JS-библиотека с апи для всех функций месседжинга. Авторизация, прием-отправка сообщений, статусы сообщений, статусы пользователей, операции с группами, с контактами и т.д. Планируется создание апи виджетов.
          3. Много думаем над этим, но пока не очень понятно, как это сделать универсально. Кому-то нужно общение внутри компании – там должность, отдел, непосредственный руководитель. Кому-то – b2c сервис, с информацией вроде «Клиент», «Админ», «Модератор». Очень вероятно, что скоро что-то такое будет сделано под одного из наших клиентов. Если получится сделать это универсально, смержим с открытой платформой.
          4. Входящие хуки есть, да. Исходящие в планах на ближайшее будущее.
          • 0
            3. Много думаем над этим, но пока не очень понятно, как это сделать универсально.

            В теории довольно просто, не знаю насколько это так в применении к вашему конкретному случаю (могут быть какие-то ограничения со стороны реакта или вашей конкретной имплементации и т.д.): перед отрисовкой любого из основных элементов (контакт, сообщение и т.д.) кидаете эвент на который может подписаться внешний обработчик. Эвент синхронный, содержит логическое представление объекта (aka модель) и его html или dom-структуру. Во внешнем обработчике я могу отловить эвент и поменять html/dom по своему усмотрению. После этого происходит собственно отрисовка уже изменённого (ну или неизменённого если никто не менял) объекта.
            • 0
              Я писал проблеме универсальности не столько на уровне интерфейса, сколько на уровне API, его сущностей, методов управления ими.
              Для CRM это одно, для оргструктуры организации – это другое, для массового клиентского сервиса – третье.
              И управлять этим где-то нужно через интеграции, где-то явными действиями в клиентах.
              В общем, пока непонятно, как это выделить в универсальную абстракцию так, чтобы ее было просто использовать и расширять.
              • 0
                Ну я это предложил именно как относительно простой в реализации способ расширять почти произвольным образом UI, возможности чего я так понимаю сейчас нет.
                Ну то есть это концепция системы плагинов именно для фронтенд-части.
    • +1
      сделайте мессенджер в котором будут интегрирован голос и текст распознанный по голосу (хотя бы и средствами iOS).
    • 0
      А сколько человек задействовано в работе над проектом, если не секрет?
      • +1
        Не секрет. Пятеро.
        • 0
          А территориально где все находятся?
          • 0
            Пока что все в Питере. К чему вы клоните?
            • 0
              Пока просто интересуюсь

    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.