JustSignal – Turn down the noise and just get the signal.


On Friday, November 21st cosinity released JustSignal – a combined FriendFeed and Twitter application that allows you to turn down the noise and focus in on just those topics or users you find most interesting.

As much as I love Twitter and FriendFeed, they can become a giant distraction. Too much noise, not enough signal. JustSignal is the solution. It allows you to get your entire home feed from FriendFeed and near real-time “Track” from Twitter – all in one user interface. JustSignal’s filtering solution allows you to only receive the information you care most about – in real-time.


While that alone is a powerful solution for the individual user… JustSignal delivers so much more.

JustSignal Brand Monitor tracks your brand across Twitter and FriendFeed – allowing you to monitor what is said about your brand – and react in real time. Our robust solution queues Tweets, FriendFeed Posts, Comments and Likes that refer to your brand. Anyone in your company can log in and respond to those Social Media brand messages as they happen.

JustSignal Brand Monitor also archives everything said about your company – allowing you to analyze the data and determine what the perception is and how it is trending.

This combination of real-time monitoring and response, and historical data analysis is transformative for your company. Stop sending out surveys and start listening to your customers, prospects and influencers.

You can contact me directly for more information.

Micro-Messaging – Data Interchange Standards and Track

I’ve been hard at work over the past week. Having your own company which you are attempting to bootstrap in this economy and sponsoring an academic project with ASU Polytechnic and – in my spare time – working on the challenges of real-time information discovery and participation is exhausting. Never-mind the two children under 6.

I’ve listened to what everyone has had to say regarding the “fire-hose” – or as I tend to refer to it – the question of trackable scope. Karoli took the time to write a very persuasive and passionate post – which you can read here. While we still may not agree weather or not the “fire-hose” is required to make track – I think we understand each other’s point of view. We agree on what is important – if not in which order and why. That is enough for me.

Apparently I was mentioned on the Gillmor Gang on 11/11/2008 – I’ve included the podcast below:

PodCast courtesy of The Gillmor Gang

icon for podpress Standard Podcast [60:12m] Download (746)

The discussion turns to track for the last half or so of the hour. After sitting with my latte this morning and listening (to some parts more than once) I believe I have a clearer understanding of Steve Gillmor’s perspective on the issue.

I completely agree with Steve that establishing a base mechanism for data interchange between real-time/near real-time social media services is going to be critical to the ultimate value delivered. As I’ve discussed on identi.ca we need a real-time data “bus” which moves data in real time from publishers to subscribers. Much the same way an electrical bus moves electricity from generators to consumers. At some point that bus – when widely adopted – will become a standard.

I’ll be posting more about the bus early next week.

I believe – and I am quite certain history bears this out – that standards develop because they benefit the services that implement them. In most cases this is because the interchange of data in some structured way is required to unlock the full value of a particular service or solution. We’ve seen this evolution in the past – email is an excellent example. Prior to SMTP every major producer of email systems had a “standard” for routing email between users. SMTP became dominant because it became more valuable to have email that could be exchanged with anyone than to have email without that capability. As a matter of fact it became a deal breaker if you couldn’t send email to anyone.

A counter example can be found in the world of Instant Messaging. After nearly 10 years there is no dominant standard. Each network implements it’s own standard and perhaps bridges messages to other standards. AIM uses OSCAR, GTalk uses XMPP, MSN uses SIP/SIMPLE. You want them all – you need a clever developer who creates a client that can talk to all 3.

There are many reasons that these standards either emerge or fail to emerge. But I’m fairly certain that it has rarely been the case that the standard was implemented because a small, vocal community of users insisted on it. I am very certain that the majority of standards become dominant is because there is a business imperative which makes using a standard more valuable than not.

Call me cynical – but that is how the world works. The question isn’t should there be a widely implemented standard for real-time micro-messaging, the question is what is the win-win? What is the business imperative that will drive widespread adoption? Specifically – how does it benefit Twitter to publish everything to the real-time messaging bus?

My contention is – as I’ve said before:

When compelling and broadly adopted services exist, which demand real-time un-scoped access to multiple underlying services, the individual services will have no choice but to “open their kimono” or face massive user defection.

