Reflections on Rhizome protocol

[®om]

I wrote some reflections on Rhizome protocol here:
http://dl.rom1v.com/rhizome/rhizome.html

Thank you for your feedbacks.

®om

[Jeremy Lakeman]

Data expiration

The local rhizome store should be thought of as a cache. After holding
onto any content for a while it should be dropped to save space.
In "normal" use we expect the rhizome store to fill all space
allocated to it, and remain full.
We intend to create a single ranked list of all bundles in the cache,
ordered by some set of priorities.
When a higher ranked item becomes known, lower ranked items would be
expired to make room.

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.


Causality in multi-user chat

Yeah, we know. Broadcast messaging was a quick hack based on 2 party
messaging, which in turn was designed to behave like SMS messaging.
Multi-user chat/micro blogging is a very different type of problem
that requires a different solution.
Treating group chat more like a threaded newsgroup conversation may be
more appropriate.
Each message should at least indicate the message it is replying to.

If this rhizome store is not interested in following the conversation
at all, it should affect the ranking order of the bundles so they are
allowed to expire out of the cache.


I've been toying with the idea of building a git-like object store to
replace the rhizome store.
The base object that would be stored might look something like;

[count of references, total size of referenced objects]
[
[reference of other object],
...
]
[binary data]

A git-like blob would have no refs, just the file contents. A git-like
tree would have references to files and trees, plus meta data like
names.
A large file could be stored in a tree of objects for more efficient
storage. If there are any failures during transfers, only small pieces
of the file would need to be thrown away.
A multi-part file like a zip archive, might be stored with each
sub-file in a different stored object. Hopefully, if the sub-file is
the same, the content hash would also be the same, reducing storage
requirements.
A rhizome manifest would include a reference, some meta data and a
signature, similar to a git tag.
Each object could be referenced by multiple objects.

The application layer would ask the object store to add, remove and
transfer objects from other stores. eg rhizome would store and remove
signed manifests.
Internally the object store can remember the list of objects added by
the application in a root object, as well as a log of all insertions
and removals. The log object can be announced to other nodes for very
efficient synchronisation.
This way the application layer can store any kind of object graph. And
when an object is removed, the object store can traverse the entire
store for garbage collection without needing special case code for
each object type.

In a multi-user chat conversation, each message would have a signed
manifest, and references to the previous relevant messages in the
conversation.

> --
> You received this message because you are subscribed to the Google Groups
> "Serval Project Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to serval-project-dev...@googlegroups.com.
> To post to this group, send email to
> serval-proje...@googlegroups.com.
> Visit this group at
> http://groups.google.com/group/serval-project-developers?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[®om]

Here is the continuation of my reflections after your answer:
http://dl.rom1v.com/rhizome/rhizome_2.html

[Andrew Bettison]

Hi �om,

It is good to read your thoughts on Rhizome and MeshMS. I am glad you
are putting effort into this area.

Romana, Corey, Jeremy, Paul and I have had many discussions over the
last year about the design and architecture of Rhizome and its existing
applications such as Batphone software upgrades, MeshMS and Serval Maps,
plus future Rhizome applications such as voice mail, citizen journalism,
disaster situation awareness, shared documents, etc.

Jeremy has already explained a little of what our plans are. Your
efforts have made it very apparent that we lack clear public
documentation of our designs and intentions for Rhizome. Some of your
ideas resemble ideas of our own, which is great. Some ideas we have
considered and rejected, for reasons that we have not explained
publicly, but ought to.

Thanks to your initiative, in the next week or so I plan to
significantly expand the "Rhizome" page on our Wiki, with as much
information as I can, as clearly as possible, hopefully with diagrams.
This should help you, and the rest of the world, to get a much better
idea of what we want Rhizome to be, and how we plan to solve certain
problems, and which problems we do not want to solve.

