Some thoughts on how to announce one's presence.

A while back I wrote an article about web applications that can live wherever you can store a file and not necessarily on a web server out of your control. I probably should have posted a link to Google Group dedicated to unhosted applications, but that's neither here nor there. To recap briefly, what I discussed in the previous article are called unhosted communications applications, like social networking or instant messaging software. This begs a crucial question: Assuming that you're running an unhosted application in your web browser, how do you tell other people how to connect to you with their own copies? If an application is running on a server someplace then everybody who visits that server can potentially communicate through it with everyone else connected to it. This is how garden variety web applications operate. But what if running a server won't work for your use cases? I talk a lot about decentralized applications because they're harder to shut down. Central points of failure are too easy to find and take out but peer to peer services are harder to contain by their very nature. (Disclaimer: I hope I got this bit right. If I didn't, expect future edits.) Let's take everyone's favorite example, BitTorrent. Applications like BitTorrent have two modes of operation: They can connect to one or more centrally located servers called trackers to download .torrent files and advertise their participation in one or more torrents so that other clients partaking of the same torrents can contact them. The other mode of operation involves so-called trackerless torrents, where a distributed hash table takes the place of a tracker. In the BitTorrent DHT every node pseudorandomly picks a hash to identify itself. That hash is computed from addressing information, and by searching the contents of the table it can find other nodes on the public Net which are either running the same torrent or possess addressing information of nodes that are. Nodes which are aware of one another can also ask one another for addressing information which is then locally cached and possibly replicated to other nodes later. Then there are application protocols which try to be helpful by embedding the IP address of the machine in packets where NAT can't do anything about it because it operates at a lower OSI layer. Other clients tend to throw errors because they think they can't reach you. BitTorrent clients and some instant messaging applications are notorious for these kinds of problems which is why many have a configuration option for entering your public IP address. There is also a protocol called uPNP, which among other things can ask your local firewall to temporarily punch holes through itself so network applications can operate normally. Unfortunately, sometimes the implementation you've got works, and sometimes it doesn't. Smarter applications have ways of detecting the routable IP address they're behind and can configure themselves appropriately. Tor does this, for example. I think these examples illustrate the point that no matter how you cut it unhosted applications need ways to find to one another when they don't have any pre-existing knowledge of where to start looking. They also need ways to find one another when IP addresses periodically change (thus invalidating local caches) or cannot be reached directly for whatever reason. The solution employed by Torchat relies upon Tor hidden services so clients can locate one another. Every Torchat user is identified with a .onion address which users can then add human readable aliases to (thus squaring Zooko's Triangle). The .onion hostnames of Tor hidden services are public keys, so by communicating exclusively over the Tor network it becomes possible for applications to find one another and dodge firewall problems as well as confirming the identity of the client on the other side (because the hidden service has to have the matching private key for the connection to complete). However, not everybody wants to (or can) install the Tor Browser Bundle. The BitTorrent tracker model could be used by unhosted apps to find one another - a bunch of services could be set up across the Net that our hypothetical unhosted communication apps use to find one anothe