For your weekend reading: proposal on adding geolocation to the protocol. If implemented, will enable location-based clients, improved feed targeting, and better analytics

For your weekend reading: proposal on adding geolocation to the protocol. If implemented, will enable location-based clients, improved feed targeting, and better analytics
https://github.com/farcasterxyz/protocol/discussions/165

great idea. probably would just go with #2 for now, but carries a reliance on google.

we need more FIPs — and this is a great one!

Option #2 seems best way to go. Keep it simple and flexible. I think this is something client will control and can utilize in various ways. Some might not want to locations that are bound to countries/cities/etc. Protocol should not be too specific on this.

I need this right now as I started hacking it on the client end myself.

why not both? add "custom" as a geolocation type and then add `string custom` as a oneof.

i prefer the structured but extensible approach introduced in #1.

i would also highly consider h3 as a location type with it's flexible resolutions. it has served the helium ecosystem very well.

why not both? add "custom" as a geolocation type and then add `string custom` as a oneof.

i prefer the structured but extensible approach introduced in #1.

i would also highly consider h3 as a location type with it's flexible resolutions. it has served the helium ecosystem very well.

https://h3geo.org/