The key part of that statement is “broadly adopted services exist“. My opinion is that we have to focus on the value proposition. What are the problems being solved and why are the valuable to users?

There are many – and some can be solved today (and as Karoli knows – some that can’t) – without the fire-hose. If I did not believe that to be true I wouldn’t be attempting to solve them. Will they be imperfect? Yes – but the goal isn’t perfection on day one – it is making a situation incrementally better by solving the important problems facing the user.

FriendFeed offers an interesting case – since they base their business model on being an aggregator. And, at least in theory, aggregation is one way to establish a real-time messaging bus and standard. It, however, requires not a network of peers but a single massive aggregator serving as the gateway/hub for access to information.

What I know – with complete certainty – is that the marketplace has ways of working these types of issues out. There will be a winner (or winners). They may or may not be the best technical solution. The real-time micro-messaging bus will be created to support the solutions that gain traction in the market. The solutions will not constrain themselves to 140 characters or any other standard which impedes the ability to solve important problems.

In short – until we hash out the types of services and how they deliver value AND the business imperative which drives a broadly implemented standard… there will be no standard (beyond paper standards).

So I’m going back to work creating value and solving important problems using the power of real-time (or near real-time) information discovery and participation… you in?

The evolution of FFStream and the Great Track Debate

ff-filtered-twitter.pngAs those of you who follow me on twitter or friendfeed know FFStream – which I began discussing in this post – has evolved into FF-Filtered. The changes are not dramatic, but they are significant.

FF-Filtered is now focused on providing “your friendfeed – filtered” – and as that implies what it does is filter your friendfeed (home feed to be specific) by a list of keywords. If these keywords match the post title, comment, or user you receive the update in real time – in the browser or via IM, including GTalk, Jabber, AIM and Yahoo.

It isn’t track – as I’ve been repeatedly and vehemently told by the “community” over the last 5 days – more on that later.

Additionally – for the mobility set – we’ve added like, comment, post and filter updates via a mobile web page. If you click on the link in the IM from a mobile platform you get the following mobile web page:


I’ve got a few more tricks up my sleeve – so look for more changes this week including a name change.

Now for the second half of the post… I’m going to talk about Track again… so sharpen your knives (or tongues) and get ready to revel in your abject disdain for my refusal to “go along” or shut up.

Let me say one thing first – if you want to attack my positions and opinions go for it. If you are here to attack my motives or me personally – GO AWAY NOW.

The last 5 days has been very illuminating for me – both in terms of the fervor of the “track community” and in terms of their point of view – which at times verges on dogma.

Let me attempt to “play back” what I’ve heard and then explain – as clearly as possible given my limited skills – my point of view.

Track – by the definition of the “track community” as led today by Steve Gillmor of Gillmor Gang/News Gang Live, is defined by the “fire-hose”. This fire-hose is the complete unabridged stream of posts occurring on any social media site. In the case of Twitter, this is the entire public timeline published in real time.

This is an important distinction – because it states that “track” can not be achieved without the “fire-hose”. More on this latter.

The second component of “track” is the ability to keyword filter the real time stream and deliver the filtered content in real (or near real) time.

The third component of “track” is the ability to insert posts into the public timeline from the same user interface you are viewing the stream in.

Those four things collectively comprise the “holy grail” of track.

I’m sure you will all let me know exactly how wrong I am… but I think those four capture the broad brushstrokes. Ok?

Before I attempt to explain my point of view – let me clarify one point. Regardless of my agreement or disagreement with the track community on any given point, there is one thing we vehemently agree on:

There is massive value in the ability to discover and participate in the social media stream in real (or near) real time. Our objective where that is concerned is the same.

When I consider track – I consider it in terms of the problems it attempts to solve. To me, track is an attempt to solve 2 very important problems:

  1. Real-Time Information Discovery
  2. Real-Time Participation

Any solution which solves those two problems would – by my definition – fall within the scope of a “track” service.

Now let me explain why (take a deep breath… you can throw something at me later). Where I differ with the “track community” on this issue is on the scope of the track-able data not what happens after the “track service” receives it. As importantly I fundamentally agree that the wider the scope of the data being tracked the more effective the track solution will be.

