On Thu Aug 14 19:03:24 2008, Matthew Wild wrote:
IRC has the concept of invitation-only rooms. Although this isn't
implemented in any MUC server that I know of, today's protocol
leaves
the option for implementation open, while this one doesn't.
Why not do what we discussed in ages past? Leaving off the domains to
make my typing less - and because I can't spell shakespeare:
1) Crone requests an invitation ticket from Dark Cave:
<iq from='crone1' to='[EMAIL PROTECTED]' type='get'>
<invite xmlns='...'>
<to>hecate</to>
</invite>
</iq>
2) Dark Cave returns one.
<iq from='[EMAIL PROTECTED]' to='crone1' type='result'>
<invite xmlns='...'>
<to>hecate</to>
<from>crone1</from>
<ticket>[hash output, maybe HMAC]</ticket>
<timestamp>[Timestamp]</timestamp>
</invite>
</iq>
3) Crone1 now sends this invitation to Hecate - privacy lists are
still okay (I can't be bothered typing, so I'll leave out the data
itself, but it's simply copied):
<message from='crone1' to='hecate'>
<invite>
<conference/>
<to/>
<from/>
<timestamp/>
<ticket/>
</invite>
</message>
4) Hecate joins the MUC room using the invitation:
<presence from='hecate' to='[EMAIL PROTECTED]/hecate'>
...
<invite/>
</presence>
Now the MUC can *at this point* verify that the ticket is valid, and
add Hecate to the membership as needs be. Worth noting that this also
allows Hecate to know if the invitation was genuine.
This doesn't preclude leaving off the ticket fetching part, of
course, when not needed or supported by the MUC, so we've a nice easy
upgrade path. ANd MUC implementations don't need to store any
additional state - in fact, if Hecate doesn't want to join, then that
means he won't even be listed as a member.
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
