o OK, so I've suggested that: messages be clustered into pools, each pool has a wall of privacy around it that ony allows users in it's group to "fish" for messages from that pool, and that a given user may be a member of multiple groups and thus have access to multiple pools of messages.

o So how to we convert the user's permissions against this multi-pooled dataspace into useful and usable views?

HOW ARE MESSAGES STORED?
o I'm assuming that messages are basically records in a relational database, and therefore that creating end-user views is (mechanically) a matter of running a query and formatting the output.

STREAMS
o Most of the time the view a user wants is an ordered list of messages meeting certain criteria.  I call these lists "streams".

o In various contexts I have heard the use of terms like "timeline", "mailbox", "tracking", "conversations", etc.  In all cases the common element is that they all consist of a query against the set of messages, a results set that is limted by a user's access controls, a sort order (usually reverse-chronological order), and the results displayed as a list of messages.  I would call all of these streams.

o Here are some common streams:
     -- The Public timeline.
     -- A conversation.
     -- A track (a timeline defined by your tracking criteria).
     -- The messages directed (via @yourname) to you.
     -- Replies to your messages.
     -- Each group would have its own timeline.
     -- The set of messages sent by users you follow.

SYSTEM-DEFINED STREAMS
o The system should create certain predefined streams for you on demand.  You should simply be able to ask to view, and get a stream for:

     o The messages in a selected group's pool.
     o The messages sent by a selected user.
     o The messages with a seleted tag.
     o The messages posted by users you follow.
     o All messages in the Public pool.
     o The messages you've sent.
     o etc.

[Daniel] All messages containing a defined expression?

ACCESS CONTROL IN STREAMS
o In all cases, each user only gets to see those messages that their access privileges allow them to see.

o For example, if you follow someone who posts to groups of which you are not a member, you will never under any circumstances be able to see THOSE messages.  On the other hand, any messages posted to the Public group (of which you ARE a member), and posted to groups of which you are a member; you'll be able to see in the streams you request.

DIRECTED MESSAGES
o So what happens if a poster directs a message (via @username) to a given user, but does so when posting to a group of which the user is not a member.  In that case, by the rule of group privacy, the targeted user would never see the message.

[Daniel] The sneder should get a feedback on that.

FILTERING STREAMS
o We should make it possible (and easy) for users to filter a stream.

o For example, let's say that a given server has only one group defined so far, the Public group, making all messages in the server available (in theory) to all users.

o By default, on viewing the public stream, we would display only the most recent (say) 20 messages, and let the user page back in history to see previous messages.

o We should also let the user apply ad-hoc filtering criteria to the stream without having to formally do a search.  So the user could ask to see only messages with a certain tag, and/or by a certain user, and the stream should re-display with most recent (say) 20 messages from the now-filtered list.  Underr the covers I expect this to be implemented as an ad-hoc query, taking some search criteria from the basic stream definition and adding some terms from the user-selected criteria.

TRACKING
o Tracking seems to me to be nothing more than stored queries that produce streams.  So for example when you say "show me my track of the ESME tag", the server runs a query against all the groups to which you have access for messages tagged with ESME, sorts them in reverse chronological order, and shows you the first (say) 20 results.

SEARCHING
o So far I've described timelines and tracking as ways to generate streams on-demand by running stored queries.  The only real difference is that at the UI level we are calling them different things for the user's benefit.

o I think we should also make it possible for users to explicitly "do a search".

o users should be able to create a query by specifying:
    o which group pool(s) to search.
    o what tags to look for.
    o what date range to search.
    o whether files, URLs, etc. are attached.
    o what user sent them.
    o etc.
And to be able to show the results in various ways:
    o list of messages.
    o list of files or URLs sent as attachments.
    o a graph of message volume over time.
    o a chart showing the most/least active users.
    o a cloud of tags, or users, or keywords, etc.

CLOUDS
o I think of a cloud as another kind of view onto the results of a query; although a cloud is special in that for performance reasons you need to pre-compute much of the results set (e.g. by indexing.).

o So, for example, the cloud of tags used by JohnDoe would be the precompiled list of tags, filtered by their association with JohnDow.

o Since cloud data has to be pre-compiled, we have to define what kinds of clouds we're interested in.  We currently have tag clouds, and that seems like it should stay.  We currently have word-frequency clouds, and I'm not sure we should keep this.  If we want to have user-participation clouds, etc. we'll need to say so up front.
[Darren] I agree that word-frequency clouds should go. They were a great idea, but one that simply didn't work out in practice - common words (mostly "I") tended to dominate, and eliminating such common words would be a whack-a-mole task.

[Daniel] Additionally we should provide the content of clouds also via an api. (this decouples ESME from means to present the cloud content.)

CHARTS
o System administrators will need to see charts of different kinds to monitor system loading, performance, error rates, etc.
o Maybe there are charts that end-users would like to see too.  For example, would group administrators want to see charts of activity levels over time?