Useful contributions - What is needed?

[gaolaowai]

Starting this thread here to ask what kind of contributions are currently needed, where current roadblocks are, and what we (random people on the internet who are interested) can do to help move Lunatic forward.

I'm new to Rust, having mostly programmed in C++, C, JS, and Python for work (but play with Elixir/Lisp/Scheme on the side) and I'm learning Rust specifically so that I can use Lunatic for some projects. I've also written a distributed application framework for my employer and have experience with the headaches involved.

I'd just love (and those who follow me) to know where we can help out most.

Thanks!

[bkolobara]

Hi @gaolaowai, thank you for starting this thread!

At the moment we are re-working the way messages are serialized before they are sent between processes. You can read more about one of the approaches I would like to take in this discord thread: https://discord.com/channels/779332282531184680/815161515765268511/876230973262561361

The biggest drawback of the current approach is dealing with the serialization of structs that contain some opaque host side resources. I would love to hear more from the community, what do you think about the UUID idea? This would greatly simplify serialization and allow us to just use any of the already existing formats (msgpack, bincode, ...). Having UUIDs would also make logging much better, as all the IDs would be completely unique.

Our next development step will be the development of distributed lunatic. There was some discussion on the discord about it as well. I would really appreciate some help with this task. Originally I wanted to use nats.io to send messages between lunatic nodes. This would greatly simplify the implementation, as the nats library would take care of connecting nodes to the cluster, encryption of messages, authentication and other "hard" to get right features. One drawback here would be the introduction of an external dependency (nats) that you would need to set up and run.

We could also take the Erlang approach and just directly connect all lunatic nodes. In this case we would need to take care of encrypting all the messages between nodes. I don't even think there is any encryption be default in Erlang, that's why fly.io is so popular for Elixir projects. They give each application a private network based on WireGuard, so the messages never leave your private network. We could also push out this concern to the user to keep our implementation simple. However, I would prefer not to have an unsecure by default approach.

There are many tradeoffs with both approaches. I would love to pick your mind and hear what you think about it!

[gaolaowai]

Is there an open alternative to Ockam? They seem young and might disappear at any moment, taking their codebase with them.

[sleipnir]

Is there an open alternative to Ockam? They seem young and might disappear at any moment, taking their codebase with them.

Ockam is a new and very promising project, I've been talking to the core team members and they've told me they're focused on making the Rust version as robust as possible as soon as possible.
We can ask the status of the CTO and main developer of the Ockam team @mrinalwadhwa. I don't remember any other Open Source project with a proposal as mature ideas as this one.
There is another project that implements Distributed Erlang for Rust, called erl_dist. The advantage is that Lunatic Actors could talk to Erlang Actors within the same network, that would be amazing. I remember it supported up to OTP 19 at least.

[sleipnir]

@gaolaowai @bkolobara I've been thinking and a good alternative would be to use the rsocket protocol as it allows for backpressure and delivery guarantees that are important for the implementation. Also has rust support with tokio

https://rsocket.io/
https://github.com/rsocket/rsocket-rust

[bkolobara]

Thanks for the link @sleipnir, I will check it out. I also agree with you that ideally we would abstract away the higher level concepts from the transport layer to make it pluggable like Erlang's implementation: http://erlang.org/doc/apps/erts/alt_dist.html

[sleipnir]

https://github.com/rsocket/rsocket-rust/tree/master/rsocket-transport-wasm

[gaolaowai]

I think the 128bit UUID idea is good. As for serialization, I think we need it and here's why: different people are going to be targetting WASM from potentially different languages, all of which store their data differently, different memory models, different (in distributed systems) bit orders (risc vs. cisc CPUs). So annoying as it is, serialization is required. So which one to go with then? We have to thing about which formats are widely supported across different languages, what structures are supported, transformation speed, etc... there's no perfect choice here, but only a series of compromises. JSON, being text, is nice in that it's really a universal exchange format that's easy to use with web applications. PITA with it comes in following proper serialization standards with it, edge cases, etc. MsgPack is a nice compromise in that it has fast serialization/deserialization without the need to specify the message format ahead of time. It's also widely supported across different outside systems and languages.

This article did some exploration of JSON/MsgPack/protobuff that's worth taking a look at.
https://medium.com/@hugovs/the-need-for-speed-experimenting-with-message-serialization-93d7562b16e4