Wow, this is quite a throwback, because that's almost the exact same way of triangulating a location that me and a few of my classmates discovered in regards to Tinder around 6-7 years ago (which got patched up shortly after). Just a note, it was done purely out of academic interest and was not ever used in any capacity other than just finding out that it was possible.
Basically, Tinder used to give you only the distance to a user in the UI, but the exact coordinate location of the user in their API responses. They patched it up and made it so that it only returns the distance in the API as well. And that's when it became really similar to the current Telegram situation. This was before we got our hands on this. However, reading older articles and blog posts about those "times before us" was what gave us the idea. Mostly because it seemed like their fix was not sufficient enough to prevent anyone (assuming they know basic trigonometry) from pinpointing the location just as easily, but with a few extra steps added.
Knowing the distance between you and another user, you could quickly spoof your GPS location to 3 different coordinates that would create 3 circles all intersecting in one small area. You could easily pick coordinates for those circle centers based on the change in distance to the user, so if you picked a bad coordinate for one of the circles, you can adjust and pick a better one based on the feedback you got. E.g., if the first circle center coordinate was 1 mile away, but the second one was 5 miles away, and the third one was even further away, you should probably try re-picking the 2nd and 3rd circle better, since the goal is to not move those far away, but to have them have a similar distance to the user location, just from different directions.
Shortly after, Tinder fixed it in a much smarter way. Instead of assigning each user to a precise location and reporting a distance to them in the API response, they would break up the map into a grid of roughly 1mile by 1mile squares (or maybe hexes or maybe slightly different size? I am very rusty on the actual details of their fix, but the principle is still the same), and then assign each user to one of those squares. So the API would instead give you the distance between the center of the square you are assigned to and the center of their square.
AFAIK, that last approach they used to solve the issue is still unbeaten, and it makes sense as to why, since it is logically pretty robust at its core (plus/minus minor optimizations and improvements, of course).
No idea about other apps, as it was all done purely for fun and for learning purposes, so we didn't really have any interest in potentially implementing the exact same thing but for different apps. Especially since there is no real fun or learning happening when the API just spits out the exact coordinates back at you. To clarify, this was already patched by the time we set our sights on it.
>another one that just sent out coordinates and left the distance finding to the client
That's exactly what Tinder used to do back then, they simply sent out the coordinates and left distance calculations to the client. Given that Tinder (being one of the most popular dating platforms that was also known to be one of the most "tech-forward" ones) did that, I have zero doubt that some other dating platforms could have been using similar methods for determining the distance between users around that time.
Basically, Tinder used to give you only the distance to a user in the UI, but the exact coordinate location of the user in their API responses. They patched it up and made it so that it only returns the distance in the API as well. And that's when it became really similar to the current Telegram situation. This was before we got our hands on this. However, reading older articles and blog posts about those "times before us" was what gave us the idea. Mostly because it seemed like their fix was not sufficient enough to prevent anyone (assuming they know basic trigonometry) from pinpointing the location just as easily, but with a few extra steps added.
Knowing the distance between you and another user, you could quickly spoof your GPS location to 3 different coordinates that would create 3 circles all intersecting in one small area. You could easily pick coordinates for those circle centers based on the change in distance to the user, so if you picked a bad coordinate for one of the circles, you can adjust and pick a better one based on the feedback you got. E.g., if the first circle center coordinate was 1 mile away, but the second one was 5 miles away, and the third one was even further away, you should probably try re-picking the 2nd and 3rd circle better, since the goal is to not move those far away, but to have them have a similar distance to the user location, just from different directions.
Shortly after, Tinder fixed it in a much smarter way. Instead of assigning each user to a precise location and reporting a distance to them in the API response, they would break up the map into a grid of roughly 1mile by 1mile squares (or maybe hexes or maybe slightly different size? I am very rusty on the actual details of their fix, but the principle is still the same), and then assign each user to one of those squares. So the API would instead give you the distance between the center of the square you are assigned to and the center of their square.
AFAIK, that last approach they used to solve the issue is still unbeaten, and it makes sense as to why, since it is logically pretty robust at its core (plus/minus minor optimizations and improvements, of course).