But, consider this – not every user wants to track the entire social media universe. To the contrary – most IMHO simply want to track their friends, family, co-workers, brand, market makers, influencers, power users, etc.

For those users a limited scope is a good thing. Beyond consideration of the scope of the data being tracked this service solves the exact same problems.

  1. Real-Time Information Discovery
  2. Real-Time Participation

So apply the duck test. It walks like a duck… it quacks like a duck… why isn’t it a duck?

It is my opinion – and you can feel free to take issue with it – that the track communities’ obsession with the “fire-hose” has actually retarded the growth of alternative track services. The obsession with scope has prevented the creation of useful (if limited by their limited trackable data) solutions under the banner of track – and that is a shame.

Every developer that seeks to solve the two problems should be embraced, encouraged and supported.

The real battle here is one of leverage. And the way to get the social media services to both open up their data and participate in the creation of a standard for doing so is to create a win-win. I believe track services that are useful and solve real problems (e.g., real-time brand monitoring) can and will provide the leverage that causes the change the community has been seeking.

If Twitter wants to pretend they ARE the social media universe – let them. It is abundantly clear from the success of friendfeed that no single service is or will be the social media universe – any service that ignores this will fail.

When compelling and broadly adopted services exist, which demand real-time un-scoped access to multiple underlying services, the individual services will have no choice but to “open their kimono” or face massive user defection.

So stop complaining about the lack of a “fire-hose” and figure out what those services are, who needs them the most, and how to drive that value to as many users as fast as possible. If you do that – you’ll get what you want… not today, not even tomorrow… but relatively soon.

I had intended to discuss standards, what I believe the high level components of an open track environment might look like, and why friendfeed is in the best position to lead standard development… but this has already gotten too long. I’ll set those subjects aside for another day.

If you’ve disagreed with everything else I’ve said – please remember – I share your goal. I’m not saying the outcome you seek isn’t valuable – I am just proposing a different course of action. I hope I’ve done so respectfully and without denigrating anyone or their point of view.

XMPP, Track and the Social Media Command Line

Last Friday I created a FriendFeed Real-Time bridge to XMPP. Over the weekend I’ve had several people receiving their home feed in real time over XMPP (GTalk to be specific). I also wrote a post about what I had done and what I intend to do with this going forward.

One thing I heard from the initial testers was the desire to “make it work like Track”. Consequently – I’ve spent quite a few mental cycles this weekend thinking about Track (as deployed by Twitter) and how that might work for FriendFeed Streams.

There are three basic components of Track

  1. The ability to track keywords (topics) and receive any tweets containing those keywords.
  2. The ability to post a new tweet.
  3. All interaction happens via IM (XMPP to be specific).

As I thought about these three basic components – and how they might be implemented for FriendFeed Streams I quickly realized that Twitter and FriendFeed are very different – and those differences have a huge impact on “Track” for FriendFeed Streams.

Let’s first consider the nature of Twitter.

Twitter is a stream of stateless tweets. Each tweet is an independent entity – bearing no relation to any other tweet in the timeline. Tweets only have relationships to the user that sent the tweet and, optionally, the user the tweet was directed at – via a @ reply. However, even those @ replies are simply stateless tweets – existing as an independent entity in the timeline.

It is that fundamental nature of Twitter that makes Track interesting – and to a certain extent possible. Since all tweets exist as stateless peer entities in a universal timeline – Twitter essentially creates a stateless stream of tweets. Track works by scanning and filtering this stream and injecting tweets into this stream.

Now let’s consider the nature of FriendFeed.

FriendFeed is a social media aggregator. It contains posts created organically (via the create post button in the FriendFeed interface) or via any number of aggregation channels (blogs, RSS Feeds, Twitter, Disqus, Flickr, etc). Each of these posts exist as state-full peer entities on the timeline.

FriendFeed posts are state-full because they exist as containers. They contain a separate groups of entities – Likes and Comments. Likes and Comments change change the state of the Post – and by doing so change the posts place in the timeline. For Example – If I comment on a 4 day old post it will move to the top of the timeline.

The Post as a container creates a conversation. This concept – the conversation – is totally foreign to Twitter.

FriendFeed, then, creates a state-full stream of conversations. Conversations appear in the stream one or more times – each time they are created or added to via a Like or Comment.

