I was trying to solve a pretty simple problem: how to keep geo-notes organized and actually usable without building a multi-level UI. Instead of building another app, I started wondering if Telegram — with its search and message model — could handle more than it seems at first glance. At some point, I approached the problem from a very simple angle: What if a location could be treated as a tag? Not just a generic label, but something more concrete — essentially latitude and longitude encoded into a hashtag-like format. A representation that can always be turned back into actual coordinates. In practice, a caption might look something like this: `#geom3eaZ76OH4 ` where the links to something like `https://www.google.com/maps?q=11.453792,104.957634` So the tag acts as a compact, searchable identifier, while the link preserves the exact location in a human-friendly way. Once you have a consistent location tag, everything else falls into place quite naturally. Any Telegram-supported content — messages, media with captions, text — can be tied to that same tag. Since everything is already indexed, you automatically get a connected set of data around a place. In practice, this means a single location tag becomes a kind of anchor. You can describe a place, add notes, attach photos, or extend it over time — all linked through that one reference and fully searchable. At that point, you're not really building a separate storage system anymore. You're leaning on Telegram’s own indexing and letting it do most of the heavy lifting. If you take this idea a bit further, you can introduce an additional layer using another tag. For example, something like `#myTrip` to mark a group of geo-notes that belong together. If messages with location tags are also labeled with `#myTrip` (for example, within a topic or a dedicated thread with the same name), you can start linking different places into a route. In practice, this turns a set of individual location anchors into a connected sequence. You’re no longer just describing places — you’re organizing them into paths that can be revisited, searched, and shared. At that point, it starts to feel less like a collection of notes and more like a lightweight, flexible way to build and navigate routes directly inside Telegram. There was a trade-off, though. Since the system restructures messages to keep everything consistent and searchable, I lost the ability to edit them in a normal way. Instead of direct edits, messages are effectively rebuilt. To keep things simple and stay within Telegram’s native interaction model, I introduced a minimal set of reply-based interactions. For example: * replying with `=new text` replaces the caption * replying with `=` clears it down to the service tags * replying with `+some text` appends a new line It’s not as convenient as standard editing, but it keeps everything consistent with the overall idea: no complex UI, just structured messages and lightweight interaction. In the end, this approach comes with some clear trade-offs — but also some practical advantages. On the plus side: * there’s no separate database to maintain — everything stays inside Telegram * no multi-level menus or complex UI flows * no AI layer in between — just direct interaction with structured messages At the same time, this simplicity has its limits. Since the system doesn’t store data outside of Telegram, it can’t help recover anything you delete. If a message is gone, it’s gone — there’s no secondary storage or history to fall back on. Another limitation is that the structure only really works inside Telegram. If you try to move it elsewhere, it loses most of its connections and interactivity, because everything relies on native message behavior and search. So it’s not a system that tries to control or preserve everything. It’s closer to a lightweight layer that helps organize what’s already there, while leaving the underlying behavior unchanged.