1 Conference control
Conference control in IRC and PSYC
With IRC each server has full conference control over a channel on the network - each one of them can say XY is an operator and YZ is banned. In the case of netsplits there are various logics to figure out which side is authoritative, but if the server is evil, it can always say its users started that channel somewhere around 1970 and thus have the authority over the channel.
PSYC has a context master (theoretically more than one, but we didn't implement any of that). One server hosting the context program which defines the conference control for the chatroom. All nodes that are involved in distributing the context to its members may be entitled to perform certain jobs on his behalf, but the protocol always makes it clear who has the authority.
2 Decentralized conference control
In 1995 lynX wrote a draft on decentralized conference control. It also provides for redundant context masters, nicknamed group authorities in the draft. The canonical context master can declare for back-up context masters that would take over control whenever necessary. The concepts of group structure and multicaster may be superceded by context slaves and newer approaches to multicasting. The single letter flags should be variables these days and belong into the distributed state. This has never been implemented or updated, since the need for such a protocol hasn't materialized until now with PSYC2.
3 Floor control
Floor control, to put it simply, is a subset of conference control which handles who is in charge of talking.
There is a new IETF protocol on this issue. Very focused on realtime requirements, which makes it more interesting and complicated. It's called Binary Floor Control Protocol (BFCP) and it's documented in RFC 4582.