the rails app that is the icecondor server wont scale. it'll be another failwhale if more than some small number of people regularly use it. how can the android app provide resources at the same time that it consumes them? thats what bittorrent did - turned every leach into a provider. that means the client needs to report its location directly to other clients. every client has a piece of the picture. clients frequently go offline so there would be a lot of redundancy. i keep coming back to distributed hash tables. in the way that gnetulla works, someone new comes along and a search gets sent out to nodes, routing as it goes, looking for information on the new person.
how does one get the scent, or the digital fingerprint of someone to add to the list of people to track in icecondor? one way would be to support face to face meetings. through wifi and bonjour, or even better through bluetooth adhoc networking or possibly bluetooth mac sniffing, a list of people in the room would show up. click on a name to save that ID as someone to watch.
next client steps
the server needs to be able to send a response code that sets the update frequency in the client. that way the server can manage the clients like an air traffic control tower. it can look at its response times and add or remove time to the clients' pause between updates as needed.
the social side to the client will have to happen sooner or later. friend discovery through twitter or XFN. the first hard part is to make bootstrapping as easy as possible. the client needs a single starting URL that describes the user. this will normally be their OpenID URL. its a bit unweildly to type your URL into the little text box. the cell networks knows who owns the phone through its IMEI number. i wonder if that or (if a SIM is installed and the phone is registered on the network) the phone's telephone number is available to the app.