web 3.0 – Stay N Alive

Category: web 3.0

Kynetx Introduces the Programmable Internet – the Language of the Building Block Web

Posted on by jessestay

Several months ago I talked about a concept I call the Building Block Web.  It’s the next evolution of platforms, with all different types of services able to communicate with each other and work together. Where Web 2.0 is “the Web as a platform”, the Building Block Web is “the Platform as the Platform.”  I talked about the MVC model of the Building Block Web, and how different elements represent different layers of that paradigm.  From Amazon Web Services, to Facebook Graph API, to Twitter API, to even Google App Engine and other cloud-based, API-focused architectures, we’re able to all include our biggest strengths in each others’ applications.  Today, Utah-based Kynetx released its own strength into the Building Block Web and essentially provided what I consider to be the first programming language of this new Platform.

Dr. Phil Windley (or as employees of the company endearingly call him, “Doc”), Kynetx’s CTO and co-founder, described the new “feature” of their event-based language KRL as “A Big, Programmable Event Loop in the Cloud”.  Windley, also a Computer Science Professor at BYU, has taken his deep understanding of language theory and created a new language intended to basically allow all these different building blocks to talk to each other and provide a more relevant experience for users on the web.  He calls it a Purpose-driven ecosystem, one where users go to the web with specific purpose in mind, and the web adapts to help them achieve that purpose.

The new feature (it may as well be called a new revolution, as it is much more than a feature – it could completely change the breadth of what Kynetx can accomplish for companies, developers, and users) enables developers to basically create their own “endpoints”.  These endpoints can be anywhere from Google Calendar, to my own SocialToo API, to your Sprinkler system.  When developers create endpoints, they are essentially, automatically providing an API that developers using Kynetx’ cloud-based platform can tie into and use in their own applications.  So, let’s say for instance I created an endpoint for my sprinkler system (since that’s an example Phil used), which is being installed today.  I could enable you to turn on my back sprinklers, turn on my front sprinklers, and turn them off again.  I could then tell Kynetx’s platform how to do this.

Once Kynetx knows how to turn on and off my sprinklers, I could open that up to other developers using the Kynetx platform, and now someone could easily build a plugin that, whenever you visit Twitter.com and it sees the word “sprinkler” in your stream, it turns on my sprinklers, getting me all wet.  Another endpoint Kynetx itself has provided for developers is one that interacts with Google Calendar.  If you wanted, you could make Kynetx’s endpoint for Google Calendar talk with your endpoint for your sprinkler system, enabling you to schedule your sprinkler system in Google Calendar and have it automatically turn on and off your sprinklers at home based on your Google Calendar schedule.

Or, let’s say you’re Target.com and you want to make your products available to other apps on the Kynetx platform.  If you create a Target.com endpoint, other developers can now tie into it, bringing the option of Target.com into their own applications on the Kynetx platform so your products will now also appear in their apps.  This portable, 2-way, programmable API in the cloud, enables both programmers providing content, and programmers receiving content, to meet in the middle, providing a completely contextual experience for the user.  Basically, developers can both create the API, and consume the API all in the cloud.  The concept is very powerful!

With Kynetx, soon you’ll be able to use one language, one API, to both provide  and consume the services you are providing to your users.  Add a little flag to your app, and soon users will be getting just the experience they desire, with little to do on their part.  Or, perhaps Kynetx will enable users to do this for themselves, providing users the option on Kynetx.com to specify the apps they want to enable as they surf the web.  The possibilities are endless.  Kynetx is making API development really simple with their new API to the Internet!

Have an idea for the Kynetx platform?   What would you create with such an opportunity?

What is Your Core?

Posted on by jessestay

In a typical Lego set, there is a core set of building blocks that make up the core of the object you are building.  My son just got a new Star Wars Tie fighter Lego set.  It relies on a few common objects, such as little flat Legos you might see in other sets, but overall, what you would see in this set would be much different than the core of Legos you would see in, say, a set to build a House, or even my 2 year old’s set of Duplos which builds just very simple objects geared towards people his age.  For a house set you will see more block-like structures.  For a Robot you may see more objects with holes in them, to accommodate for axles and gears.  For a plane you may see more flat structures for things like wings and a skinnier body.  In the end, you’re trying to build one core, unique object that is different than any of the other objects around it.

