David says he hates the idea of groups (though he likes "pools") and of sending things to groups (though he likes "posting to pools"). Nevertheless I'm going to use the term "groups" because it helps me describe certain functionality, and I hope we can decide on terminology after the functionality's agreed to.

With that, I'd like to suggest some concepts and see how the team feels about them.

GROUPS
o I'd like to propose that each server can support an abitrary number of groups.

o A group is a logical construct consisting of a set of data:
   -- A set of users.
   -- A pool of messages.
   -- A set of metadata.
   -- Perhaps a set of business rules.

GROUP MEMBERSHIP
o All users are members of a group called something like "Public", which by definition contains the set of all users of the ESME server.

o A user may be a member of as many additional groups as desired.

GROUP CREATION, DEFINITION, DELETION
o Any user can create a group (or would we like the ESME administrator to be able to grant a "create group" privilege to only certain users?).

o The creator of the group is it's first (and initially only) administrator.

o A group's administrator(s) can add and remove users at will, and sets the privileges for each user.

o A group's administrator(s) can edit the group's metadata (e.g. it's name), and edit any business rules we support for groups.

[Daniel] I would love a feature to populate groups automatically based on business rules such as "create a group with all people with jobtitle=controller in
department="XYZ" (based on regular expressions this could be quite powerful. 

USER PRIVILEGES
o Within a group, each user has one of the following privilege levels:
     -- Read.  (Let's you read messages in the group's pool)
     -- Read and Write. (adds the ability to post messages)
     -- Read, Write and Administer (adds all admin privileges)

o The above model establishes three roles:  those of viewer, participant and administrator.

o Any user having at least READ privileges against a group has PERMISSION to see ALL messages in the group's pool.

ADMINISTRATOR PRIVILEGES

o Anyone with admin privileges is an administrator.  Thus a group can have as many admins as desired.

o There's no concept of "ownership", only of "control".  All administrators have equal control, and the creator of the group can drop off the set of administrators to pass control on to others.

o Over time, organizations will inevitably want finer-grained admin privileges.  Do we want to try to build them in from the beginning? For example:
     -- Moderate group (lets user delete messages?)
     -- Delete group (lets user destroy the group)
     -- Add/remove read and/or write users
     -- Add/remove, promote/demote, admin users

MESSAGE POOLS
o Before posting a message you must choose a group.  This defines the set of users who will have permission to read the message.

o By default, all users are members of the Public group, the Public group is the only group that is required for an ESME server, and thus in the simplest case all messages are posted to the public pool and accessible to everyone.

o Every message posted to a group goes into that group's message pool; which is the set of all messages posted to/within that group.

o Which messages a given user sees depends upon what the user has chosen to see (who he/she follows, what tags he/she tracks, etc.), and/or what he/she searches for.

PRIVACY
o So each message exists in one and only one pool, and only users of that pool's group have permission to access that message.

o Therefore by choosing a group before you post a message you are choosing the scope of privacy for that message; because (a) ALL members of that group will have a way (by searching, tracking, following, etc.) to SEE that message, (b) NO users outside that group will ever be able to see that message.

JUMPING THE WALLS OF PRIVACY
o Note that since a given message can only exist in one pool over its lifetime, if you want multiple groups to recieve the same message you must post it to each of those groups separately.  From an intuitive, end-user standpoint this appears to be a case of posting the same message to multiple groups, but to the system each posting is a separate logical entity (each has it's own unique ID, even if the text of each is the same).

o So if you see a message in one pool that you want users of another pool to see, you have to "copy" it from the one and "paste" it into the other.

o This gives us a simple, safe privacy model, yet makes it easy and convenient for users to circumvent the rules when necessary.  It takes the burden off the system to manage access control of cross-pool messaging, and puts the burden of responibility on the user.

[Darren] To address "jumping the walls of privacy" we could allow groups to be members of other groups. This means that a user wanting to make a message available to Group1 and Group2 could simply create a new group, "Group1and2" and add Group1 and Group2 as members.

ACCESS CONTROL
o Thus the fundamental access control model is:  (a) create groups of users that need to communicate with each other, (b) post messages to the appropriate group, (c) the system will keep your messages private to the group.

PRIVATE, INTERPERSONAL MESSAGING
o I think we also need to make it possible to have private conversations between any two users without having to formally set up a group.  It should be easy to make it so that you choose a user in the UI as the "group", post a message, and see all the messages in this ad-hoc, private pool.

o But then, of course, the two users are going to want to bring others in on some conversations, so maybe it would be better to make private, ad-hoc group messaging a property of conversations....  I don't yet have a suggestion for how to handle this anticipated end-user desire.