| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was originally not done based on my interpretation of XEP-0045. Today's
reading, however, revealed that it actually says the result
> SHOULD contain **at least** a <username/> element
(emphasis mine)
I take this to mean that including a form **is** allowed (and I think this is
sensible). Tigase already includes the form I believe.
I've gated the new behaviour behind a (default off) option, because it hasn't
been tested for compatibility with clients. My primary desire for it is in
Snikket, where the clients will be tested to ensure compatibility with this.
I don't anticipate that (m)any clients would break, so maybe after 0.12 we can
experiment with enabling it by default and eventually remove the option.
|
| | |
|
| |
|
|
|
|
|
| |
If nickname enforcement is enabled this would otherwise let you bypass
the join check in muc.lib by registering an invalid nickname and then
joining with any nickname, letting register.lib change it to the invalid
registered nick.
|
| | |
|
| |
|
|
|
|
| |
Prevents traceback from resourceprep(nil)
muc#register_roomnick is also required in XEP-0045
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There is currently no mention in XEP-0045 of how or where to advertise
support for registration.
Advertising on the host JID may be confusable with service-wide
registration, as implemented in ejabberd.
A common and sensible pattern in XMPP is that a feature is advertised on
the JID where the service is available.
|
| | | |
|
| |/
|
|
| |
Affiliation data is passed as a loop variable so no need to retrieve it
|
| |
|
|
| |
affiliation (thanks jc)
|
| | |
|
|
|
as per XEP-0045
|
