> 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 identi.ca. 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. Vassil
