Live data from Hacker News

Show HN: Actor Messaging platform

github.com

11–20 of 40 posts

Re: Show HN: Actor Messaging platform

#11
post #4
post #3

Earlier quoted context omitted.

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

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.

1: https://github.com/trevp/axolotl/wiki 2: https://github.com/agl/pond/tree/master/client/ratchet

Re: Show HN: Actor Messaging platform

#12

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 ?

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.

Re: Show HN: Actor Messaging platform

#13
post #6
post #5

Earlier quoted context omitted.

Yet somehow, Open Whisper Systems apps are doing just fine being GPL.

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...

You could ask the Moxie for extra permission to publish a non-open source version of Actor with his code on the app-store.

Re: Show HN: Actor Messaging platform

#14
post #11
post #4

Earlier quoted context omitted.

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. 1: https://github.com/trevp/axolotl/wiki 2: https://github.com/agl/pond/tree/master/client/ratchet

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.

Re: Show HN: Actor Messaging platform

#15
post #6
post #5

Earlier quoted context omitted.

Yet somehow, Open Whisper Systems apps are doing just fine being GPL.

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...

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.

Re: Show HN: Actor Messaging platform

#16
post #13
post #6

Earlier quoted context omitted.

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...

You could ask the Moxie for extra permission to publish a non-open source version of Actor with his code on the app-store.

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?

Re: Show HN: Actor Messaging platform

#18
post #10

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. If you is interested in protocol, you can read docs: 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 e…

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 ?

Re: Show HN: Actor Messaging platform

#19
post #10

Earlier quoted context omitted.

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 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 e…

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 ordinar…

> 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.

Re: Show HN: Actor Messaging platform

#20
post #2

We asked ( 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!

Thanks so much! Is there anything HN community can help you with?

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.

Post reply on HN