For example, I should be able to give unique URLs (for the same data) to different users and expire one but continue for the other,etc.
Edit: The keys are very short (64 bytes), so they can easily be copy/pasted, tweeted and what have you :)
You generate one key pair for one shared item. I'm talking about multiple key pairs for each shared item, so that I can give access to individual users for the same data and revoke them when necessary.
Fundamentally if you don't have that, then your case is trivially solved by a private bittorrrent tracker.
This is the fundamental difference between things like Quilt and bittorrrent.
http://www.libtorrent.org/dht_store.html
previous HN discussion - https://news.ycombinator.com/item?id=12257065
What you need to mimic dat is a more integrated way to tell other peers that the torrent changed and to check the new one... which is not there yet.
http://www.bittorrent.org/beps/bep_0046.html
>The intention is to allow publishers to serve content that might change over time in a more decentralized fashion. Consumers interested in the publisher's content only need to know their public key + optional salt. For instance, entities like Archive.org could publish their database dumps, and benefit from not having to maintain a central HTTP feed server to notify consumers about updates.
You are technically right that the torrent file is immutable, but basically this lets clients know that the torrent is updated using the DHT data. The outcome is the same.