<p>It is unlikely to be practical because it does not even try to be efficient (number of lookups) or reliable (failure rate multiplied by number of lookups). And that is for a single keyword, not boolean queries which would blow up the lookup complexity even further.</p>

<p>Not to mention that it doesn't even solve the hard problems of distributed searching such as avoiding spam and censoring.</p>

<p>Additional problems are that each node could only publish one torrent under a keyword and it would require multiple nodes to somehow coordinate what they publish under which keyword before they run into the collision problem.</p>

<p>Of course you might be able to make it work in a handful of instances, but that is is irrelevant because uses of p2p protocols should be designed in a way such that they still work in that case that <em>all nodes</em> nodes used that feature in a similar fashion. Clearly a (m * n * 10)-fold [m = torrents per keyword, n = number of search terms] blowup of network traffic is not acceptable.</p>

<p>If you are seriously interested in distributed keyword search I recommend that you hit google scholar and arxiv and look for existing research, it is a non-trivial topic.</p>

<p>For bittorrent specifically you should also look beyond BEP 5. BEP 44 provides arbitrary data storage, BEPs 46, 49 and 51 describe additional building blocks and abstractions. But I would consider none of them sufficient for a realtime distributed multi-keyword search as one would expect it from a local database or an indexing website.</p>
Using BitTorrent's DHT to perform real-time keyword searches
<p>I have an idea to implement a real-time keyword-based torrent search mechanism using the existing BitTorrent DHT, and I would like to know if it is feasible and realistic.</p>

<hr>

<p>We have a torrent, and we would like to be able to find it from a <code>keyword</code> using the DHT only.</p>

<ul>
<li><code>H</code> is a hash function with a 20 bytes output</li>
<li><code>infohash</code> is the info_hash of the torrent (20 bytes)</li>
<li><code>sub(hash, i)</code> returns 2 bytes of <code>hash</code> starting at byte <code>i</code> (for example, <code>sub(0x62616463666568676a696c6b6e6d706f72717473, 2) = 0x6463</code>)</li>
<li><code>announce_peer(hash, port)</code> publishes a fake peer associated with a fake info_hash <code>hash</code>. The IP of the fake peer is irrelevant and we use the <code>port</code> number to store data (2 bytes).</li>
<li><code>get_peers(hash)</code> retrieves fake peers associated with fake info_hash <code>hash</code>. Let's consider that this function returns a list of port number only.</li>
<li><code>a ++ b</code> means concatenate <code>a</code> and <code>b</code> (for example, <code>0x01 ++ 0x0203 = 0x010203</code>)</li>
</ul>

<h2>Publication</h2>

<pre><code>id &lt;- sub(infohash, 0)
announce_peer( H( 0x0000 ++ 0x00 ++ keyword ), id               )
announce_peer( H( id     ++ 0x01 ++ keyword ), sub(infohash, 2 ))
announce_peer( H( id     ++ 0x02 ++ keyword ), sub(infohash, 4 ))
announce_peer( H( id     ++ 0x03 ++ keyword ), sub(infohash, 6 ))
announce_peer( H( id     ++ 0x04 ++ keyword ), sub(infohash, 8 ))
announce_peer( H( id     ++ 0x05 ++ keyword ), sub(infohash, 10))
announce_peer( H( id     ++ 0x06 ++ keyword ), sub(infohash, 12))
announce_peer( H( id     ++ 0x07 ++ keyword ), sub(infohash, 14))
announce_peer( H( id     ++ 0x08 ++ keyword ), sub(infohash, 16))
announce_peer( H( id     ++ 0x09 ++ keyword ), sub(infohash, 18))
</code></pre>

<h2>Search</h2>

<pre><code>ids &lt;- get_peers(H( 0x0000 ++ 0x00 ++ keyword ))
foreach (id : ids)
{
    part1 &lt;- get_peers(H( id ++ 0x01 ++ keyword ))[0]
    part2 &lt;- get_peers(H( id ++ 0x02 ++ keyword ))[0]
    part3 &lt;- get_peers(H( id ++ 0x03 ++ keyword ))[0]
    part4 &lt;- get_peers(H( id ++ 0x04 ++ keyword ))[0]
    part5 &lt;- get_peers(H( id ++ 0x05 ++ keyword ))[0]
    part6 &lt;- get_peers(H( id ++ 0x06 ++ keyword ))[0]
    part7 &lt;- get_peers(H( id ++ 0x07 ++ keyword ))[0]
    part8 &lt;- get_peers(H( id ++ 0x08 ++ keyword ))[0]
    part9 &lt;- get_peers(H( id ++ 0x09 ++ keyword ))[0]

    result_infohash &lt;- id ++ part1 ++ part2 ++ ... ++ part9
    print("search result:" ++ result_infohash)
}
</code></pre>

<hr>

<p>I know there would be collisions with <code>id</code> (2 bytes only), but with relatively specific keywords it should work...</p>

<p>We could also build more specific keywords by concatenating several words in alphanumeric order. For example, if we have words <code>A</code>, <code>B</code> and <code>C</code> associated with a torrent, we could publish keywords <code>A</code>, <code>B</code>, <code>C</code>, <code>A ++ B</code>, <code>A ++ C</code>, <code>B ++ C</code> and <code>A ++ B ++ C</code>.</p>

<hr>

<p>So, is this awful hack feasible :D ? I know that <a href="http://retroshare.sourceforge.net/wiki/index.php/Frequently_Asked_Questions#How_does_RetroShare_know_my_friend.27s_IP_address_and_port.3F_Why_don.27t_I_need_a_static_IP_address.3F_What_is_DHT_for.3F" rel="nofollow noreferrer">Retroshare is using BitTorrent's DHT</a>.</p>