Resolving peers

Lookup paths

The resolver tries these in order:

1. If the input already implements InputPeer, return it.
2. If a cached peer for the input exists and is not min, return it.
3. If the input is a numeric id, look it up in the local user/chat cache.
4. If the input is a username, run contacts.resolveUsername.
5. If it is a t.me link, parse out the username or invite hash and recurse.
6. If it is an E.164 phone, look in contacts; fall back to contacts.resolvePhone.

Whichever path returns first is cached so subsequent calls are local-only.

By username

peer, err := client.ResolvePeer("@durov")
// or without the @
peer, err := client.ResolvePeer("durov")

peer, err := client.ResolvePeer("@durov")
// or without the @
peer, err := client.ResolvePeer("durov")

Both forms work. The @ is decorative; the server never sees it. Usernames are case-insensitive on lookup but the canonical form (whatever the user set in their settings) is what comes back.

By id

peer, err := client.ResolvePeer(int64(-1001234567890))

peer, err := client.ResolvePeer(int64(-1001234567890))

For channels and supergroups, pass either the -100-prefixed form or the bare positive id; the resolver figures out which. For users and basic groups, pass the literal signed id you got from an update.

By link

peer, err := client.ResolvePeer("https://t.me/joinchat/AAAA...")
peer, err  := client.ResolvePeer("https://t.me/durov")
peer, err  := client.ResolvePeer("t.me/+12345")

peer, err := client.ResolvePeer("https://t.me/joinchat/AAAA...")
peer, err  := client.ResolvePeer("https://t.me/durov")
peer, err  := client.ResolvePeer("t.me/+12345")

Public links (t.me/username) resolve to the channel/user; invite links (t.me/joinchat/... or t.me/+...) resolve to the chat the invite points to, but only if you are a member or about to become one. If you are not a member, CheckChatInvite + ImportChatInvite are the next two methods to call.

By phone

peer, err := client.ResolvePeer("+15551234567")

peer, err := client.ResolvePeer("+15551234567")

Only user accounts. The number must be in E.164 form and the user must either be in your contacts or have made themselves discoverable by phone in their privacy settings.

Cache behaviour

The default cache lives in memory. It records both the id-to-access-hash mapping and the username-to-id mapping. Entries are added on every successful resolve, every received update that contains a non-min peer object, and every time the library learns about participants of a chat.

Restart the process and the cache is empty — resolves go to the network again. For long-lived bots that talk to many peers, persist the cache (see Custom peer storage) so cold starts do not pile up FLOOD_WAITs on the resolve methods.