Too often I think entrepreneurs struggle to find out what their core is.  Social Networks should be ubiquitous.  Real time should be ubiquitous.  Open Standards should be ubiquitous. Search should be ubiquitous.  There are already companies out there that have these things as their core.  They’re the experts.  I think entrepreneurs and developers often get stuck (myself included) in this rut of fixing things the experts are already good at, rather than finding something new and innovative they can take ownership at.

There’s already a T-Shirt out there that says “Twitter destroyed my market segment, and all I got was this lousy T-shirt”.  Well, the reason that occurs is because developers are building core blocks that are already part of the Twitter core.  They are building something, the cockpit, the engine, the wheels, that were already destined to be replaced in the original scheme of things.  We developers like to see, and fix, the big picture – I know because I’m in the same boat (or ship?).  However, I think we need to be thinking bigger.  We need to be thinking about what our core is, not what’s missing from others’ cores.

When we talk about “filling holes”, I think the best position to be in is where others are filling the holes that you create.  You own the core that includes the missing parts.  The propellers of Twitter should be added to your core to make your airplane fly.  The Jet Engines of Facebook should be added to your core project to push it forward.  The wheels of Google should be added to your core project to get it off the ground.  But in the end, you still own the airplane.  You have control of the core.  All the other “cores” get to contribute back to your core to make it better.  Heck, you can even take pieces of your core and add it into the other existing cores to complement their space too – the power is you still own your space that way.

As you build new creations, think to yourself, am I contributing to others’ cores, or am I building the core that other cores can add their parts to and make better?  No one should be building another “social network” project.  No one should be building another “search engine” project.  The focus should be on the innovative creations we create, and how other “social networks” and “search engines” can make us better.  It should not be the other way around.

This is the “core” success story of the Building Block Web.  How are you letting Twitter or Facebook or Google make your core project better?

Twitter Launches Facebook Connect Competitor, @Anywhere

Posted on by jessestay

I’ve long talked about the MVC model of the Building Block web.  Data Repositories like Amazon Simple Storage, Facebook Data Store, Google Data, and others comprise the Model of this new platform.  APIs like the Twitter API, the Facebook server-side APIs, or other REST-type APIs compose the Controllers of this web.  Then you have the View – something pretty much only Facebook and OpenSocial/Google Friend Connect have covered thus far.  The View enables developers to easily integrate and access code from a user’s Client, the web browser.  Today Twitter added their entry to that game, @Anywhere.

@Anywhere strives to provide a solution for a huge weakness in the Twitter API Platform thus far.  It provides an entire Javascript, Client-side platform for developers and website owners to integrate Twitter easily and simply right on top of their website, no server-side code involved.  This is the missing link Twitter has needed to have a truly competitive solution against Facebook’s Connect platform.

Facebook Connect relies on Javascript to provide an immersive experience into the Facebook environment right on top of any website owner’s site.  With a few lines of Javascript, and an HTML-like tag language called XFBML, website owners can pretty much copy and paste pieces of code in place and immediately have access to comments, become a fan boxes, post to their stream, and even more if you know a little Javascript as well.  It’s unclear if Twitter will be releasing an XFBML competitor (I’d love to help Twitter test if this becomes the case – I wrote the book on Facebook’s FBML), but Twitter is clearly going up against Facebook Connect to provide similar type tools, and I think it’s a very smart move.

I mentioned earlier I was excited about the entry of Josh Elman as product manager at Twitter.  I’m unclear if he had anything to do with this, but you can clearly see the Facebook influence in Twitter’s new API.  With not only Josh, but several others from the Facebook team now working at Twitter, you can bet they’ve compared and contrasted how they could obtain some of the millions of Facebook developers out there.  Making it as easy as possible is the smartest way to do this, and Twitter has already signed on several very big players in the Facebook Connect space, Huffington Post and Yahoo, to be launch partners in this effort.

In addition to those, the most significant partner that I think should not be ignored is Amazon.  Amazon, IMO, is the holy grail in Social E-Commerce, and despite not having a Facebook Connect solution, they seem willing to integrate Twitter into their environment.  Why they are choosing Twitter over Facebook is beyond me – maybe they have a Facebook deal in the works as well?

I’m very excited about this new announcement.  Soon, it will be easy for any developer to very seamlessly, in a single, well-understood language (Javascript), integrate Facebook and Twitter all on a single website with little effort.  As a developer, I’m drooling a bit over this.  I can’t wait to start playing with it.

