Пользователь
0,0
рейтинг
21 июля 2015 в 19:24

Разное → Actor Open Messaging Platform от разработчика Telegram

Всем привет!

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



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

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

Также мы проводили эксперимент и создали публичные группы для обсуждения различных вопросов вокруг технологических проектов. Даже я, человек который уже больше 6 лет программирует под Android, подчерпнул для себя что-то новое. Наверняка, сможете и вы.
Егор @traneblow
карма
35,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разное

Комментарии (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
            Пока просто интересуюсь

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