« Avoiding Communication Tunnel Vision | Main | Sponsored Conversations: Four Models But Nothing Perfect »

March 03, 2009


Feed You can follow this conversation by subscribing to the comment feed for this post.


Mike -- For Traction TeamPage's LiveBlog product: security, access controls, archiving/logging, LDAP/AD integration, and policy management (including groups defined by dynamic LDAP/AD queries) are all handled by the TeamPage engine (along with permission aware display of search results, RSS/Atom feeds, IM notification, email digests, and inline comments, and paragraph level tagging). I'm not aware of a competing product that goes deeper or does more.

"LiveBlog" is a specialized (ajax) skin with live updates and a Twitter like interface that can be specified as the default for any TeamPage project (aka workspace). The content of a LiveBlog post can be viewed, tagged or replied to using the LiveBlog UI - or the UI search, syndication, inline comment and all other capabilities of the TeamPage product.

Please see my 26 Feb 09 blog post "Clarity Amid the Hype" responding to your original post: http://traction.tractionsoftware.com/traction/permalink/Blog977

Description of LiveBlog feature here: http://traction.tractionsoftware.com/traction/permalink/Blog878

Ross Mayfield

Hi Mike --

Good questions, of course. While not important for the broader audience we reached with our launch, quite important and expected for our enterprise customers. Below are some answers and am happy to clarify further.


* Socialtext provides an appliance that can be deployed behind the firewall for a high level of network protection.
* Socialtext Signals & Socialtext Desktop transmissions are encrypted via https when the server uses https.

Access control
* Socialtext Signals and Socialtext Desktop require username/password login to send and view signals.
* Socialtext Signals and Socialtext Desktop already leverage Socialtext's directory integration. Socialtext Signals also leverages existing browser-based Single Sign-on implementation. Socialtext Desktop is not yet supported with Single Sign-on.
* The only users who can see Signals are users who belong to the same network (directory group) as the sender of the signal.
* Individual users can participate in more than one network. The most common example an intranet and one or more extranets. In those cases, the user will be able to choose which network to send a Signal
* Users can send Signals regarding updates to wiki pages. These Signals are transmitted only to users who have permission to view the signaled pages. For example: Alan follows Eugene. Eugene is in several workspaces in common with Alan, and when he makes updates to pages, Alan can see them. However, Eugene is also in workspace that Alan is not authorized to, for example Leadership Team. When Eugene updates a page there, even though I am following him, Alan does not see that update.

Policy management

* Socialtext Signals is enabled on a per-network basis. Appliance administrators can choose to enable or disable Signals for a network. Appliance administrators can view all users per network, add users, and remove users.
* Socialtext is currently working on a feature to enable directory groups to be added to an account. This is expected to be available in Q2.
* Socialtext has fine-grained role-based access. We currently have no known customer use cases to restrict the use of Signals by role, but expect it and is easily implemented with the current architecture.

* All Signals sending actions are logged, archived, and backed up. Users can page through past signals. A robust display of past signals is on the roadmap.

Email and IM integration
* Email and IM integration are on the roadmap.

Oh, and don't forget to try it http://www.socialtext.com/products/desktop.php

Aaron Fulkerson

You forgot the most promising of all these: http://identi.ca/

Nathan T. Freeman

Not to take away from SocialText's implementations, but honestly, I find the concerns over micro-blogging to be underwhelming. It's pretty trivial to get this stuff right. We implemented a robust micro-blogging application on the Lotus Domino platform in about two weeks, and incorporated it with the Bleedyellow.com public social site in literally a day.

Securing to a directory and securing the server should be second-nature in modern web apps. Role-based security should be inherent in any design, whether specifically spec'ed or not. (e.g: in our solution, a user can designate all direct responses to be held private and not visible in the public stream.) These should be natural expectations, not afterthoughts.

Timothy Young


We are frequently asked about data security and administrator controls, so these questions are important to answer. Because Socialcast is delivered via SaaS, we've taken many steps to ensure that our clients have an agile, enterprise-ready tool that can live outside of the firewall. Below I address the topics that you mention in your post.

- We take service availability, integrity, and confidentiality very seriously. Our application and data center network environments are designed to deter, detect, and deny unauthorized access. We have been providing software as a service to enterprise clients for almost four years now in a variety of sectors including government, entertainment, retail, and media.
- Data traffic between clients and Socialcast servers are encrypted using Secure Socket Layer (SSL). Security monitoring at our network, hardware, and application level are implemented and constantly maintained by our network operations and security team.

Access Control
- In order to access and use the Socialcast service, each user needs to provide valid email and password credentials.
- All user activity is only accessible to other users from the same organization. Socialcast is a tool that is private to each company, all communication is between employees.

- All application usage by users are logged, archived, and backed up (including secure remote backup).
- Users have access to the entire history of available messages either via searching or by paging through the history of activity.
- Administrators have the ability to block and hide content that may deem inappropriate.
- If a user chooses to delete content, it is simply a soft delete, as the original is still logged and stored but it is removed from view.
- Clients can choose to request to download all of their content at any time.

Policy Management
- Administrators have full control over which users have access to the system. They initially set up and invite the users, and they have the ability to add new users, edit existing users, and terminate access for users.
- Administrators also have control over which external services and features their users are able to import and access.
- Further directory integration and granular user access is scheduled to be rolled out onto the platform in Q2. At the same time, many of our clients have unique needs depending on their sector. For example, 90% of employees that work at some of our retail clients do not have a corporate email account and don’t use directory integration. Socialcast allows these clients to reduce the anonymity of these workers in a secure, transparent environment utilizing SaaS and mobile access to our software platform. For the first time, our clients are gaining direct communication access to front-line employees.

Email/IM integration
- Socialcast's Google Gadget can be integrated into Gmail, iGoogle, or Lotus Notes 8.
(Note: A large number of our customers use Google Apps)
- Jabber integration allows users to interact with Socialcast via IM. Additional IM integrations are coming to Socialcast in Q2.
- Users can also choose to use Twitter to update their status inside Socialcast.
- Many new integrations for email and IM clients are coming in Q2 and Q3.
- For more on our integrations, including our bookmarklet: http://socialcast.com/blog/introducing-the-gmail-plugin-jabber-integration-and-the-socialcast-bookmarklet/

The comments to this entry are closed.

Become a Fan

Twitter Updates

    follow me on Twitter