@lakeman, thank you for commenting the first part of my reflections.
You did several relevant remarks and gave interesting ideas.
The purpose of this part 2 is to discuss these points, and adapt/enhance my previous ideas.
BTW with meshms journals, when you ack message 5, you are implicitly creating an ack for all messages up to 5 as well.
This might mean that you only received version 1 and version 5 of the log, missing the versions in the middle.
But when version 5 arrives, it contains all messages in between.
Very good point.
My reasoning was: 1-to-1 communication services are a particular case of n-to-n communication services. MeshMS is a 1-to-1, multi-users chat and microblogging are an n-to-n, so I concluded, who can do more can do less, we just need to provide the necessary for implementing a chat/microblogging service.
But there is a fundamental difference between MeshMS and multi-users chat: transitionnality.
Multi-users chat uses Rhizome for replicating and keeping data on the mesh network, while MeshMS only wants to send a message to another, and remove it from the network as soon as possible once it has been received.
It would be different with a 1-to-1 communication service wanting to keep thread "alive" so as to others can read it in the future. This is not what MeshMS does.
This does not imply we can't do both over an n-to-n system, but the principle of your current implementation of MeshMS seems better for any transitional 1-to-1 communication service. It guarantees the causality partial order (there is no total order even for 1-to-1 communications) much more efficiently.
The good news is that adding relations between bundles does not prevent the specific implementation for transitional services: it is still possible to store two nodes (one for each corresponding) without any explicit causal relationships (which can be interpreted as an optimisation for this particular case). It just adds possibilities.
In my opinion, Rhizome should be service-agnostic.
This is one of the most important objective in my reflections: anyone should be able to write a service over Rhizome without modifying Rhizome protocol or implementation at all. In other words, Rhizome should support, as far as possible, any store-and-forward service, present or future.
If you accept this hypothesis, then all MeshMS related fields (sender, recipient, message signature…) should be moved out of Rhizome and implemented in MeshMS layer (in other words, in Rhizome payload).
Treating group chat more like a threaded newsgroup conversation may be more appropriate.
I was just thinking this message hierarchy for microblogging.
First, note that if you accept my hypothesis, then the choice of implementing either an IRC-like chat or a thread newsgroup in Batphone must not affect in any ways the design of Rhizome: it should be able to support both.
My first proposal was too limited for providing support for thread messages. As I had in mind IRC-like chat, I decided to use a graph with nodes (bundles) and causal relationships.
But this is quite an arbitrarily choice: why only causal relationships should be implemented?
The main idea to support thread messages is to allow any kind of relationships between nodes (a text or int attribute on edges).
For example, I represented here in black the causality and in red the thread relation:
You can imagine a service which don't care about causality, but only about threads (as a thread relationships implies causal relationships, this means causality within threads only):
The relationsihps are still defined by the upper layer (MeshMS or chat service), not by Rhizome itself (it has no idea what the upper layer relationships are).
At this point, you should make me (at least) one objection: if I were coherent with myself, as I say the relationships concern the upper protocols, why do I want to include them in Rhizome itself?
This a good question, thank you for asking ;-)
While I was trying to justify this choice, I realized that I have no good arguments.
If the graph description does not help Rhizome for exchanging bundles, I can't see any good reason.
And the fact is it does not help: the knowledge of relationships (edges) by Rhizome does not help for deciding whether retrieving the parents or the sons is more important than retrieving another independant bundle (it depends on upper services).
Moreover, you can imagine a peer which have retrieved several disjoint graphes of the same IRC-like channel: Rhizome cannot know the disjoint graphes are related (they are from the same IRC-like channel).
So we will suppose now that relationships are managed by upper services. As managing a graph is often useful for decentralised service, for avoiding code duplication, each upper service should be able to use a shared graph management tool for Rhizome (but the services which don't need it will not use it).
Your ranked bundles are a very good an idea.
In the same way that only the upper service can define the relationships, it is the only one which can decide the importance of bundles (it understands its payload).
For the upper service, it makes sense that the importance depends on the relationships. For example, if we give more importance to newer messages, it makes sense to increase the importance of an older message if there is a recent answer depending on it.
Thus, the idea is to add a score field in Rhizome bundles/nodes (for example a value between 0 and 255), which will be set only by the upper services.
Rhizome will use this value for removing less important bundles when it has no more space available. Without any need to know the relationships.
The drawback is that Rhizome cannot decide to priorize a service over another. We can still do it manually (if I decide that MeshMS is more important than IRC-like channels, I can give 0 to 255 to MeshMS bundles and 128 to 255 to IRC bundles).
To summarize the state of my reflections today, here is how I imagine the improvements:
I have not totally abandoned the idea of putting the graph management into Rhizome, but for the moment I think it is better over. What do you think?
Of course, this state of my reflections can (and will) change as soon as you will give some feedbacks, or even on its own ;-)