11 ms·

Show HN: Actor Messaging platform

110 points by ex3ndr 11y ago

ex3ndr 11y ago
We asked (https://news.ycombinator.com/item?id=9757243 https://news.ycombinator.com/item?id=9757243) what we can do with our project and make a promise that we will release it to OpenSource. Here we are!
- jcr 11y ago
  Thanks for opening the source. You might want to contact the EFF to see if they will add you to their "scorecard" for secure messaging programs: https://www.eff.org/secure-messaging-scorecard https://www.eff.org/secure-messaging-scorecard
  - ex3ndr 11y ago
    I want to implement full e2e encryption with Moxie's encryption and I can't because it is GPL( GPL is not comparable with mobile apps at all. Also I think that implementing encryption by ourselves will be mistake. May be some one can contribute?
    - nzp 11y ago
      Yet somehow, Open Whisper Systems apps are doing just fine being GPL.
      - ex3ndr 11y ago
        Yes, this is their software and they can do whatever they want. I think Moxie just don't care. In Actor we respect licenses and all other legal stuff. More information about GPL and Mobile Stores: https://www.fsf.org/blogs/licensing/more-about-the-app-store-gpl-enforcement https://www.fsf.org/blogs/licensing/more-about-the-app-store...
        belorn 11y ago
        You could ask the Moxie for extra permission to publish a non-open source version of Actor with his code on the app-store.
        ex3ndr 11y ago
        I tried, no luck. And any fork will need this permission again? I believe that crypto implementations need to be in public domain. What if people can't use some software and will stay unsecured?
        nzp 11y ago
        You could ask for an exemption from OWS for the App Store (and others) distribution. I don't know if OWS contributors retain individual copyright or just transfer it to OWS (ala GNU contributors to FSF). If former, it could be complicated, but it's worth a try.
        aorth 11y ago
        The reason you aren't allowed to publish applications containing GPL'd source code in the Apple Store isn't because the GPL forbids it, it's because Apple forbids it; they have an unnatural hatred for the GPL. From what I can see the Signal application uses GPLv3'd code. I have no idea how it is still available in the Apple store.
    - Rafert 11y ago
      You're free to re-implement the public-domain protocol[1] under your own license. Pond has a 3-clause BSD licensed Golang implementation[2] that Moxie even references in the Axolotl announcement blog post. 1: https://github.com/trevp/axolotl/wiki https://github.com/trevp/axolotl/wiki 2: https://github.com/agl/pond/tree/master/client/ratchet https://github.com/agl/pond/tree/master/client/ratchet
      - ex3ndr 11y ago
        Re-Implementing cryptography is VERY costly operation that we cannot afford now. I already implemented in the past crypto for Telegram, there waere a lot of small mistakes in the implementation part. Even Telegram have many resources, but we haven't.
        deleted 11y ago
        [deleted]
        Rafert 11y ago
        Understandable. Other than that the project looks quite interesting -- good luck!
    - lmm 11y ago
      You could make a GPLed APK available. Not user friendly but it will allow those who really care to get the most secure possible version.
    - aorth 11y ago
      I don't like the way you've framed the debate. As I said below, the reason you aren't allowed to publish applications containing GPL'd source code in the Apple Store isn't because the GPL forbids it, it's because Apple forbids it; they have an unnatural hatred for the GPL. Whether you like copyleft licenses or not is irrelevant. They are the wishes of the person who developed the original code.
      - johncolanduoni 11y ago
        That's not entirely true. They forbid using other people's code licensed under the GPL because it is not possible to meet its conditions[1]. Basically, they don't want to deal with the possible resulting copyright lawsuit. If you own the copyright to all the code used in your app, then there is no issue. [1]: http://apple.stackexchange.com/a/59495/101602 http://apple.stackexchange.com/a/59495/101602
    - dllthomas 11y ago
      Incorporate Moxie's encryption as a module. Distribute this version for those who want it (and have jailbroken phones, where relevant), and use it as a reference implementation when you build an alternative that is more generally available. Meanwhile, criticize Apple's anti-gpl policies for making their users less secure.
- jakozaur 11y ago
  Thanks so much! Is there anything HN community can help you with?
  - ex3ndr 11y ago
    Actually, anything! Scala developers can build some features to server (like good API, hubot integrations, etc...), iOS/Android/Web devs can improve applications. Someone can try to translate platform to various languages. But we need good quality, this is the main point. We don't want to be another opensource-based company that don't have resources to build good software and use small community opportunities to build something that at least works, we want quality. This is essential for messaging: speed, reliability and UI/UX.
  - ex3ndr 11y ago
    Maybe someone wants to unite to build something bigger. We have awesome quality messaging, but it is nice to have voice/video. Also for voice/video it is good to have messaging too. Maybe someone building encrypted email provider? Or just email provider? Email and Messaging are good together. File sharing? Aero FS? We can integrate messaging in any service, and it can look like "chat heads" of Facebook. Imagine, from any task in Issue Tracker you can open conversation with an author of issue/comment? Nice! No one has done this yet. "Actor" is named after Actor Model, where Actors are small valuable pieces of code that can integrate with other Actors of different kinds. The same idea can be for services, build deeply integrated experience of tools that we are using. This is dreams, but i have not evidence that they can't be true.
wiradikusuma 11y ago
Is this like Atlas from Layer.com? I.e. open-sourced client SDK for their proprietary messaging platform?
- ex3ndr 11y ago
  No, it is completely open source with server too. This is main difference from Layer.
  - wiradikusuma 11y ago
    Thanks! I'm in the early stage of evaluating Atlas/Layer, and I think I'll play with your product this weekend. How do you plan to make money? I don't see any "Pricing" page.
    - ex3ndr 11y ago
      We don't know how we will make money. Currently, we provide consulting and implement features for money. Maybe at some point donations, but i never ever seen that donations can help build big and complex stuff like this. I believe that if Actor will be quite popular we will find some way to do money, this is what i learned from my experience at Telegram.
sandGorgon 11y ago
why did you not use something like websockets and layer on your security layer ? I see you have done a fair bit of sophisticated work inside your "core-async" library. Was there nothing like socket.io-client, etc that you could have used for your transport layer and on the android client side ?
- ex3ndr 11y ago
  core-async is extension of core project for async environments with real multithreading. It is mostly contain working with data and syncing it with UI. If you is interested in protocol, you can read docs: http://actor.readme.io/docs/protocol http://actor.readme.io/docs/protocol Sources of networking is inside core project. You will see how really complicated it is. Networking layer are also handle cases when servers are crashing randomly and restoring everything on clients after restoring. We reimplement low-level networking because all underlying protocols are still bad. TCP usually freezes randomly especially in mobile networks. (this is very long story and i will post something someday about this) WebSocket (that we are actually using) are freezing too. Good protocol is QUIC from google, but it is written on C++ (i don't like it) and quite new. Also most of the libraries a buggy, we implement simple and time-proven solution (that was done when i worked at Telegram). Also I can't believe in socket.io because we are able to handle 1M connections per server and no one on Node.js ever available to do this.
  - sandGorgon 11y ago
    are you using both websocket and your new protocol ? what is the different usecases for each ? also, did you measure power consumption on platforms like android ? one of the big problems with a lot of protocols is the impact of power consumption. I will tradeoff 5 seconds of latency if it reduces power consumption by 50% on my phone. Actually - this is one of the questions that I have: which library should an ordinary app use to have decent power consumption performance for a messaging platform. Fast response and realtime is not a criteria. Websockets, XMPP, long polling ?
    - ex3ndr 11y ago
posnet 11y ago
The use of unicode in the source is interesting. ← and ⇒
- CatsoCatsoCatso 11y ago
  Could you link to the sources you're talking about? That sounds interesting.
  - prettynatty 11y ago
    https://github.com/actorapp/actor-platform/blob/master/actor-server/actor-peer-managers/src/main/scala/im/actor/server/peermanagers/GroupPeerManager.scala#L128 https://github.com/actorapp/actor-platform/blob/master/actor...
    - gh0zt 11y ago
      Those are just Scala unicode operators http://scala-lang.org/files/archive/spec/2.11/01-lexical-syntax.html#identifiers http://scala-lang.org/files/archive/spec/2.11/01-lexical-syn.... They are equivalent to <- and =>
0xdragon 11y ago
This is great! Any chance of making it so that it can use email instead of SMS in the mobile app though? SMS gets expensive really quickly in Australia. Thanks again! :)
- ex3ndr 11y ago
  We provide SMS authentication for free. If it will be costly for us, then we will switch to Twitter's free sms authentication solution. But we have email authentication now and we just not implemented it apps. We also can to do OAuth2 authentication.
  - 0xdragon 11y ago
    Yeah, that's what I meant. Is it possible to get mobile app authentication working with email? Thanks!

110 points by ex3ndr 11y ago

We asked (https://news.ycombinator.com/item?id=9757243 https://news.ycombinator.com/item?id=9757243) what we can do with our project and make a promise that we will release it to OpenSource. Here we are!

jcr 11y ago
Thanks for opening the source. You might want to contact the EFF to see if they will add you to their "scorecard" for secure messaging programs: https://www.eff.org/secure-messaging-scorecard https://www.eff.org/secure-messaging-scorecard
- ex3ndr 11y ago
  I want to implement full e2e encryption with Moxie's encryption and I can't because it is GPL( GPL is not comparable with mobile apps at all. Also I think that implementing encryption by ourselves will be mistake. May be some one can contribute?
  - nzp 11y ago
    Yet somehow, Open Whisper Systems apps are doing just fine being GPL.
    - ex3ndr 11y ago
      Yes, this is their software and they can do whatever they want. I think Moxie just don't care. In Actor we respect licenses and all other legal stuff. More information about GPL and Mobile Stores: https://www.fsf.org/blogs/licensing/more-about-the-app-store-gpl-enforcement https://www.fsf.org/blogs/licensing/more-about-the-app-store...
      - belorn 11y ago
        You could ask the Moxie for extra permission to publish a non-open source version of Actor with his code on the app-store.
        ex3ndr 11y ago
        I tried, no luck. And any fork will need this permission again? I believe that crypto implementations need to be in public domain. What if people can't use some software and will stay unsecured?
      - nzp 11y ago
        You could ask for an exemption from OWS for the App Store (and others) distribution. I don't know if OWS contributors retain individual copyright or just transfer it to OWS (ala GNU contributors to FSF). If former, it could be complicated, but it's worth a try.
      - aorth 11y ago
        The reason you aren't allowed to publish applications containing GPL'd source code in the Apple Store isn't because the GPL forbids it, it's because Apple forbids it; they have an unnatural hatred for the GPL. From what I can see the Signal application uses GPLv3'd code. I have no idea how it is still available in the Apple store.
  - Rafert 11y ago
    You're free to re-implement the public-domain protocol[1] under your own license. Pond has a 3-clause BSD licensed Golang implementation[2] that Moxie even references in the Axolotl announcement blog post. 1: https://github.com/trevp/axolotl/wiki https://github.com/trevp/axolotl/wiki 2: https://github.com/agl/pond/tree/master/client/ratchet https://github.com/agl/pond/tree/master/client/ratchet
    - ex3ndr 11y ago
      Re-Implementing cryptography is VERY costly operation that we cannot afford now. I already implemented in the past crypto for Telegram, there waere a lot of small mistakes in the implementation part. Even Telegram have many resources, but we haven't.
      - deleted 11y ago
        [deleted]
      - Rafert 11y ago
        Understandable. Other than that the project looks quite interesting -- good luck!
  - lmm 11y ago
    You could make a GPLed APK available. Not user friendly but it will allow those who really care to get the most secure possible version.
  - aorth 11y ago
    I don't like the way you've framed the debate. As I said below, the reason you aren't allowed to publish applications containing GPL'd source code in the Apple Store isn't because the GPL forbids it, it's because Apple forbids it; they have an unnatural hatred for the GPL. Whether you like copyleft licenses or not is irrelevant. They are the wishes of the person who developed the original code.
    - johncolanduoni 11y ago
      That's not entirely true. They forbid using other people's code licensed under the GPL because it is not possible to meet its conditions[1]. Basically, they don't want to deal with the possible resulting copyright lawsuit. If you own the copyright to all the code used in your app, then there is no issue. [1]: http://apple.stackexchange.com/a/59495/101602 http://apple.stackexchange.com/a/59495/101602
  - dllthomas 11y ago
    Incorporate Moxie's encryption as a module. Distribute this version for those who want it (and have jailbroken phones, where relevant), and use it as a reference implementation when you build an alternative that is more generally available. Meanwhile, criticize Apple's anti-gpl policies for making their users less secure.
jakozaur 11y ago
Thanks so much! Is there anything HN community can help you with?
- ex3ndr 11y ago
  Actually, anything! Scala developers can build some features to server (like good API, hubot integrations, etc...), iOS/Android/Web devs can improve applications. Someone can try to translate platform to various languages. But we need good quality, this is the main point. We don't want to be another opensource-based company that don't have resources to build good software and use small community opportunities to build something that at least works, we want quality. This is essential for messaging: speed, reliability and UI/UX.
- ex3ndr 11y ago
  Maybe someone wants to unite to build something bigger. We have awesome quality messaging, but it is nice to have voice/video. Also for voice/video it is good to have messaging too. Maybe someone building encrypted email provider? Or just email provider? Email and Messaging are good together. File sharing? Aero FS? We can integrate messaging in any service, and it can look like "chat heads" of Facebook. Imagine, from any task in Issue Tracker you can open conversation with an author of issue/comment? Nice! No one has done this yet. "Actor" is named after Actor Model, where Actors are small valuable pieces of code that can integrate with other Actors of different kinds. The same idea can be for services, build deeply integrated experience of tools that we are using. This is dreams, but i have not evidence that they can't be true.

wiradikusuma 11y ago

Is this like Atlas from Layer.com? I.e. open-sourced client SDK for their proprietary messaging platform?

ex3ndr 11y ago
No, it is completely open source with server too. This is main difference from Layer.
- wiradikusuma 11y ago
  Thanks! I'm in the early stage of evaluating Atlas/Layer, and I think I'll play with your product this weekend. How do you plan to make money? I don't see any "Pricing" page.
  - ex3ndr 11y ago
    We don't know how we will make money. Currently, we provide consulting and implement features for money. Maybe at some point donations, but i never ever seen that donations can help build big and complex stuff like this. I believe that if Actor will be quite popular we will find some way to do money, this is what i learned from my experience at Telegram.

sandGorgon 11y ago

why did you not use something like websockets and layer on your security layer ? I see you have done a fair bit of sophisticated work inside your "core-async" library. Was there nothing like socket.io-client, etc that you could have used for your transport layer and on the android client side ?

ex3ndr 11y ago
core-async is extension of core project for async environments with real multithreading. It is mostly contain working with data and syncing it with UI. If you is interested in protocol, you can read docs: http://actor.readme.io/docs/protocol http://actor.readme.io/docs/protocol Sources of networking is inside core project. You will see how really complicated it is. Networking layer are also handle cases when servers are crashing randomly and restoring everything on clients after restoring. We reimplement low-level networking because all underlying protocols are still bad. TCP usually freezes randomly especially in mobile networks. (this is very long story and i will post something someday about this) WebSocket (that we are actually using) are freezing too. Good protocol is QUIC from google, but it is written on C++ (i don't like it) and quite new. Also most of the libraries a buggy, we implement simple and time-proven solution (that was done when i worked at Telegram). Also I can't believe in socket.io because we are able to handle 1M connections per server and no one on Node.js ever available to do this.
- sandGorgon 11y ago
  are you using both websocket and your new protocol ? what is the different usecases for each ? also, did you measure power consumption on platforms like android ? one of the big problems with a lot of protocols is the impact of power consumption. I will tradeoff 5 seconds of latency if it reduces power consumption by 50% on my phone. Actually - this is one of the questions that I have: which library should an ordinary app use to have decent power consumption performance for a messaging platform. Fast response and realtime is not a criteria. Websockets, XMPP, long polling ?
  - ex3ndr 11y ago

posnet 11y ago

The use of unicode in the source is interesting. ← and ⇒

CatsoCatsoCatso 11y ago
Could you link to the sources you're talking about? That sounds interesting.
- prettynatty 11y ago
  https://github.com/actorapp/actor-platform/blob/master/actor-server/actor-peer-managers/src/main/scala/im/actor/server/peermanagers/GroupPeerManager.scala#L128 https://github.com/actorapp/actor-platform/blob/master/actor...
  - gh0zt 11y ago
    Those are just Scala unicode operators http://scala-lang.org/files/archive/spec/2.11/01-lexical-syntax.html#identifiers http://scala-lang.org/files/archive/spec/2.11/01-lexical-syn.... They are equivalent to <- and =>

0xdragon 11y ago

This is great! Any chance of making it so that it can use email instead of SMS in the mobile app though? SMS gets expensive really quickly in Australia. Thanks again! :)

ex3ndr 11y ago
We provide SMS authentication for free. If it will be costly for us, then we will switch to Twitter's free sms authentication solution. But we have email authentication now and we just not implemented it apps. We also can to do OAuth2 authentication.
- 0xdragon 11y ago
  Yeah, that's what I meant. Is it possible to get mobile app authentication working with email? Thanks!