Another thing we ought to do, if you would like, is to arrange a Skype
call with you soon. A live question-and-answer discussion is faster and
more productive that email messages back and forth, in my experience,
with the only drawback that the conversation is not available to others
afterwards.

Regards,
Andrew Bettison

On 14/03/13 03:50, �om wrote:
> Here is the continuation of my reflections after your answer:
> http://dl.rom1v.com/rhizome/rhizome_2.html
>
>

--
Andrew Bettison
Senior Software Engineer
and...@servalproject.org | Mobile +61 407185656 | Skype ajbettison

[®om]

Thank you for your answer.

Another thing we ought to do, if you would like, is to arrange a Skype
call with you soon.  A live question-and-answer discussion is faster and
more productive that email messages back and forth, in my experience,
with the only drawback that the conversation is not available to others
afterwards.

Unfortunately, my level of spoken English is not enough.
(by Skype, I guess you meant XMPP: I would not have installed this snitch #troll)

Thanks to your initiative, in the next week or so I plan to
significantly expand the "Rhizome" page on our Wiki, with as much
information as I can, as clearly as possible, hopefully with diagrams.

That would be great!
 

Some ideas we have considered and rejected, for reasons that we have

not explained publicly, but ought to.

[…]

and how we plan to solve certain problems, and which problems we do

not want to solve.

Meanwhile, could you summarize them here?

Regards,

®om

[®om]

Some more thoughts/remarks/questions.

About services and current implementation

I said:

Rhizome should be service-agnostic.

We seem to agree on that point:

Rhizome software does not encapsulate any application-specific logic

However, the current implementation does (ex1, ex2).
Therefore, if someone wants to create a new service, they cannot without modifying Rhizome itself ("Unsupported service").

What do you think about it?

Do you think anyone should be able to create a new service over Rhizome without modifying it? Or is it one of the ideas you rejected?

Some ideas we have considered and rejected, for reasons that we have not explained publicly, but ought to.

In other words, is it something to be fixed, or is it the expected behaviour?


About layer separation

I wrote:

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.

 

I think this is very important. But I added:

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

I was wrong. I forgot one import point: Rhizome is not only a transfer protocol, it manages storage too. So a user must (at least) be able to extract bundles from some criteria (service, sender, recipient, …). Therefore, Rhizome must be able to identify some of these meta-data. The good news is that it does not prevent the service-agnosticism ;-)


About manifests table in database

Why do you store some fields both as manifests table columns and as key=value in manifests.manifest value?


About ranking

I wrote:

the idea is to add a score field in Rhizome bundles […] which will be set only by the upper services.

When I wrote that, I had in mind the ability to forget/delete old/irrelevant messages from a chatroom or a µ-blogging service. It can have some drawbacks (e.g. someone can force priority max for all its bundles).

You say exactly the opposite:

Rhizome does not rank (prioritise) based on the content of payloads

Could you explain your reasons, please?

In that case, Rhizome can only prioritise by meta-data:

most meta data is created by Rhizome to identify and prioritise the payload, eg, id, filesize, filehash, version, etc.

But do you think these meta-data are interesting enough for prioritising?

Also, you wrote:

Rhizome does not record the originating or transited nodes of any payload, so nodes cannot rank (prioritise) payloads based on point of origin, only on available meta data

I don't understand: what is manifests.sender in Rhizome database?
(but I agree, rank must not depend on originating nodes)


Thank you for your answers.
®om

[Jeremy Lakeman]

On Thu, Apr 4, 2013 at 12:26 AM, ®om <romain...@gmail.com> wrote:

Some more thoughts/remarks/questions.

About services and current implementation

I said:

Rhizome should be service-agnostic.

We seem to agree on that point:

Rhizome software does not encapsulate any application-specific logic

However, the current implementation does (ex1, ex2).
Therefore, if someone wants to create a new service, they cannot without modifying Rhizome itself ("Unsupported service").

What do you think about it?

