Hello, this is part 2 of the thread about how broken XMPP is <https://mail.jabber.org/pipermail/standards/2017-October/033499.html>.
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 measure. 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 <https://mail.jabber.org/pipermail/standards/2017-February/032089.html> Pro: cloud-scale. Contra: visible to people who are subscribed to you. Contra: client identifier changes when reconnecting to a different cluster node. 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 ;) Georg -- || 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 ||_________________________________________________||
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
