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?
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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! :)
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 ?
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.
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.
Thank you for sharing the code! I read through your documentation and noticed there is documentation of server-client but not server-server. How do you achieve a multi-server architecture? Is it simply to scale the Postgre database and connect more server frontend to it and load balance over those frontends? Or is there some inter server protocol as well?
Actor is built on top of Akka that have built-in support for node-to-node communication. When our CTO will wake up, he will answer in details how it works.
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 ?
> are you using both websocket and your new protocol ? what is the different usecases for each ?
Yes. We use at lowest layers websocket and TCP just for transmitting binary frames. Our protocol is very complicated for providing stable cnnections.
> also, did you measure power consumption on platforms like android ?
This is not how cellular data works. It warms up radio before any active transmit and it lasts for much more that 5 seconds after last byte was sent. This doesn't help you at all. We have small problems in our clients with power consumption, but this is in application level, not networking.
> 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.
In all cases it depends how you use them in application level.
Actually for network layer we need to implement much more complicated things: replace TLS. This is dangerous, of course. But TLS is source for HUGE lags in networks because of it's triple handshake. And on mobile networks ping usually big and application can try to connect in several seconds. When you remove TLS (like QUIC) then time to connect drops to 200ms and you don't need to wait for successful connection that also reduces latency. This is level of quality that Actor Platfrom try to satisfy.