Do you think anyone should be able to create a new service over Rhizome without modifying it? Or is it one of the ideas you rejected?

Some ideas we have considered and rejected, for reasons that we have not explained publicly, but ought to.

In other words, is it something to be fixed, or is it the expected behaviour?

Import, export & network transfers should only care that the manifest is signed, the content matches the hash, and the version cannot go backwards. These operations should allow for future manifests with new and different content.

Anything else is a bug to be fixed.

Add & extract may enforce more rules about content structure as these operations need to know if the payload is encrypted and if the correct key can be derived.

Other service specific features should be application specific. Though these applications may be built into servald the above commands should still function without any knowledge of application specific rules.

 

About layer separation

I wrote:

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.

 

I think this is very important. But I added:

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

I was wrong. I forgot one import point: Rhizome is not only a transfer protocol, it manages storage too. So a user must (at least) be able to extract bundles from some criteria (service, sender, recipient, …). Therefore, Rhizome must be able to identify some of these meta-data. The good news is that it does not prevent the service-agnosticism ;-)

We are thinking about a new, more compact manifest format.
We're thinking about splitting the meta data information into perhaps these layers;
1 - verify integrity and versioning for the transport and storage systems.

2 - support prioritisation / ranking decisions.

3 - identify the recipient and decryption key
4 - application specific which may also be encrypted but "add" and "extract" don't count as part of the payload, eg filename & mime type.

We're thinking that the application layer would start with a mime type, and may support something like multi-part mime encoding.

We're thinking of compressing everything we can with something like this;
https://github.com/servalproject/smaz

And supporting future unknown fields with something like;
http://en.wikipedia.org/wiki/Protocol_Buffers

About manifests table in database

Why do you store some fields both as manifests table columns and as key=value in manifests.manifest value?

For convenience and integrity. The manifest must be provided in its original form to verify the signature. But this form can't be searched and indexed efficiently by the sqlite database engine.

About ranking

I wrote:

the idea is to add a score field in Rhizome bundles […] which will be set only by the upper services.

When I wrote that, I had in mind the ability to forget/delete old/irrelevant messages from a chatroom or a µ-blogging service. It can have some drawbacks (e.g. someone can force priority max for all its bundles).

You say exactly the opposite:

Rhizome does not rank (prioritise) based on the content of payloads

Could you explain your reasons, please?

 

The rank could be influenced by some well defined meta-data that the application has provided in a standard way. eg "This content expires quickly", "This is published by serval".
But this meta-data cannot be changed after the content is added by the originator as it must match the signature.
Also (as above) the transport layer cannot rank based on layer 4 information or below as it is likely to be encrypted and unreadable. And may have been written by a future software version with unknown formatting rules.

An application like meshms might ask the local store to preserve some specific bundles that this application can decrypt and understand.
But we must assume that most of the content in the rhizome store that we need to rank will be addressed to other users and unreadable.

 

In that case, Rhizome can only prioritise by meta-data:

most meta data is created by Rhizome to identify and prioritise the payload, eg, id, filesize, filehash, version, etc.

But do you think these meta-data are interesting enough for prioritising?

Also, you wrote:

Rhizome does not record the originating or transited nodes of any payload, so nodes cannot rank (prioritise) payloads based on point of origin, only on available meta data

I don't understand: what is manifests.sender in Rhizome database?
(but I agree, rank must not depend on originating nodes)

That's currently populated for meshms service only. The encryption scheme we are supporting for meshms or other directed services needs to know one public key and one private key from the same pair.

The recipient could not decrypt the content if the sender was not present.

 

Thank you for your answers.
®om

--

[Andrew Bettison]

Hi �om,

I'm glad you're asking these questions.� It's about time we started writing down some of our requirements and design decisions.

On 04/04/13 00:26, �om wrote:

About services and current implementation
I said:

Rhizome should be service-agnostic.

We seem to agree on that point:

