This is cross-posted from EnThinnai Blog.
Background:
During the recent Enterprise 2.0 Conference that took place in Boston, there was a panel called Microsharing: It is All About the Tools. It is Not About the Tools. It was moderated by Marcia Conner. Stowe Boyd felt that the panel "demonstrated that there is widespread disagreement, confusion and even antipathy about streams in business." So he wrote blog post enumerating the characteristics of Streams, which is an abstracted service concept of Twitter and also highlighted the differences between Streams and email.In this post I argue that indeed business would benefit from the service concepts of both Streams and email and I propose a service concept that integrates them.
Access Control: Publisher vs. Consumer:
The first defining characteristic that Boyd identifies is the "asymmetric relationship" widely attributed to Twitter. But he points out that this is derived from the public blogging model. Interestingly he dismisses the limit of character count, another characteristic of Twitter as not the most productive distinction. He makes it clear that the real focus should be on the way content is published and consumed. Content creators publish with no specific intended recipients. Content consumers have their own way to filter from this vast collection of content with no a priori agreement with the publishers. Certainly, the publishers can facilitate consumers' filtering process with other techniques like hashtags. But the critical thing is that the publishing and consumption processes are independent.
Boyd contrasts this to email where the publisher determines and selects the set of consumers. For him this is a critical flaw. If streams are elective on the consumers' side, email is elective on the publishers' side. If streams are inherently more distributed and bottom-up, email is inherently more centralized and top-down.
But I am uncomfortable with this categorical dichotomy. If Twitter is a prototype of Streams, it may be instructive to note how it is being used by its users, especially because Twitter users are well known to develop adhoc conventions to overcome some of the limitations. Even though Twitter streams are public and anybody can access them, users feel certain tweets are private and meant for a single individual. This is met by "direct message" (DM). In a business environment, the need for privacy is more acute. Businesses have fiducial and legal requirements to keep certain messages confidential. Only the publisher can know the level of restriction. Secondly, the general understanding in Twitter is that it is possible for a person to miss a particular tweet. It is well known that tweets are phatic. To ensure that a particular person reads a tweet, publisher usually uses an "@message". Twitter's web interface and almost all third party clients list @messages ("mentions"). This is a call for a specific consumer to pay attention to a particular tweet, but decided by the publisher. Thirdly, as Boyd notes, publishers can use hashtags to telegraph the intended audience for a tweet. All these point to the need for "elective on the publisher's side" as well.
To summarize, Streams must allow for different level of access restriction: all the way from free access to free within a domain to restricted to people with a certain responsibility to a set of identified people.
Tummlers: Individuals and Tags too:
Kevin Marks talks about the role played by "Tummlers" in expanding the conversation. Since one routinely reads tweets from only a set of people, it is possible to be stranded in a Twitter island. But so called Tummlers play the role of bridging these islands. Usually Tummlers retweet to spread information from one island to another. But ever inventive Twitter users have found another way - hashtags. Publishers attach hashtags to their tweets and others, even non-followers can search for a specific hashtag term. These tags can be viewed as "interest tags" as expressed by consumers. In other words, a publisher is saying that a tweet will be of interest to those who are interested in the tags identified in the tweet. But business context requires another kind of tags. In keeping with the requirement that businesses may have to control access, publishers may have to control access to only those whose area of responsibility includes those identified in what I call "responsibility tags".
Accordingly, in the new service access rights will be determined by three parameters: A "To" list as in the traditional email, a list of responsibility tags along with the identification of the authority that issued the responsibility and finally a list of interest tags. A publisher has to identify these three parameters and the specific logical combination that should be applied.
Let me elaborate with a few examples. If the publisher has put Aswath in the To list, acme.com/marketing in the responsibility tag and VoIP in the interest tag and the logical combination, is "AND", then Aswath can access this post only if acme.com has asserts that Aswath has marketing responsibility AND Aswath has expressed an interest in VoIP. On the other hand if the logical combination is "OR", then Aswath or anybody who has marketing responsibility according to acme.com or anybody who is interested in VoIP can get access to this post. Of course the logical combination can be a bit more involved.
Anatomy of a Stream:
As was pointed out earlier, Boyd states that Twitter's size restriction may not be relevant for businesses. Dave Winer has been lobbying for a long time that Twitter should allow for metadata. He points out that shortened URLs are attaching pictures or other media via URLs are examples of metadata. Twitter itself has announced plans to introduce a new feature called Annotated Tweets. Not withstanding all that, there is a real benefit in capturing the main idea of a post in a pithy comment. This allows the reader to quickly scan many messages before deciding to select a subset of them to dig deeper.
So Streams should adopt "Subject" field used in email, but restrict the length of Subject field to 140 characters. Furthermore, the recipients will first see only the Subject and possibly an initial segment of the post, but no more than 140 characters. A recipient can access the full post if so desired.
Distribution of Streams:
email and Streams differ in how they distribute messages. In email the sender explicitly identifies the list of recipients. Then the sender's server distributes the message each of the recipients' servers individually. On the other hand distributed systems like XMPP use Pubsub like mechanism. More recently, this mechanism is further refined with PubsubHubBub. In this mechanism the originating server uses intermediary Hubs to reach the ultimate servers. In a business environment either of the schemes have some undesirable qualities. Since the email system delivers the complete message to the recipients, one of them can forward it further down the line. The originator has no control or record of such distribution down the line. In the case of PubSubHubBub, the intermediary nodes have access to the message. even if the message is encoded, the mere fact that two enterprises/individuals are communicating itself may be potentially sensitive information. So an alternative, efficient mechanism must be used that takes into consideration privacy concerns.
When Streams identifies an individual recipient, then it should first determine whether that recipient is a Streams user. If so, the Subject of the post along with the URL to retrieve the complete post will be posted to the recipient's server using webhooks. If the recipient is not a Streams user, then the creator will be notified to inform the recipient using some other method like an independent mode of communication. The address resolution algorithm may resolve to a group of people identified by a Responsibility tag under a domain. In this case, the domain may not revel the individuals associated with the Responsibility tag since that could be a sensitive information. In this case, the Subject of the post and the retrieve URL will be deposited to the domain which in turn will distribute to the relevant individuals. Finally if a group is identified by an Interest tag under a domain it is possible that the group may be a large number. So in this case, the Subject of the post and the retrieve URL will be deposited to the domain, which will distribute to the individuals.
Threaded Stream:
Traditionally email systems treated messages individually. Then Google introduced the concept of threaded messages in GMail. Still it is from the perspective of the recipients. If one person is excluded from the reply then that person looses the threaded view. We should also note that an email thread captures organizational memory. This organizational memory would be of help to a new person joining the group.But current email systems are not very effective in facilitating transfer of knowledge base. Streams musty endeavor to provide this.
Accordingly, Streams should keep responses to a message along with the original message, identifying the author of each of the responses. Further, the original creator of a message must be able to add new recipients at a later time.
Summary:
1. Publisher can specify the audience for a stream using three parameters: Individuals identified by "To" field, Responsibility Tags and Interest Tags.
2. A stream will contain a Subject field that summarizes the content of the stream and is of limited length.
3. Stream will also contain a field called Body. It can contain arbitrary digital content and can be of arbitrary size.
4. Recipients can be individuals or a group whose members can only be determined by a third party domain.
5. Individuals and third party domains will be given the contents of the Subject field and an URL to retrieve the stream. When somebody tries to access the URL, the user will be authenticated to maintain the integrity of the access control stipulated by the publisher.
6. Any followup exchange to a stream will be appended to the Body of the stream.
Shameless Self-promotion: These and other thoughts were the motivational forces for EnThinnai. A showcase implementation has captured all of the requirements except for Responsibility and Interest Tags.