
Updating Torrents via DHT Mutable Items - sktrdie
http://www.bittorrent.org/beps/bep_0046.html
======
niftich
This is an intriguing addition to Bittorrent; this kind of feature exists in
IPFS [1], but of course Bittorrent has a much, much larger install base, so
this progressive enhancement could bring similar or near-equivalent features
to a wider audience.

This implementation relies on BEP 44 (Storing arbitrary data in the DHT) [2],
which, together with the design of the DHT, does have some security
implications [3].

[1] [https://ipfs.io/](https://ipfs.io/)

[2]
[http://www.bittorrent.org/beps/bep_0044.html](http://www.bittorrent.org/beps/bep_0044.html)

[3]
[https://gist.github.com/substack/eadd13302d785dc13aac#file-r...](https://gist.github.com/substack/eadd13302d785dc13aac#file-
results-markdown)

~~~
Mizza
IPFS still doesn't have a content discovery mechanism, which I found very
disappointing. It's not a killer app without that.

~~~
niftich
Well, to be fair, neither does HTTP, short of either name-services (DNS), or
crawling-and-indexing.

IFPS has IPNS [1], the name services (the feature most-directly relevant to
the Bittorrent enhancement in question).

To date, I'm unaware of an IFPS crawler-and-indexer search engine.

[1]
[https://github.com/ipfs/faq/issues/16](https://github.com/ipfs/faq/issues/16)

~~~
Mizza
Why is that fair? They're designed for different purposes. IPFS falls far
short of being useful in a transformative way because it lacks this important
feature. Otherwise, it'll be a kind of gimmicky alternative to HTTP, "auto-
archiving HTTP", that never got used for anything real.

~~~
nine_k
Did you ever use the web in 1995?

Content discovery is neither a part of HTTP nor the architecture of the web.
It's a feature if it's current landscape, built on top of existing non-ideal
ALI and brute force (scanning).

Good web search (represented by Google) appeared around 1998, years after the
general availability of the web, when the corpus of web pages was already
large. Up to this moment, search is powered by ad revenue.

I don't see how IPFS is significantly different in this regard.

~~~
Mizza
It isn't 1995, this is exactly my point. If we're trying to design new
systems, we shouldn't design them with the exact same problems. What's the
point of "decentralizing" if it just means another Google?

~~~
nine_k
The approach of yacy.net may be partly applicable to IPFS.

Donating resources to a "traditional" scanning search engine is also probably
doable. But unlike Web, IPFS lacks intense linking and thus "citation ranking"
(PageRank-like). Measuring relevance is harder.

------
Mizza
This is an okay idea, but it doesn't really solve the big problem facing BT
right now: content discovery.

Mutable Items are good for updating content, but that doesn't matter if nobody
can find it.

There needs to be a BEP for a way to host, serve and search metadata about
torrents, not just their info-hashes. This should be priority #1 for BT devs.
Fortunately, there is at least some related thinking in this direction:
[http://www.bittorrent.org/beps/bep_0044.html](http://www.bittorrent.org/beps/bep_0044.html)
although I don't think that it really goes far enough, as there is no
standardization around how the data for searching will be structured, etc.

~~~
sktrdie
Torrent sites could publish their database dumps via this extension, and
consumers would automatically download their updated index. A torrent can be
anything; it can also be a list of other torrents ;) So it does help with
content discovery.

~~~
cocotino
An index? That could be huge. I think it's senseless.

So many p2p protocols have support for p2p search (to my mind comes Kademlia),
why can't BitTorrent have p2p search?

~~~
swolchok
Vuze (formerly known as Azureus) has (or at least had a prototype of) p2p
search.

I wrote a paper on building a torrent search index quickly using the DHT
records that this feature emitted at the time.
[http://static.usenix.org/events/woot10/tech/full_papers/Wolc...](http://static.usenix.org/events/woot10/tech/full_papers/Wolchok.pdf)

~~~
sktrdie
Great work with this. Are you still in academia doing research?

------
eximius
Wow, the first thing I think of is that this could be a fantastic vector for
malware. Anyone who implements this should make it very clear the underlying
data can change.

~~~
DarkLinkXXXX
To be fair, torrents were always a fantastic vector for malware.

~~~
pessimizer
To be fair, the internet has always been a fantastic vector for malware.

~~~
jokoon
To be fair, human cells has always been a fantastic vector for infection.

------
beefield
So, what is stopping this to be the ultimate distributed social media
platform?

I mean, I should be able to publish a relatively simple sqlite database that
contains:

\- my public posts

\- my public encryption key

\- list of my friends

\- my private posts encrypted with the friends' public keys

Then I should seed at least my and my friends databases, so even if some of my
friend is offline, his/hers database is still available.

~~~
niftich
Network effects and lack of off-the-shelf implementations.

~~~
beefield
Network effects are clearly a major issue, but wrapping the concept to a
webpage and/or mobile app should not be a major hurdle. If I have not missed
something.

If I only had some more time on my hands...

~~~
niftich
Although the subject matter is different, GitTorrent [1] actually uses
techniques you propose, by using BEP 44 to store Git revisions in the
Bittorrent Mainline DHT, and Bitcoin to store cryptographically-signed
usernames in the Bitcoin Blockchain.

You can look at how that implementation was done and what issues they
encountered to see what it would take to implement a distributed [something],
where that [something] in your case is a social network.

[1] [https://github.com/cjb/GitTorrent](https://github.com/cjb/GitTorrent)

