216
edits
Difference between revisions of "DevCon3Agenda"
Jump to navigation
Jump to search
m
no edit summary
Neustradamus (talk | contribs) m |
|||
| (8 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:// | [http://xmpp.org/extensions/xep-0198.html XEP-0198: Stanza Acknowledgements] | ||
* Justin to update the spec to reflect IRL discussion | |||
Mixed child elements in message/presence | Mixed child elements in message/presence (Justin to write first draft of best practices spec): | ||
* Each message stanza is of a single profile. | * 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). | * 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). | ||
| Line 22: | Line 23: | ||
==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 72: | Line 80: | ||
==MUC STUFF== | ==MUC STUFF== | ||
* [http://www.wimba.com/labs/mucol/ MUCOL] -- Bruno discussed on Day One | * [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 | ||
| Line 83: | Line 91: | ||
* 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? | * 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? 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== | ||
| Line 110: | 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: | 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.... | * 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:// | * 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 | * Public node: open access model, anyone may subscribe or get items | ||
* Eventing node: presence access model, filtered notifications | * Eventing node: presence access model, filtered notifications | ||
* Data node: open access model (e.g., public keys / user profile), persist items -- see [http:// | * 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== | ||