On Fri Oct 15 08:08:19 2010, Justin Karneges wrote:
Just throwing out ideas, and I'm curious if anyone out there has
done
hierarchical permissions in their MUC implementations, standard or
not.
Kind of.
M-Link has - sort of - domain level affiliations, for MUC at least.
I'm going to (as part of my workload for the next major release we
do) unify these into proper domain-level affiliations, but for now
they operate only for the Owner and Outcast, and basically grant a
Super affiliation or ban from every room respectively.
Clients don't see the Super affiliation or role in M-Link, they just
see them as Owner and Moderator respectively, but "true" Owners can't
do much about Supers, and Moderators cannot demote Supers either.
Similarly, there's a global "operators" group which is effectively
granted Super across all domains (including both MUC and IM, and I
should get this working for PubSub shortly).
For groups of rooms, it's just limited to having multiple MUC
services. In general, this is what we recommend to customers with
complex access-control needs (for instance, we do have true
domain-level labelling and clearances, as well as room-level, and
we'd be happier seeing label-capable clients support these rather
than only handle a single MUC domain as most do).
I'd be inclined to stick with this pattern, too - add domain-level
affiliations in a more general way, include them in protocol (we
currently use a magic room in MUC), and not try to expose them (very
much) in the affiliation lists of the node/rooms. The problem with
doing so is that domain-wide Owners cannot be overridden, and I think
exposing them as affiliations on each node is going to be confusing -
in operational circumstances, these are either special accounts and
rarely used (and called "administrator" or "root"), or else they're
known to the users by out of band means (ie, in Isode, everybody has
quickly learnt that Kev and I are system-wide operators).
Either way, users quickly understand that the superusers are beyond
their means to control, and act accordingly.
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
