How to Use Twitter and Asterisk for Call Notification

200903101607.jpg I’m still old school enough to think that voice conversations still matter. So I call people, and they call me. When I’m out and about I like to know who has called me back at my office (no I don’t want my cell to ring EVERY TIME someone calls my home number, my cosinity number or my home office number). That way I can see who it is and give them a ring right back if it was really something we needed to discus.

200903101608.jpgI’ve had a number of solutions in place for this over the last 2 years or so. From IM messages to SMS messages. The problem with IM is the lack of great notification on mobile devices. The problem with SMS is paying 2-5 cents each.

This led me to think – maybe using Twitter and @ messages or DM’s was a better answer.

Before I give you the code let me first explain how this works. If you are not comfortable with Asterisk, Asterisk AGI, and customizing extensions.conf you should probably stop here.

Continue reading “How to Use Twitter and Asterisk for Call Notification”

What is Interesting to me… right now.

One of my favorite things about social media is getting to know people not just by what they say, but also by following along to see what interests them. The things that interest you make you interesting to me.

Some people will tell you to grow your social graph (people you follow/friend/subscribe to) because if you do that you get better signals about what matters. And I guess if you are Robert Scoble and your job is to identify macro trends there is some merit to that argument. But…

The vast majority of us are not Scoble. We are building relationships, not a macro trend radar. If I want a macro trend radar… I can get that by following Scoble.

So for the rest of us context matters. We need to locate those we find interesting – and what better way to do that than by following conversations around particular topics, subjects or events (i.e., context). Because we already find the context interesting there is a much higher likely-hood that we will find people discussing that context interesting.

Call it the cocktail party principle – you engage in the conversations (i.e., context) that interest you. Sometimes you meet someone new in that conversation (context) and continue the relationship outside the party/conversation (context). This is how relationships work in the real world. Why should it be different online?

What you wouldn’t do is walk in to a cocktail party and run from conversation to conversation listening for the length of one comment and passing out relationship invitations. Why – because it would be weird. But this is exactly how many people approach Social Media and building their social graph.

This simple notion – that context matters and is the best way to build your social graph – is exactly why I’m so excited about JustSignal and the problems we are solving. As a concrete example I’m adding a JustSignal widget to this post and the About Page on my blog. It will constantly track everything said on Twitter about the topics/subjects/events I’m interested in right now. The content will change as my interests change… because I’ll update the context.

You want to know what is interesting to me… right now – check out the widget.

http://justsignal.com/widgets/brianroyblog/widget.html

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:

IMG_0001.PNG

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.

Are you looking to hit a 5 run homer?

120px-Chase_Utley_Home_Run.jpg I love a good baseball metaphor. There is nothing better than using the lens of baseball to make a point simple, clear and biting.

So let me tell you what I’ve been thinking today. You can’t hit a 5 run homer – it just can’t be done. Doesn’t matter how smart you are; doesn’t matter how talented you are; doesn’t matter how many twitter friends you’ve got.

I’m an optimist – some would say annoyingly so. I believe the best developers among us can code just about anything we want them to. But that isn’t really the point – is it? The point should be bringing the greatest value to the largest number of people possible.

Often, however, you are faced with a dilemma. Your “power users” want functionality that no one but a power user will ever be able to (or more importantly willing to) use. In short – they want you to hit a 5 run homer.

Why is that a 5 run homer? Because you can’t exert 80% of your effort satisfying 5% of the target market. You can’t convert the masses by catering to the few.

So you make a choice – you swing for the fences, or you shorten up and take the ball back up the middle. But no matter how hard you swing… you aren’t driving in 5 runs with one swing.

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.

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.