This was probably my most embarrassing oversight. Your first point is the way it's working. I'm trying to figure out if there's a way to make that work without segmenting the map into fixed cells... any thoughts?
I personally don't see how you could completely avoid this without some kind of fixed regions, unless you required people to do some kind of an "@user Hey..." for every message so that you would know if you share the same sphere with the destination user. This makes it more tedious and less fun, though, plus it takes away the whole idea of multicasting.
Another nice aspect of keeping it strictly distance-based is that it makes it simpler to scale - all persons within a geographic region are able to see only other people within that region, so within limits you can run separate backend instances as required.
And of course there are all sorts of potential growth directions by allowing communities (e.g. "Students at XYZU and people within 1 mile" or "Students at XYZU who are within 1 mile").
You might try a clustering algorithms like k-means. Or perhaps there is a graph theory way to approach it.
But I suspect every solution you come up with will involve some trade offs, so there is something to be said for the simple solution you implemented.
To detect replies, one option is to do a statistical analysis of the typical time between two messages on the network. Anyone who replies in the upper 70% percentile is "replying"
You could make the effect fuzzy and have a back and forth conversation (which would probably be obvious in the data) have a stronger effect and could use that for training your algorithm.
Maybe, something similar to hearing, a person who is closer is louder while the one far is faint.... So nearby people have a stronger font while the one who is far has a lighter font ? Note - I've not used this app, so don't know how it is working ...