Rhizome software does not encapsulate any application-specific logic

However, the current implementation does (ex1, ex2).
Therefore, if someone wants to create a new service, they cannot without modifying Rhizome itself ("Unsupported service").

The requirement of application agnosticism was only very recently articulated and discussed, and written into the Wiki.� (The Rhizome design and requirements are still very much under development, but heading towards stability.)� As you rightly point out, the manifest service field is a blatant violation of this requirement, and the name field is another.�� There may be others, but I hope not.� We have talked about how to deal with these.

Consensus was to eventually eliminate the service and name fields, and replace them with a MIME Content-Type manifest field, and another field similar to the MIME Content-Disposition header (to carry meta-data such as filename).� The need for a Content-Type field has been known and discussed for some time, but this discussion seems to have cemented its eventual role and importance.� Content generated by the Serval software itself would have a major MIME type of x-servalproject and a minor MIME type similar to the current service field.� Serval would interpret its own minor types when injecting or extracting bundles, ignore them when transferring or receiving bundles, and possibly interpret them when ranking bundles (see below).� For example, the Serval Mesh Rhizome explorer activity ("Find" button) would only display bundles with a MIME Content-Type of x-servalproject/file (unless a "show hidden" option were set) and the MeshMS logic would only accept and create bundles with a MIME Content-Type of x-servalproject/meshms-1.

The allowed minor file types for the x-servalproject major type would be managed by the Serval Project.� We would allocate types for our Serval Maps app, our sensor logging app, and of course for software upgrades.� We might also have to implement a non-x-servalproject MIME type registry as part of the Serval Mesh application API, to allow third-party apps to dynamically register their own MIME types.� This would then allow Serval Mesh to route notifications of arrivals to those apps (not such an issue on Android, which has its own Intent notification broadcast system), and to exclude those types from the Serval Mesh Rhizome file explorer, or at least group or display them better.

We also discussed dividing the manifest into two grades of meta-data: that which is interpreted by Rhizome when ranking and transmitting, and that which is not.� The MIME Content-Type field would be in the former (eg, to allow x-servalproject/software-upgrade to be prioritised over other types) and the MIME Content-Disposition field would be in the latter (eg, the name of a file or the internal format of the payload is of no interest to Rhizome).� We realised it would be useful to be able to carry other kinds of non-Rhizome meta data in the manifest, and even encrypt all such "application" meta-data if the payload is encrypted.

All of this is design that has not been implemented, nor even written down until now.

About layer separation

I wrote:

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.

�

I think this is very important. But I added:

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

I was wrong. I forgot one import point: Rhizome is not only a transfer protocol, it manages storage too. So a user must (at least) be able to extract bundles from some criteria (service, sender, recipient, �). Therefore, Rhizome must be able to identify some of these meta-data. The good news is that it does not prevent the service-agnosticism ;-)

The sender and recipient fields are potentially of use to applications besides MeshMS.� Any end-to-end protocol, such as voice mail, file transfer, email, etc, will need to use them.� We will formalise and standardise the way these fields are used by Rhizome, hopefully in the most useful and general manner, then applications can make use of their semantics as they wish.

The manifest signature is Rhizome's mechanism for guaranteeing the integrity of every bundle, and is, as you observe, application agnostic.

About manifests table in database

Why do you store some fields both as manifests table columns and as key=value in manifests.manifest value?

In a general sense, this is pure optimisation.� It would be possible to only store the manifest ID and BLOB in the table and perform all searches by selecting all rows, extracting the BLOB of each row, parsing it as a manifest, then performing the search predicate expression on the results.� But this is hideously inefficient and wasteful of CPU and memory, hence certain manifest fields of interest are duplicated as table columns to allow us to use the WHERE clause of SELECT statements.

