esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vassil Dichev <>
Subject Re: ESME Groups
Date Thu, 12 Mar 2009 22:43:57 GMT
> 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.
> Thoughts, anyone?

One more reason for me to regret not being at QCon- if I was there, it
would probably be easier for me to tell what's on that picture :)

My first idea was the simplest thing that could work, which is how
some people have implemented ad-hoc groups for Twitter. A Twitter
group in this context is a user, behind which is a bot, retweeting
every reply to it from someone the bot is following. Apart from
syntax, that's about how it works in

ESME has easy auto-retweets (the resend action). So the only
interesting part is security, or restricting who can see which
messages. AFAICT, this is what David calls pools. For simplicity, I'm
not going to discuss read-only access without permissions to write to
a group.

With what Twitter has as functionality it's easy to restrict messages
from different users. If a user has "protected updates", it's easy to
simulate a private group with access control who can read its
messages. If whomever this "group user" follows can see its updates,
then the follower has read access in the group.

The problem with this approach as I see it is that if you change a
user's updates to protected the way it's done in Twitter, updates
which you were able to see would suddenly disappear. If a user
unprotects their updates, it's worse- updates, which were restricted
are now accessible (not good in an enterprise environment). This is
both inconsistent and slow- for every message we would need to query
if the user has protected their updates or not (maybe that's what
Darren has referred to when he mentioned about crippling performance).

To continue in the spirit of immutability, which was set by David, we
could have a protected flag for a message, not a user, and once the
message is created, it can't be changed. In this way, whatever was
secret, will be guaranteed to be secret within the system. It's also
easy to think of a direct message as the simplest protected message-
i.e. one which is not resent.

Which of these ideas do we want to keep? Which of them make sense? I
don't want to blindly copy what's in other messaging platforms- maybe
ESME has a better mechanism for dealing with some of the issues. Of
course, if it feels like a hack, we'd better redesign in a clean way.


View raw message