Durable messaging

[ionorg]

Durable messaging

Had a look at the Protoo repo. Its light, simple and fast.

I don't know if this is helpful OR if your happy for the system to just be able to be used for Chat and nothing else, but i will point of the issues that i see.

Your presuming no network partitions will occur currently. No Durability server side.
You have designed the Use case semantics around Rooms.

My 2 cents :) :

1. Adopt a Namespace rather than room, because the namespace is much easier to reason about in terms of all data and multi party synchronisation. Basically, it can be used for any data and not just rooms.
2. Because of message propagation delays / partitions, you need durable, at least once. Basically a message Broker. Centrifugo uses Redis and NATS, and does at least have a namespace, but is a messy system currently. Maybe also look at Resgate ( https://github.com/resgateio/resgate). It uses a namespace approach. The way the data collections are used is very nice because its holding the data as denormalized structures. This makes it very easy to do subscriptions to many clients.

Also because Dart FFI is now going ahead well, you can compile the golang client code to a c shared lib and call it directly from the Flutter Dart code without going through the Swift or java layers.
In this way the only thing really at the Dart level is the GUI and the Data - All transport aspects are in the golang. I have used this for many flutter and golang combined projects and for me it make all the transport and network code much more resilient because its golang on the client and Server.

[adwpc]

Very good suggestions! Thanks!

1. Maybe channel is better than room, Someone cat sub streams/signals from two different channels.
2. Think about signal history record, I will consider it