Now that we understand how Twitter and FriendFeed are similar and differ we can re-visit Track.

  1. The ability to track keywords (topics) and receive any tweets containing those keywords.
  2. The ability to post a new tweet.
  3. All interaction happens via IM (XMPP to be specific).

What is clear is that component #1 above is still viable and makes sense. It was the fundamental reason I chose to build FFStream. It still solves the problem of information discovery.

What poses a significant challenge is #2. I refer to this as the problem of participation. This is due to the state-fullness of the FriendFeed Post (or conversation). Where FriendFeed is concerned participation is a relative exercise – you can post a new conversation OR you can participate in an existing conversation. It is the relative nature of participation (relative to an existing conversation) that makes participation via IM so problematic.

This schism is completely analogous to the schism between the command line and the graphical user interface. As a matter of fact, an IM/XMPP interface for Social Media streams is simply a Social Media Command Line. You enter commands – often obscure, opaque and archaic commands – and thereby control the behavior of the application. And this model works… until the interaction model becomes so complex that a command line interface becomes impractical.

When the goal is to filter a stateless stream of data (ala grep) and insert data into that stateless stream – a command line works. However, when the stream becomes state-full – and contains entity relationships (i.e., conversations) filtering the stream is sensible – but the complexity of the required command line interface to inject data into the right entity in the stream makes the proposition a fools errand.

In short – FFStream is an ideal information discovery mechanism – far more powerful than Track because the stream is an aggregation of content and because the stream is a stream of conversations. It is not, however, a usable interface (i.e., command line) for participation in Social Media.

So the goal of FFStream will be to enable information discovery and encourage participation by providing a reference to the conversation. That reference will open a browser window with an appropriate interface (i.e., graphical user interface) for the participation in the conversation.

I know some will find this (to put it mildly) lacking. I know some will declare that I don’t get it. But there is a reason people vastly prefer the ease of use provided by a graphical user interface over the command line. If you are one of those who believe I’ve missed the point – please consider the command line vs. graphical user interface schism and how it relates to this conversation before declaring my ignorance.

FriendFeed to XMPP Bridge – Why, how and the plan.

Yesterday I took about and hour and created a FriendFeed to XMPP bridge. The advantage I had was that I was already running a XMPP server and had a working XMPP bot – these existed for my own personal use as well as for cosinity.


Primarily this is about information discovery. The ability to participate is challenging (see below) as FriendFeed is an aggregator.

As I said in an earlier post – I believe FriendFeed’s Real-Time functionality is missing two important capabilities.

  1. The ability to filter the feed by keyword(s).
  2. The ability to get real-time for the public timeline.

While there is nothing I can do about access to the public timeline – I can, via the API, create the ability to filter a feed by keyword(s).

Additionally, XMPP is a clean way to distribute the information – so why not have it published via XMPP?


Since FriendFeed had not released any sample code or a Python/PHP library for real-time yet I had to modify the existing libraries to support real time. This turned out to be trivial – I simply made a new {fetch_RT} function which looks much like the existing {fetch} function. With that complete I could simply use this modified PHP library to grab a user’s real-time stream.

As I mentioned earlier I already had an XMPP server running and had created a bot for other reasons. I simply re-used that bot and the over the network XML API defined by the bot to send the FriendFeed stream out as XMPP messages.

There are several important things to note here about the architecture:

  1. De-Coupling the FriendFeed real-time processes from the XMPP bot processes is a very efficient model.
  2. Keeping the XMPP stream bot a “dumb pipe” (i.e., outbound message streaming only) is also very efficient.
    1. Clicking on the link at the front of the XMPP message opens the FriendFeed “conversation” in a browser.
  3. Since FriendFeed is an aggregator, participation via XMPP will be very problematic.
    1. For Example: If the message is a tweet do you want to reply with a tweet – or comment on the tweet in FriendFeed’s conversation?
    2. The bot would have to track a large number of variables for each message in order to properly distribute your comment/message/etc.
    3. This overhead would directly affect the ability of the service to scale.
  4. The scope of the feed (e.g., the apple room or My Home feed or my “the cool people list”) and the keywords for which you’d like an XMPP notification would be configured via a web interface.
    1. This – again – goes directly to keeping the service as scalable as possible.
    2. The down side is you can’t change scope or keywords via XMPP messages.
    3. There is the possibility of creating a separate “ffstreamcontrol” bot which would take these commands. It remains to seen if this is really required or a nice to have.
  5. Since the stream bot acts as a dumb pipe – it can rapidly scale by running multiple instances with the same UID and a different resource string. You won’t know (or care) which bot you are connected to – they all look the same. If one dies – the FriendFeed real-time processes will be programed to try the next one… and the next one… etc.
    1. Again – this is a very efficient model.
    2. Will provide high levels of redundancy
  6. The bots will all connect to a dedicated XMPP server – the XMPP messages will then be distributed via XMPP federation.
    1. XMPP federation protocols are very efficient.