Eventually, we will not store the manifest as a BLOB in the database.� The canonical representation of a manifest will become an extensible, compact binary format, which will only be used in-memory and on-the-wire.� The current text format will only be used in the application API, and will be converted to binary format for use within Serval DNA.� Rhizome should only use the BLOB to store the un-interpreted "application" meta-data (possibly encrypted) and any other manifest fields unrecognised by the software.� This might get done when we get around to rewriting the manifest handling code in Serval DNA.

About ranking

I wrote:

the idea is to add a score field in Rhizome bundles [�] which will be set only by the upper services.

When I wrote that, I had in mind the ability to forget/delete old/irrelevant messages from a chatroom or a �-blogging service. It can have some drawbacks (e.g. someone can force priority max for all its bundles).

You say exactly the opposite:

Rhizome does not rank (prioritise) based on the content of payloads

Could you explain your reasons, please?

This is both a pragmatic and idealistic objective.

Pragmatically, Rhizome should not be expected to know how to interpret any payload it encounters.� For starters, some payloads are encrypted, and secondly, we do not want to start building special-purpose application code into the Serval software, or depend on having any given application installed on all intermediate nodes between two end points.� That would be a maintenance nightmare would make it impossible to achieve any kind of forward- or backward-compatibility with respect to ranking or prioritisation, and would discriminate against applications not yet written or not yet built into or known by Serval.

Ideologically, Rhizome aims to uphold the principles of net neutrality, and eschews any kind of content inspection akin to deep packet inspection which forms the basis of the next wave of non-neutral Internet infrastructure, particularly of the mobile Internet.

In practice, Rhizome would succumb to the Tragedy of the Commons, just as USENET newsgroups did, if it were unable to rank and prioritise based on content.� For that reason, Rhizome supports a limited set of meta-data which it interprets according to a clearly defined set of semantics, while making no guarantees about prioritisation or ranking, since we cannot afford to close off possible future avenues of development.� The challenge for us as designers is to settle on a meta-data model which is rich enough to allow Rhizome to be a useful data transport for all kinds of applications, yet simple enough to make it attractive for application developers.� Another way of framing this challenge is the question, "What is the minimum that Rhizome needs to know about each bundle in order to give the best chance of getting it to where it is wanted?"

In all our discussions to date, we have identified the following meta-data as pertinent to a large Rhizome network:
- payload size, to allow smaller bundles to take priority
- bundle creation time, to allow older bundles to be expired
- (maybe) bundle life time - not yet implemented - to allow different time scales for expiring bundles
- service (to be replaced by MIME Content-Type), to allow prioritisation of software upgrade bundles
- geographic bounding circle (centre coordinates and radius) - not yet implemented - to prevent a bundle from displacing other content outside its geographic area of relevance
- sender and recipient, to allow end-to-end bundles to travel further than "broadcast" bundles so they have a better chance of getting to their destination

Also, you wrote:

Rhizome does not record the originating or transited nodes of any payload, so nodes cannot rank (prioritise) payloads based on point of origin, only on available meta data

I don't understand: what is manifests.sender in Rhizome database?

The manifest sender and recipient fields are supplied by the application itself.� If an application does not put them into the manifest, Rhizome will not put them there itself.

Officially, the Rhizome store (database) should not record where a bundle was first injected into Rhizome.� This requirement is vital in order to preserve plausible deniability -- if my phone is seized by a hostile party, they should not be able to tell which bundles originated on my phone (eg, photos that I took and shared).� In practice, this requirement is currently violated by the "author" column, which is necessary to divide bundles between the "Find" (aka Inbox) and "Sent" screens.� Once we implement multiple identity management in the Serval Mesh app, then identities that are marked as "secret" will never be recorded in the "author" column.� This will have the effect that any files I share using a secret identity will not show up in my "Sent" screen, but on the "Find" screen.� This is a small inconvenience to pay for ensuring my safety from self-incrimination.

Rhizome does not propagate the "author" column to neighbouring nodes.� So when a node receives a bundle, it cannot tell if it originated from an immediate neighbour or has already travelled through a hundred nodes.

