Difference between revisions of "DevCon3Agenda"
Jump to navigation
Jump to search
Neustradamus (talk | contribs) m |
|||
(28 intermediate revisions by one other user not shown) | |||
Line 1: | Line 1: | ||
Here are some possible DevCon agenda items... | Here are some possible DevCon agenda items... | ||
Room: devcon@conference.jabber.org | Room: [xmpp:devcon@conference.jabber.org?join devcon@conference.jabber.org] | ||
==XMPP-CORE== | ==XMPP-CORE== | ||
[http://xmpp.org/extensions/xep-0198.html XEP-0198: Stanza Acknowledgements] | |||
* Stanza size limitations | * Justin to update the spec to reflect IRL discussion | ||
Mixed child elements in message/presence (Justin to write first draft of best practices spec): | |||
* Each message stanza is of a single profile. | |||
* Transmission elements don't affect the profile, and these elements need to be noted as transmission elements in whatever document proposes them (e.g. x:delay, AMP). | |||
* Each element is part of some profile. Unless otherwise stated, every element of a given namespace is in the same profile. | |||
* Unknown elements don't affect the profile. | |||
* Mixing profiles is invalid, except that you may mix the IM profile with any other profile as a fallback means. | |||
* When determining what profile a stanza falls under, consider the IM profile as a last resort. | |||
* need to specify in transmission specs that they are transmission elements | |||
* need to specify in message payload specs that they are in IM profile or some other profile | |||
Stanza size limitations | |||
* specify that stanza-too-big error includes max stanza size | |||
* specify IQ interaction for client to set its desired max stanza size | |||
==COMPONENT PROTOCOL== | ==COMPONENT PROTOCOL== | ||
* | Consensus to solve the basics | ||
* TLS | |||
* SASL | |||
* Component Binding | |||
* Use jabber:client | |||
* Specify simple username format more carefully | |||
No consensus to solve more advanced features yet | |||
* Domain subscription | * Domain subscription | ||
* Namespace subscription | * Namespace subscription | ||
Line 15: | Line 36: | ||
* Roster subscription and manipulation | * Roster subscription and manipulation | ||
* Route | * Route | ||
==COMMUNITIES== | |||
See [http://www.wimba.com/labs/mucom/ MUCOM] | |||
Lengthy discussion about using MUC for communities. PSA to write up with help from Bruno and Yann at Wimba. | |||
Notes...... | |||
conference/community | |||
a profile of MUC | |||
presence only MUC (or can send messages to group) | |||
define sensible defaults | |||
deploy as separate service | |||
disco#items to find communities | |||
disco#info to discover community type | |||
(or receive via caps) | |||
presence subscribe to community | |||
presence subscribed from room | |||
log in | |||
server sends my presence to room | |||
presence from='comm' | |||
CAPS say "I'm a community" | |||
presence | |||
need ability to query room for member list | |||
roster annotation for items that "this is a communities item" | |||
get annotations before get roster | |||
who can see community via disco#items? | |||
who can join community? (subscribe to community) | |||
who can see presence of community members? | |||
whose presence is shown in community? | |||
send my privacy list (presence out) to community so it can filter presence-out | |||
==MUC STUFF== | ==MUC STUFF== | ||
* [http://www.wimba.com/labs/mucol/ MUCOL] | * [http://www.wimba.com/labs/mucol/ MUCOL] -- Bruno discussed on Day One | ||
* [http:// | * [http://xmpp.org/extensions/inbox/distributedmuc.html Distributed MUC] | ||
* Message moderation | * Message moderation | ||
==SECURITY== | ==SECURITY== | ||
* Requirements, requirements, requirements ([http:// | * Requirements, requirements, requirements ([http://xmpp.org/extensions/xep-0210.html XEP-0210]) | ||
* Stanza signing (broadcast and directed) | * Stanza signing (broadcast and directed) | ||
* Auth via PGP key? (IIRC there's a TLS method for this - see http://tools.ietf.org/html/draft-ietf-tls-openpgp-keys | * Auth via PGP key? (IIRC there's a TLS method for this - see http://tools.ietf.org/html/draft-ietf-tls-openpgp-keys | ||
* ESessions | * ESessions | ||
* Justin's "JEP-Secure" | * Justin's "JEP-Secure" | ||
* SPAM fighting / reporting | * SPAM fighting / reporting | ||
* DDoS | * DDoS | ||
* | * Ubiquitous TLS on open network -- can't get rid of Server Dialback anytime soon, but how do we encourage server admins to get certs? "Secure Communications Week" with TLS only? | ||
* Server reputations | * Server reputations? Lukewarm reaction. | ||
User registration | |||
* CAPTCHAs for user registration? | |||
* Redirect to website, the web folks have to deal with this more than we do so they are probably better than we are! | |||
* Limit number of accounts created in a time period | |||
Groupchat spam problem | |||
* IP hash | |||
* Auto-ban based on bad word filter | |||
* Host server limits number of accounts created in a time period | |||
* Per-room karma | |||
==FILE TRANSFER== | ==FILE TRANSFER== | ||
* Existing methods don't work well enough | * Existing methods don't work well enough | ||
* Requirement to send multiple files? | * Requirement to send multiple files? Also thumbnails? | ||
* Jingle to get reliable transport (e.g., ice-tcp) | * Jingle to get reliable transport (e.g., ice-tcp, perhaps even IBB) | ||
* Then: HTTP? | * Then: HTTP? IQs? | ||
* IBB is a good fallback if all else fails | |||
* Conclusion of IRL discussions: we need to clearly define requirements... | |||
Requirements... | |||
* Usually XMPP and HTTP servers available | |||
* Offline use case | |||
* Upload to MUC room | |||
* Virus check at server | |||
* No HTTP server available | |||
* No XMPP server available (link-local) | |||
==PUBSUB/PEP== | ==PUBSUB/PEP== | ||
Line 47: | Line 127: | ||
Specs: | Specs: | ||
* [http:// | * [http://xmpp.org/extensions/xep-0060 XEP-0060: Publish-Subscribe] (1.9) | ||
* [http:// | * [http://xmpp.org/extensions/xep-0163.html XEP-0163: Personal Eventing] (1.0) | ||
Works in progress: | Works in progress: | ||
* [http:// | * [http://xmpp.org/extensions/tmp/xep-0060-1.10.html XEP-0060 1.10 working draft] | ||
* [http:// | * [http://xmpp.org/extensions/tmp/xep-0163-1.1.html XEP-0163 1.1 working draft] | ||
IRL discussions: | |||
* Come up with ~5 node types a la MUC room affiliations? -- all these node configuration options are too complicated and users will never be able to handle them! Here are some possibilities.... | |||
* Private node: whitelist access model, only account owner on whitelist, persist data -- see [http://xmpp.org/extensions/inbox/pdp.html PDP] | |||
* Public node: open access model, anyone may subscribe or get items | |||
* Eventing node: presence access model, filtered notifications | |||
* Data node: open access model (e.g., public keys / user profile), persist items -- see [http://xmpp.org/extensions/inbox/pop.html POP] | |||
==SHARED EDITING / WHITEBOARDING== | ==SHARED EDITING / WHITEBOARDING== |