Here are some possible DevCon agenda items...
Room: firstname.lastname@example.org (would be an xmpp: link if this wiki supported it)
- 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
Consensus to solve the basics
- Component Binding
- Use jabber:client
- Specify simple username format more carefully
No consensus to solve more advanced features yet
- Domain subscription
- Namespace subscription
- Presence subscription
- Roster subscription and manipulation
Lengthy discussion about using MUC for communities. PSA to write up with help from Bruno and Yann at Wimba.
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
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
- 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
- Justin's "JEP-Secure"
- SPAM fighting / reporting
- 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.
- 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
- Existing methods don't work well enough
- Requirement to send multiple files? Also thumbnails?
- Jingle to get reliable transport (e.g., ice-tcp, perhaps even IBB)
- Then: HTTP? IQs?
- IBB is a good fallback if all else fails
- Conclusion of IRL discussions: we need to clearly define 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)
- persisting public data objects
- private data storage
Works in progress:
- 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 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 POP
SHARED EDITING / WHITEBOARDING
- similaries to MUCOL (permissions / media sessions)
- extended presence
- more use cases beyond IM