Peter Saint-Andre wrote: > The XSF held a productive developer conference in Brussels over the last > few days. I will write up the minutes tomorrow while flying back to the > States and post them as soon as possible.
Here's what I wrote on the plane... ****** XMPP DevCon #4 When: February 24-25, 2008Where: Brussels, BelgiumLogs: http://logs.jabber.org/[EMAIL PROTECTED]/2008-02-24.html http://logs.jabber.org/[EMAIL PROTECTED]/2008-02-25.htmlScribe: Peter Saint-Andre1.0 Deployment issues, with a focus spam and abuse 1.1 Issues - currently, most spam/abuse happens in Multi-User Chat rooms - JID mimicking common (e.g., add space) - service-wide nick reservation enables denial of service - rate limiting is necessary (handled now by room bots) - nick spam (really long roomnicks) - presence spam seen in the wild (frequent presence changes) - add best practices to XEP-0045- sending a large number of messages to a victim also seen - privacy lists can help (block all not in roster) - even then you can have subscription request spam - do we want centralized blacklists/whitelists (RBL)? - consensus is that RBL would introduce central failure point- better: ask peer server(s) that you trust - things will be worse once botnets gain control of legitimate JIDs - need to be clear on the architecture (client-server) - concentrate on the server side (more trusted, easier to update) - try to avoid netsplits and alternative federations (islands OK) - build a reputation system between servers? (not for end users) 1.2 Possible recommendations - need better monitoring of MUC rooms - Digg-like service for rating XMPP servers? - protocol for reporting abuse and escalating -> there is DoS potential here! - better traffic shaping / monitoring in server codebases - share contact information for operators - incremental trust of new servers that come onto the network - ask server "buddies" about other domains on the network - network status report a la BGP? 2.0 Mobile optimizations 2.1 What people have done or suggested - fast reconnection - pipelining of stream negotiation exchanges (Tony Finch) - don't retrieve roster (but this doesn't really help) - compression - BOSH (for mobile, is it better, the same, or worse than TCP?) - "session pause" feature - traffic filtering / profiles for mobile 2.2 Issues - bandwidth usage - latency of communication - power consumption ==> this is the major issue! - some operators block TCP - TCP timeouts are determined by service provider - need ability to pause or "quiet" a session - what do mobile users want? - presence-enabled contact list - typically a sub-list (not the complete roster) - do not receive presence from everyone - manage via privacy lists? - instant messaging - probably alerts and notifications (pubsub) - possibly Jingle calls (e.g., via wifi) - need way to negotiate how frequently device will wake up? - above all, maximize time in powersave mode! - for what reasons will the device be brought out of powersave? - IM from contact - phone call from contact - selected presence? (buddy pounce) - when brought out of powersave, send other queued stanzas - this is not battery-intensive because now you are awake - can this be done merely with privacy lists? - may need better handling of messages (e.g., Advanced Message Processing = XEP-0079) - define heuristics that say what to send when - TLS compression is good (DEFLATE) -- use it if at all possible - assume that TLS will succeed (it fails only if there is a misconfiguration) - stream feature for this? - buffer / queue stanzas while in pause or quiet mode 2.3 Recommendations / action items - outside expert says: we're on the right track (TCP better than UDP, DEFLATE is good, incremental approach, etc.) - document pipelining of XML sent during stream negotiation (per Tony Finch's email) - do we need an additional filtering protocol? - consensus: no - see how far we can get with privacy lists and best practices - define features for: - pausing a session (no interruptions) - quieting a session (selected interruptions OK) - do these belong in BOSH, in XEP-0198, privacy lists, or somewhere else? 3. XML synchronization / remote eventing 3.1 Motivations - whiteboarding - shared editing - collaborative data objects - more generally: DOM synchronization (for agents / wizards etc.) - even more general: perform operations on non-XML objects - question: is this in scope for XMPP?? 3.2 Issues - two modes (Fabio Forno) - session mode (e.g., whiteboarding) - sessionless (e.g., DOM events) - sharing events is easy - conflict resolution is hard 3.3 Conclusions Two models: 1. "event stream synchronization" -- it may be worthwhile to design a simple protocol extension for this 2. "object synchronization" -- this is hard and probably should be out of scope for the XSF 4.0 File transfer 4.1 Issues - the discussion continues -- why?? - currently no mandatory-to-implement (MTI) technology - result: poor interoperability - many different requirements, environments, and scenarios - no "one ring to bind them all" - need better fallback mechanisms - latency issues - do we really need to stream? - NAT traversal challenges - discussed pros and cons of multiple transport methods: - IBB - SOCK5 Bytestreams - "JabberDisk" -- SOCKS5 to server, HTTP GET to retrieve - jdisk could be generalized? (e.g., IBB to server) - WebDAV to upload, HTTP GET to retrieve - ICE-TCP - Torrent - avian transport :) - so many options -- how to manage? - also discussed pros and cons of negotiation methods: - Stream Initiation, a.k.a. SI (XEP-0095/XEP-0096) - support exists - no counter-offers - settle on a single negotiation method? - Jingle (XEP-0166) - counter-offers possible - flexible - scary - but scariness comes from ICE, not Jingle state machine - discover support via caps - also a migration path in SI (if caps not supported)? 4.2 Conclusions - IBB is the only transport method guaranteed to work - we've already punched a hole in the firewall via XMPP! - make this MTI but lowest-priority fallback - other transport methods are valuable in different situations - require support for HTTP GET on receiver side (for JDisk/WebDAV scenarios) - Pavel and Peter to document JabberDisk approach - Jingle is the more flexible negotiation method, so let's use it - but we need a migration path from SI 5.0 Jingle 5.1 Counter-offer process - content-modify is not well specified - agreement to use it only to change direction - therefore need new verb for content-replace - use this to counter-offer transport - reject content-replace if change of application type - file transfer application type must specify direction - typical case: file offer from sender to receiver - also: file request from receiver to sender - changing from offer to request (or vice-versa) is OK for content-replace 5.2 reasoncode and reasontext - this is ugly!!! - specify child elements instead for more robust error reporting 6.0 Other Topics 6.1 Distributed MUC - this is interesting, but do we really want/need to solve it? - treat your local MUC service as a proxy to others? - jointly manage .xmpp. TLD? - SRV records for failover? - e.g., if conference.jabber.org goes down then reconnect to chat.xmpp.org - list only the authorized proxies that you sync with - recommended approach for now 6.2 SRV records - RFC 3920 is not clear on necessity of SRV records for components - _xmpp-server._tcp.conference.jabber.org -> athena.jabber.org - we need to document and encourage this in rfc3920bis, XEP-0220, etc. 6.3 Machine-to-machine communication - need better support for automation resources (e.g., negative priorities) - use RAP (or something similar) for smarter routing at the server? 6.4 Component protocol - support ability for component to: - create a user session - get presence - get roster - layer these features on top of recent XEP-0225 6.5 Web integration / HTTP / SSO / OAuth / OpenID - not a great deal of interest, it seems - but there is interest in the HTTP world - XMPP as a window onto web-based services - great source of content / eventing for XMPP-based services - need way to put OpenID in XMPP user profile (XEP-0154) - list JID at OpenID provider page - <link type='???' href='xmpp:[EMAIL PROTECTED]'/> - use XMPP to federate HTTP silos 6.6 MUC++ - MEP = MUC Eventing via PubSub - Mingle = MUC room as control channel for multi-user Jingle - don't modify MUC services unless necessary: just use bots? - share presence with the room to receive caps - Collabora and Wimba interested in the Mingle idea - futher conversations to occur after the devcon 6.7 Message archiving - XEP-0136 is OK -- let's finish it - optional IMAP interface to archives? - split up XEP-0136 so that scary encryption stuff goes in a separate spec 6.8 Application platform - why define long complicated XML protocols for every feature under the sun? - they don't define every possible application as an HTML extension via W3C! - why not use something like JavaScript or Flash in the XMPP world? - long, interesting discussion -- but out of scope for XSF - interested developers to pursue after the devcon END
smime.p7s
Description: S/MIME Cryptographic Signature
