dht client

a tracker dht client must implement the core bit torrent protocol and several extensions in order to participate in the network. the dht client must also serve a 9p filesystem that conforms to the tracker spec.

http://www.bittorrent.org/beps/bep_0003.html http://bittorrent.org/beps/bep_0032.html http://bittorrent.org/beps/bep_0035.html http://bittorrent.org/beps/bep_0042.html http://bittorrent.org/beps/bep_0052.html http://bittorrent.org/beps/bep_0049.html http://bittorrent.org/beps/bep_0046.html http://bittorrent.org/beps/bep_0030.html

using mainline DHT to store/fetch activities and content is a really compelling alternative to WebAP. however, we end up needing to solve certain problems a bit differently. specifically, resolving names and providing acceptable deniability for published content.

blind key rotation as implemented in litepub depends on the instance to act as an authoritative resource for the user’s feed. this works well in a server-oriented architecture, but having an authoritative key in a mesh architecture defeats the purpose of rotating the keys in the first place.

this is problematic from a privacy perspective and a particular weak spot for

p2p protocols in general. perhaps we need a fully anonymous DHT or a clever

signature scheme that can obscure ownership of sensitive information.

does there need to be an assertion of ownership for that sensitive content? Generate one time key to post?

this is where it gets tricky. you do need an authoritative key to publish from in order for subscriptions to work. if you just publish at a random key, nobody will be able to find it unless you tell them about it. to make things more difficult, everything also has to be static so other clients can cache your feed so it can be available when you are offline.

basically, we need to obscure the feed while retaining the ability to have a global public id that can be used to find it. one way would be to encrypt everything, but that gets expensive if you have many followers. a good compromise might be to encrypt a message that lives at a public mutable DHT key. this message would point at the current authoritative feed for the account.

however, for this to work you need to do a handshake and key exchange with all of your followers. in fact, this may end up being more private than WebAP because you gain the ability to decide who can follow you. for intentionally public feeds, the client can be configured to handshake with all followers automatically.


results matching ""

    No results matching ""