BearNotes

We purposefully left the first RESULT message fairly ambiguous, for two primary reasons.

(1) we did not think that parsing a newline character would be any more difficult than parsing any other path.

(2) since the protocol specifies that the first client that can fulfill a file request must handle that request, a client can create a first RESULT message with an arbitrary number of indices as the hop path, that would function to provide further anonymity for that client in the case that the message is intercepted (although this seems a bit excessive).

So, as a result, each client can make the hop path for the first RESULT message anything, since that client is the only client that needs to make sense of it.

However, to maintain compatibility with other clients, each client must be able to handle a simple newline character as a hop path, then proceed as the protocol specifies. (See the Peer ID subsection in the PROTOCOL DEFINITIONS AND ADDITIONAL INFORMATION section of the doc, or http://bearnotes.com/phpbb/viewtopic.php?t=955 for some examples)

Hope this helps,
Jason

Am I right in saying that when a message reaches the end of a hop path when downloading, the hop path will be empty?

Or that when a search result is returned, the first peer that deals with the search result will see an empty hop path?

If that is so, then that can make parsing a pain in the ass. It's easier if we can split the message by new line and get the right fields in the right array indexes, but that method won't work if we have an empty hop path.

So then, can we make it so the end of the hop path is marked by a special something or other. It could be a -1, or a ¥, or even a space, just so long as the hop path field isn't an empty string.