Summary: | XMPP Compliance Suite 2016 | ||
---|---|---|---|
Product: | Telepathy | Reporter: | diane |
Component: | gabble | Assignee: | Telepathy bugs list <telepathy-bugs> |
Status: | RESOLVED MOVED | QA Contact: | Telepathy bugs list <telepathy-bugs> |
Severity: | major | ||
Priority: | medium | CC: | daniel.scharon, nickbroon, sam, scott |
Version: | git master | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Bug Depends on: | 36804, 46700, 74990, 78093, 90838 | ||
Bug Blocks: |
Description
diane
2016-07-13 20:21:16 UTC
I add "depends on" for all of the IM advanced client bugs. The most important mobile XEP (0198) is in the IM advanced client recommendation anyway. Also I copied the wrong URL for it should be Bookmark Storage (XEP-0048) https://bugs.freedesktop.org/show_bug.cgi?id=74990 Thanks for summing it up. I'm raising the severity, as I think that modern XMPP compliance has a big impact on the userbase and we need more users to stay active and relevant Also for staying relevant we probably also want to work on having some kind of end-to-end encryption implemented. I know KTP has OTR support through a clever dbus proxy, it might be possible to get Empathy to take advantage of it. Though theres a social issue with the OTR proxy in that it's in ktp-common-internals so depends on Qt and thus some Glib / GNOME people might not want to install it. There's OpenPGP (XEP-0373, XEP-0374) and OMEMO (Conversations proposed XEP) which are more XMPP specific, but as encryption wasn't listed in the 2016 XMPP Compliance XEP, I didn't add them to this bug. Also I think ad-hoc commands and a jabber forms UI for things like ad-hoc commands and muc configuration would also be a nice thing to have. I'm sure XEP-0357 will also be very handy for mobile clients. It's also very simple to implement on client side (literally just add a call which triggers csi message - nothing more). All the job is done on the server side - suppress/discard/defer while inactive - and redeliver when state flips back. Delivery will then be driven by client's power-management cycle which would resemble server push mechanics. The rationale - to prevent TCP being dropped (timeout) or waking up the handheld unnecessarily. Dropped TCP may partially be mitigated by XEP-0198 and connection resumption - but that one is much harder to implement on both client and server side (need to preserve state and recover it for new connection). sorry, XEP-0352 (Client State Indication) of course -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-gabble/issues/288. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.