DevCon3Agenda

From XMPP WIKI
Jump to navigation Jump to search

Here are some possible DevCon agenda items...

Room: devcon@conference.jabber.org (would be an xmpp: link if this wiki supported it)

XMPP-CORE

  • Mixed child elements in message/presence -- put in order, process in order (PSA nominates Justin to write a best practices doc about this!)
  • XEP-0198: Stanza Acknowledgements
  • 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

  • Authentication (TLS + SASL)
  • Domain subscription
  • Namespace subscription
  • Presence subscription
  • Roster subscription and manipulation
  • Route

MUC STUFF

SECURITY

  • Requirements, requirements, requirements (XEP-0210)
  • 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
  • ESessions
  • Justin's "JEP-Secure"
  • Ubiquitous TLS on open network
  • SPAM fighting / reporting
  • CAPTCAs for user registration (redirect to website, the web folks have to deal with this more than we do so they probably do it better!)
  • DDoS
  • IP Hashes to reduce groupchat spam
  • Server reputations

FILE TRANSFER

  • Existing methods don't work well enough
  • Requirement to send multiple files?
  • Jingle to get reliable transport (e.g., ice-tcp)
  • Then: HTTP? IQ?
  • 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

  • publish-options
  • persisting public data objects
  • private data storage

Specs:

Works in progress:

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!
  • Private node: whitelist access model, only owner on whitelist, persist data -- see 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

SHARED EDITING / WHITEBOARDING

  • similaries to MUCOL (permissions / media sessions)

OTHER OPPORTUNITIES

  • extended presence
  • more use cases beyond IM