Warning This raw material from the mailing list and must still be formated.

Cool - this means that each Access Control List (ACL) can exist as an object. Multiple messages in the same thread will reference the same ACL object. The SecurityManager can use a cached map of "(User, ACL) -> Permission", e.g. "(dhague, ACL_1b3cd5e) -> Read" which will improve performance over evaluating the ACL fresh each time.

How would you refer to a pool? If it uses the same syntax as for a user (@ sign), this is not only confusing, but there could be potential name clashes when pools and users have the same name. If a pool *is* a user (as in the ad-hoc Twitter groups I described), would it be less confusing?

> otherwise be put in as well as put in the mailbox of all administrators of
> the named pool as long as those people had access to the pool that message
> was also put in

So if a message can be only in one pool, does it mean it's copied as a new message (with the same text) or does it mean that it's only sent with the user's default pool? Judging by the context, it's not replicated, and then administrators can only see this message if some of them have access to the pool in which the message belongs. That
means that if none of the administrators have access to the message's pool, it will be silently ignored. This can't be a good thing, since the user doesn't have an idea who the administrators are, not to mention which pools they have access to. Eventually this mandates sending all messages *to* a pool are sent in the default pool? This seems to be the only way  to guarantee it can be read by an administrator.

> This is a direct message to the pool.  This is just like the upcoming direct
> message to a person.  Darren came up with the idea and the semantics are
> perfect.

Direct messages to a person is another thing, which is not clear to me: are they implemented as a pool, to which only the two sides have access? If so, the number of pools could be enormous- n * (n-1) / 2 only for direct messages.

I can easily imagine a pool as a list of messages, to which certain users have access. Still, I find the current description still mixes up this concept with the one of "pool as a user".

A message may only be in one pool.  There is no way for a message to escape the pool (eg. resend cannot change the pool) and any replies (or comments in FB parlance) are in the pool of the original message (this is for performance and security purposes.)

It seems I got the right idea on at least 2 counts:
-pools are not about resending messages (we already have that)
-access restrictions in a pool apply to messages, not to people

a pool is about the messages, a group is about the people.

Thanks for laying this out. It now finally dawns on me why it's important to use the term "pool" rather than "group": a pool is about the messages, a group is about the people. Of course, via LDAP etc, we can implement pool security by mapping to LDAP groups, and (as you say) even create pools based on groups. Using the term "group" might lead people to think they are sending a message to a group of people, whereas they will actually be making it *available* to a group of people, should anyone in that group choose to look in the pool.

Facebook's new front page has groups.  Groups are personal things where I assign different people into different groups and the meaning of a group is individual to me and it's all about my view of the world.  This keeps to the "opt in" mechanism that we absolutely must preserve in ESME.  If we do this type of group in the future, that's way cool, but once again, it's a personal thing that has nothing to do with access control or "sending".

Darren and I talked about pools.  Pools are collections of messages that can only be read by people who have been granted access to that pool. @pool_name *DOES NOT* "send to that pool."  A person who has access to a pool is see messages put into that pool that otherwise meet the person's criteria (who they are following, what their filter rules are.)  There is no "send to a pool" concept.  It's "place a message in a pool" and all messages are placed in one and only one pool and by default, that pool is the server-local public pool.  We can automagically create pools based on LDAP groups.  We can automagically add/remove access to pools based on LDAP groups.  We can mirror what LDAP does without destroying the most important piece... ESME is opt-in.

A User has a relationship with a pool.  That relationship is read/read-write/administer (which implies read-write).  If someone @pool_name a message, that message will be posted to whatever pool it would otherwise be put in as well as put in the mailbox of all administrators of the named pool as long as those people had access to the pool that message was also put in.  This allows a user to request access to a give pool without having to know the names of the administators of the pool.

So, how do you get a message into a pool?  You will define your default pool.  This is the pool that your messages get put into unless you specify otherwise.  This means that the CEO can choose to put things in the "c-level" pool by default.  Most people will post to the public pool by default.  If you are in a text-only interface, you will do the following: d pool_name message

This is a direct message to the pool.  This is just like the upcoming direct message to a person.  Darren came up with the idea and the semantics are perfect.

We may choose to layer a UI on top of this with a pull-down for target pool and maybe even change the UI (color or image or icon) to reflect the target pool.

I understand that we are using groups and pools to mean something different than people are used to.  ESME is a different medium than people are used to.  That gives EMSE its power.  ESME is powerful because it is a dynamic, opt-in, social medium rather than a point-to-point communications medium.  There are different concepts in ESME than in point-to-point mediums.  Let's do the extra work now to make sure we understand those differences and celebrate those differences and get others excited about those differences so that ESME can thrive for what it is... a social tool for social animals.
^
Step 1, I think, will be to implement a Security Manager concept which  can be applied to the reading/writing of messages. Following on from  this, we can build the internals of the Security Manager implementation
- this will utilise the group concept. In parallel, it would be good if  the UI guys can start thinking about how users would create/edit  groups.  As an initial idea for actually sending the messages, simple  Twitter-like d- and @-syntax can be used to refer to groups as well as  users.