The Plan:

My current plan is to build something similar to what you see below. The user will create XMPP streams based on scope (i.e., FriendFeed scope – For Example: the Debates 2008 room) and keyword(s). The user will be allowed multiple XMPP streams. All XMPP stream creation, deletion and modification will be done via a web interface.

The XMPP bot(s) will serve as a dumb pipe for content delivery.

Participation is problematic – and as such will be set aside for now. User’s can still participate by clicking on the link in the XMPP message – this link will open the FriendFeed conversation (here is one for example). This will allow the user to participate, subscribe to the user’s involved in the conversation, etc.


Please feel free to comment – let me know if you think this is headed in the right direction.
NOTE: This was written very quickly based on a prototype made yesterday. Please excuse any less than completely thought through concepts… it is a work in progress.

Social Media is about Aggregation – Not Publishing/Networks

I’ve been using FriendFeed for several months now. As a matter of fact, with the addition of real-time FriendFeed is now my primary Social Media interface. Why? Because the critical attribute which makes Social Media useful (yep, I’m banging on the adding value drum again) is aggregation, not publishing or networks. Publishing and networks are required – but they quickly become commoditized. An example – Twitter gets popular and up pops Laconica, Yammer, OpenMicroBlogging, identi.ca, …

Social Networks are no different. How many social networks do you have to check every day to keep up? What are the odds that all of your friends (or co-workers) are on the same network?

Social Bookmarking – no different. Friends across multiple networks.

The result is that you – in order to actually use Social Media in a useful way (information discovery) – have to jump through hoop after hoop after hoop to attempt to discover anything.

That is why aggregation is so powerful – and why I was never all that impressed with Twitter’s Track feature (which caused so much angst when turned off). Track was only interesting if you assume all the relevant information was/is on Twitter. In other words – the network drives value, not the information – and that completely misses the point.

FriendFeed gets it. The value is in the information – and providing aggregation of that information and useful tools to locate, consume and re-share that information is the key to providing value. With the introduction of Real-Time FriendFeed completely changes the real-time information discovery game.

FriendFeed allows a user to aggregate all the places they view, track, share, and create information. When you follow a person you follow all of their information – regardless of what network it is generated on. That – to me – is the point of a “follow” – I want to know what you find interesting, because if you find it interesting I might too. I really don’t care how you share the information… and I certainly don’t want to follow you around the inter-webs joining every cool new network to get access to the information you view, track, share, and create. When you join a new service (a.k.a., network) you add it to FriendFeed and viola! I can see what you share there as well…

The introduction of real-time (while admittedly imperfect) is a sea change for real-time information discovery. It transforms it from a network (service) based activity (e.g., I can see what happens on Facebook in real-time in Facebook – I can see what happens in Twitter real-time in Twitter – etc) to person based activity – I see, in real-time – what you share, without the limitations of network/service.

The only thing missing from FriendFeed today is aggregation based on topic. That is, the ability to specify a group (e.g., everyone, my friends, a room, etc) and a topic search (e.g., debate, google, pretty cat pictures, etc) and see only information which satisfies both criteria.

At the end of the day – the aggregation of information a person shares, and the ability of others to “follow” that information stream is Social Media. The social graph is interesting, but it doesn’t add value to people’s lives in any meaningful way (granted it creates a highly valuable advertising platform). Efficient sharing of information and information discovery does. Aggregation is the secret sauce.