[Standards] IM Message Routing 2: Device Identity
georg at op-co.de
Wed Oct 11 17:14:31 UTC 2017
Hello, this is part 2 of the thread about how broken XMPP is
Today I'd like to talk about device identity (in the sense that a server
knows when a certain client application instance reconnects).
Having such a universal client ID would be awesome for:
- client re-synchronization
- session initiation / resumption
- per device passwords
- OMEMO device key management
- awesome future use cases
What we have instead:
1. Resource identifiers in the JID
Those are unique, so a server must either kill the old session or refuse
the new session on conflict. IMO clients that create a randomized
resource string on account setup, or keep the one initially assigned by
the server, plus servers that kill the old session on a resource
conflict provide a very sane and reasonable setup that works today.
Pro: a client comes back with the same "public" identifier.
Contra: not cloud-scale, because it requires a global lock when a client
reconnects. However, a global lookup table is needed anyway to enumerate
all resource of a client for presence / bare-JID routing.
Contra: some people consider private resource strings a security
2. XEP-0198 resume id
Again, unique, used to restore a "zombified" session, typically when TCP
has failed. Typically only short-lived, kept around for multiple minutes
after a client vanishes, and then removed.
Pro: server-generated, opaque to the client.
Contra: short-lived, not suitable for long term
3. Double-Resourcepart proposed in the context of Bind 2
Something like `<client-unique-id>/<server-generated-id>` as a
resourcepart, where a stable client ID is combined with some
cluster-node identifier from the server
Contra: visible to people who are subscribed to you.
Contra: client identifier changes when reconnecting to a different
It might be useful to have a hidden or visible persistent client
identity stored on the server and associated when authenticating /
binding. Maybe even one the user can see and remove from the server's
web interface ;)
|| http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++
|| gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ ||
|| Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? ||
++ IRCnet OFTC OPN ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the Standards