[Jeremy Lakeman]

Mime types tell the receiver how to interpret the data, and are used to pick applications that can understand it. They shouldn't be used to identify the source application or author.

Sure meshms is a new content type that serval has defined and deserves its own x-serval or x-org.servalproject mime type. But text/plain, text/html, image/jpeg etc are already well known types and we should be able to carry them as is. And I believe there are some well known mime types for "unknown binary data". Android has a well defined mime type for apk files.

For those reasons I don't think mime type is particularly useful to include in prioritisation meta data. But we may still need a more general quality of service indicator.

If we want to prove authorship, and have some authors given a priority boost, we will need to prove the author cryptographically. We don't want other people producing trusted "serval software update" bundles.

[®om]

Thank you for answering so quickly!

About manifests table in database

Your answers are very clear. Thank you. I have nothing to add.


About the "service" field

As you rightly point out, the manifest service field is a blatant violation of this requirement

To be more precise, there are 2 layers to consider: the rhizome layer and the application layer.

I think "service" has its place in the rhizome layer: it gives information about where to deliver the payload, exactly like the UDP port does, so the payload is directed to any socket bound to that port. "service" can be seen as a "String port". So I don't think it breaks the application agnosticism principle.

Instead, I think the violation comes from the manifest that covers both layers.


About the manifest

We also discussed dividing the manifest into two grades of meta-data: that which is interpreted by Rhizome when ranking and transmitting, and that which is not.

That's great, it would disambiguate the role of the manifest file.

But, in that case, manifest M would become (M1, M2): M1 for the rhizome part, M2 for the application part.

As the application part (including M2) can be encrypted, M2 cannot be used by Rhizome at all (for selecting bundles or whatever). Therefore, only M1 is needed, information contained in M2 should be managed by the application layer (I consider lakeman's manifest layers 1 to 3, as well as the items from your list of meta-data you have identified, to be in M1, the rhizome layer fields).

Thus, if Rhizome manages only M1 (not any application-specific or unknown field), these fields can be defined once and for all, like IP or TCP fields are. For example:

• service         # think "port"
• sender
• recipient
• creation_date   # timestamp
  
• …
• payload_length  # the length of the (encrypted) payload
• payload         # encrypted or not
• signature       # of all the field values above

Therefore there would be no interest to store them as key/value pairs, we could store them directly (String, byte[], byte[]…), and there would be no "manifest" anymore (the manifest is the fields). Of course, the signature of the bundle must include the payload AND the rhizome fields (while encryption is performed only on the payload), so a node cannot change the recipient for example.

Note that the fields can still be implemented as key/value pairs or protocol buffer if you have any reason to reject straightforward binary…

In the "file" application layer (i.e. the rhizome payload), there could be:

• mimetype        # e.g. "image/jpg"
• data_length
• data

In the "meshms" application layer:

• author_name
• author_did
• message_length
• message         # can be a multipart message

In the "software_upgrate" application layer:

• version
• … ?             # other relevant fields for software updates
  
• data_length
• data

The implementation of these fields is up to application layers. For example, one can decide to implement them using a protocol buffer to be able to add fields in a future version keeping backward compatibility, another can use straightforward binary format…

Handlers could be registered (bound) for a particular service (think of a socket listening on a port): a MeshMS handler would listen to "meshms" service (port) for receiving meshms bundles, a file-sharing system would listen to "file" service… Anyone could create, send and receive (listen) packets/bundles for a new service. Services implemented in Batphone do not have any privilege over external/unknown ones. Either several handlers could "listen" the same service, either only one (to be discussed).


About using a MIME-type

As I said, I think the "service" field has its place in Rhizome layer.

In my opinion, replacing it with a mime-type would be an error:
 - either you will only use "x-servalproject/*", which is strictly equivalent to the service field (using "x-servalproject/meshms-1" instead of "meshms-1" does not change anything);
 - either you will also use any other mime-types ("image/jpg", "text/html"…), and in that case you are just trying to implement the "file" service directly into the Rhizome layer instead of over it.

I think "mimetype" should be in the "file" application layer (like in my example above).


About ranking

Your comments about ranking are very interesting.

Maybe we could "merge" the two approches: the local rank could be a mix (sum?) between a meta-data rank (computed from rhizome-level, from signed/unmodifiable values) and an application rank (set by the local application, not sent to other peers, for prioritizing messages from a µ-blogging service that are more relevant to the user for example).


About "sender" field and encryption

The recipient could not decrypt the content if the sender was not present.

I guess you mean "could not check the signature"? A receiver should only need its own private key to decrypt, no? (and the sender public key for checking the signature)

The encryption scheme we are supporting for meshms or other directed services needs to know one public key and one private key from the same pair

You need to know the private key of the sender???


About performance issues

If I want to retrieve the data contained in several bundles (imagine each bundle contains a µ-blog message), I have to:

• execute "servald rhizome list …" (ServalD.rhizomeList(…))
• get the bundle ids (parsing the result / using the Cursor)
• for each bundle id:
•   execute "servald rhizome extract …" (ServalD.rhizomeExtractFile(…))
•   parse the created file

Thus, If there are n bundles, I have n+1 commands to execute. Each command will result in process creation and sqlite open/close. This is very inefficient (with only 2 bundles, it takes 800ms).

Some ideas for later improvements (to be discussed):

• direct file storage instead of sqlite (open/close and writing is not so "lightweight"), which would avoid concurrency access issues too;
• servald commandline could write binary results directly to stdin (instead of writing to a file), with several results at once (bid1 | payload1_length | payload1 | bid2 | payload2_length | payload2 | …).
• any other?
  

Thank you for your time, ideas and discussions ;-)
®om