Web 3.0: The Building Block Web

Posted on by jessestay

lego bricksTim O’Reilly is well-known not only for his successful publishing company (which I have written for), but also for his definition of the term, “Web 2.0”, in summary defining the web as a platform, moving from the desktop to the cloud. I’d like to propose we are in the process of taking that one step further, perhaps even moving to our foundations, taking components of that platform, and enabling others to use those components in their own applications. Some talk about the “real-time web” being Web 3.0, or the 2010 Web, but when you look at it “real-time” is just using the web as a platform, making it real-time.  The web still hasn’t really changed in essence to something else beyond the web becoming “the platform”.  The web needs to shift to something else for that to happen. I think that shift is happening in a form I call “the building block web”.

When I think building blocks I think Lego bricks.  Each one has its own unique size and shape, and when you take the basic lego bricks you can add your own, making something unique and powerful.  The web, as a whole, is evolving towards this state.  We see Twitter, with its open platform enabling others to share in ways they were never able to share before in their own applications.  We see Facebook and Facebook Connect enabling businesses to incorporate Facebook activity, relationships, and more right in the bounds of their own brand (Jeremiah Owyang suggested we might call this “farming”).  Recently, we saw Google Wave producing ways for users to collaborate in ways they were never able to before, and embed these in new ways into external environments. We see Facebook implementing Facebook credits amongst various applications and enabling some developers to charge using Facebook credits, Facebook taking a cut along the way.  Each of these “components” is a building block.  They’re each basic foundations, or Lego bricks that have organized the web into components developers can now build new and interesting things with.  The new platform is on top of these foundations, which are built on top of the web, and viewable via a desktop or browser.

Robert Scoble, as he was interviewing me and Louis Gray last week, mentioned he thought Facebook should implement reviews similar to Yelp, and they could then profit from the deals made surrounding those reviews of retail and other physical purchase locations.  It’s a great idea, but I suggested Facebook doesn’t need to do this.  Facebook seems to understand the building block web.  They are providing means for Yelp and others to take what Facebook is good at – building relationships and sharing activities and content with your close friends and family, and incorporate that content and social graph into and out of Yelp’s own environment.  They are even providing for some developers (as mentioned earlier) the ability to integrate their built in credit system.  Facebook provides their own foundations or Lego bricks, provides a means for those people to pay for things, and Facebook takes a cut of every piece of that along the way.  Seems like a much better model than reinventing the wheel if you ask me.  Now imagine if Yelp joined the building block web by providing their own “blocks” giving other apps the power of what Yelp is good at: organizing great reviews around physical purchase locations around the world.

Now look at Google.  Google understands this well.  They are providing Friend Connect, OpenSocial, Android, Wave (on 3 different levels!), and letting Developers decide what to do with them.  Google is adding to this new platform giving developers new building blocks to play with and create cool things with.

This new web is surrounding us as we speak.  Each of the major players is in a race to see who can create the most building blocks for developers and entrepreneurs to incorporate into their own products.  No longer are entrepreneurs focused on building for the web.  They’re focused on building around these building blocks. The building blocks are the platform. This is Web 3.0.  Who will win?

Why Kara Swisher is More Wrong About Wronger

Posted on by jessestay

nails on a chalkboardSlow news day?  Let’s let aside the whole “Web 3.0” vs. “2010 Web” Debate.  They’re all just terms after all, right?  Let’s focus on something a little more important, like the fact that an established journalist like Kara Swisher can’t use correct grammar in her titles.  Let’s look at the definition of “Wronger”:

“One who wrongs someone; One who commits a wrong; Comparative form of wrong: more wrong”

Keep in mind that the only definition of “wronger” provided by Google was that one, by Wiktionary.com, something many would hardly consider a credible dictionary.  However in this case, even their definition states Kara is completely wrong on this matter.

What’s the deal with bloggers, journalists, and marketers feeling it’s okay all-of-the-sudden to relax their use of grammar?  These guys all have editors that check their work, and I wouldn’t hesitate to think they have all had much more English training than I have.  I mean, even Apple’s doing it – what’s with the whole “Funner” theme?  Does that terminology make it sound “more fun”?  To me, it just makes them look stupid.

I hope Kara’s use was just tongue-in-cheek, but let’s stop this practice.  It’s simply wrong.