[®om]

servald commandline could write binary results directly to stdin

s/stdin/stdout/

[Jeremy Lakeman]

On Tue, Apr 9, 2013 at 1:27 AM, ®om <romain...@gmail.com> wrote

The encryption scheme we are supporting for meshms or other directed services needs to know one public key and one private key from the same pair

You need to know the private key of the sender???

We're using a symmetric cipher based on a shared key that is computed from one private key and one public key from the same pair. Both public keys must be known, but knowledge of either private key can be used to decrypt the contents.
 

About performance issues

If I want to retrieve the data contained in several bundles (imagine each bundle contains a µ-blog message), I have to:

• execute "servald rhizome list …" (ServalD.rhizomeList(…))

Or listen for new incoming "BUNDLE" messages on a monitor socket

• get the bundle ids (parsing the result / using the Cursor)
• for each bundle id:
•   execute "servald rhizome extract …" (ServalD.rhizomeExtractFile(…))
•   parse the created file

Thus, If there are n bundles, I have n+1 commands to execute. Each command will result in process creation and sqlite open/close. This is very inefficient (with only 2 bundles, it takes 800ms).

Some ideas for later improvements (to be discussed):

• direct file storage instead of sqlite (open/close and writing is not so "lightweight"), which would avoid concurrency access issues too;
• servald commandline could write binary results directly to stdin (instead of writing to a file), with several results at once (bid1 | payload1_length | payload1 | bid2 | payload2_length | payload2 | …).
• any other?
  

Similar to the development of git, we're building the "plumbing" in servald. The command line interface is not really intended for users.
The android JNI layer avoids paying some of those startup & teardown costs by using a single process.

Removing sqlite and replacing it with some kind of compressed object store would be an improvement. It should reduce code & binary size, reduce compile time and should be more efficient at runtime.
We've also talked about splitting rhizome storage operations into a separate process so that file IO can't impact other daemon operations like packet routing.

 

Thank you for your time, ideas and discussions ;-)

®om

--