Not only is it shorter, the new name is more literally communicative of what the service does. Click on it and you will J.mp [jump] to a new link. It's nice and literal like the old classic tinyURL, though most people don't know what URLs are. J.mp is so friendly it makes Bit.ly look like a way to catch a bit-delivered virus. J.mp might be the best URL shortener name yet. How do those Bit.ly guys do it?

Such is the nature of the super-fast, perhaps Real Time, social web that Bit.ly is a big part of.

You can visit J.mp and get all the same bookmarklets and tools for the new URL that you've got for Bit.ly (the "sidebar" tool is excellent). We expect that leading Twitter clients like Tweetdeck and Seesmic will likely add J.mp support soon. We wonder if Twitter.com will stop transforming long links into Bit.ly links automatically (a deal that was announced this Spring) and will use J.mp instead.

In case you're curious - .mp comes from the Mariana Islands, which are just South of Japan.

There are a number of efforts in the market to create community-owned URL shorteners, with features serving developers first before the interests of private owners. Most notable among them so far is Tr.im. It would be a shame if enthusiasm for such projects was lost over one fewer letter being taken up by J.mp. That said, this new URL J.mp will likely be just the latest development from a company that's building itself into a strong market leader.

After weeks of controversy concerning a possible closure of the service, URL shortener Tr.im just announced that it's open sourcing its code, handing ownership of its domain name over to a community nonprofit organization and making clickthrough data freely available from now on, in real time. Founder Eric Woodward will spin the project out from his core company Nambu, will cover operational costs personally and will work with anyone who wants to help make Tr.im a community-owned alternative to what Woodward says is a data-hoarding monopoly in Bit.ly and Twitter.

Talk about turning lemons into lemonade. The new Tr.im may be the most exciting thing to happen in URL shortening since now market leader Bit.ly itself launched.

URL shortening is of course important primarily because of Twitter, where links have to be shortened in order to save characters against the limit of 140 per message. This May Twitter chose to make Bit.ly its default URL shortener, replacing TinyURL. Bit.ly's marketshare in the URL shortening world became a near instant monopoly.

This is important because these URL shorteners have all kinds of data about which links on Twitter and elsewhere are getting the most click-throughs. Bit.ly is interesting because they've been building all kinds of value ads on top of that data - real time analytics, semantic analysis of the linked-to pages and more. Many people believe that Bit.ly could become one of the hottest sources of news discovery on the web, challenging now slow-looking sites like Digg.

Woodward argues that the relationship between Twitter and Bit.ly has made the URL shortening business pointless for everyone else. It was taking up a lot of his time, causing him headaches and he was feeling pressure to dedicate more time to his company's core product, the Nambu desktop client.

Last month Woodward announced he would be closing Tr.im down and a substantial number of people freaked out. The biggest concern was that all the short links that had been created would now be broken. Some developers complained that they had invested time into building services that utilized Tr.im's analytics. In response to the uproar, Woodward changed his mind. He said he'd keep the service up for some period of time, he tried to find a seller, but today he's announcing a permanent change to the nature of the product.

Woodward argues that Bit.ly and Twitter will not expose raw aggregate clickthrough data to just anyone to develop on top of. That's what the new community-owned Tr.im is going to do. Working with activity data hub provider Gnip, Tr.im will make aggregate anonymized data available in real time, for free. That means that any random developer can build something exciting on top of that stream of data, not just the selected partners of Twitter and Bit.ly.

Woodward says that if the community can take Tr.im to 5 or 10% marketshare, then it should have a good sample of the data Bit.ly is seeing in the rest of the market. Opening that data to developers in real time would then become more valuable than anything Tr.im can offer in aggregate today.

Update: We spoke with Bit.ly's John Borthwick and this is what he had to say: "I think this is great, it means there will be a future for tr.im and having more services out there is a really good thing. [Tr.im's Eric Woodward] is short on the facts though and the facts are if you look at the clicks and encodes on bit.ly in a day, 15 million yesterday for example, 60% of them are from Twitter, less than 10% come from twitter.com. It's about product iteration and adding features. [That's why Bit.ly is so popular, Borthwick argues.] Eric made a choice and bit.ly has made a different choice." Borthwick also emphasized that Bit.ly has to invest substantial resources into scaling, something that the Tr.im community will need to take very seriously if it is to grow.

The prospect of a distributed, interoperable, self-hosted network of publishing, reading and discussion tools is nothing new - but the idea is gaining a lot more support as more people react to recent news like FriendFeed's sale to Facebook, Tr.im's up and down and Twitter's denial of service attacks. The tide may not be turning, but there's sure to be some new waves of innovation that come out of this period of frustration.

One of the analogies people are drawing is that we need a WordPress.org-type version of Twitter to put on our own servers as an alternative to the Twitter-hosted version that exists now like WordPress hosts blogs on WordPress.com.

Why do we need self-hosted lifestreaming, microblogging or social networks though when we've already got the ability to host our own blogs, own our own data there and set our own rules? Simply because these technologies fill different needs. Blogs are good for longer-form, author-centric communication. Quick, very social conversations around objects like links or media items can best be had in other settings. Thus the interest many people have in both writing a blog and sharing and discussing items on sites like Facebook (social networks), Twitter (microblogging) or FriendFeed (activity streams).

Twitter's Down Time

Twitter went down again today, possibly for the second time in two weeks because of a Distributed Denial of Service attack. A swarm of zombified computers, distributed all around the world, is hitting Twitter's centralized infrastructure over and over again until it can't stay up.

If we all had a little piece of our microblogging network on our own servers and they spoke to each other, that couldn't happen.

We'd also own our own data, our archives, our interface design and more. It would be like publishing little messages... like grown ups.

The two systems could co-exist, a hosted service has its advantages and many people wouldn't use anything else. Realistically, no one is going to build something too much like Twitter if they could build a distributed version of something like FriendFeed or Facebook.

Facebook Eats FriendFeed

Social activity stream discussion network FriendFeed announced that it was selling itself to Facebook yesterday and many of its users were very upset. The acquisition is likely to change Facebook in interesting ways (FriendFeed's creators were the inventors of GMail and Google Maps) but FriendFeed itself was important to its users.

The feeling of betrayal that comes from a transaction like this makes it hard to trust a hosted social networking company again.

Fortunately, there's a long and growing list of ways to put all of your activity around the web in one place on your own website. When will those tools begin to include subscription to other peoples' activity feeds and posting comments from your social lifestream viewing page that will appear back out on everyone else's?

That's a big part of the vision articulated by Anil Dash in his recent essay about what he calls The Push Button Web. It's related as well to RSS pioneer Dave Winer's recent promotion of a part of RSS called RSS Cloud. Developers are actively building on RSS Cloud and a similar protocol with the humorous name PubSubHubbub.

That's also part of the vision of the Distributed Social Networking Project (DiSo). We haven't heard much lately from this project, probably because its founders are busy building the technical standards that will allow the information to flow from one social network to another.

Tr.im Your Expectations

This weekend link shortening service Tr.im announced that it was shutting its doors. It was too expensive and hopeless to run the service without the funding, hype and official blessing from Twitter that competitor Bit.ly had won.

Big deal, right? It turns out that people freaked out. Tr.im's biggest users were developers who were hip to the opportunities to do interesting things with the service. They had built on it and they felt a lot of frustration when they heard the news.

A dead URL shortener means dead links, broken content, lost data.

There are a number of different solutions being explored in response to this part of the problem. Developer Brian Hendrickson has already begun working on a service called rp.ly, a "community-owned URL shortener" based on cloning the Tr.im API.

There will, no doubt, be any number of other efforts that rise from the ashes of the trust that's been burnt over the last week or more.

Are all of these circumstances and conversations going to push the social web over the edge, toward a more distributed and less centralized model? Probably not in a big way, immediately, but we're pretty sure that some interesting innovation is going to come out of this. Dissatisfied engineers, working on a problem that a lot of people are interested in, can produce some fun and important work.

Some will hold out for Google Wave, the forthcoming open-source hyper communication head shift. We're hearing that Wave may be too complicated, though, and we suspect that the most important innovations will come from coders building the kind of software that many, many people can hack on and help evolve.

In the future many of us may be microblogging, lifestreaming and social networking over technology that we control and can customize ourselves, instead of inside the owned networks of major companies like Facebook or Google. Those companies are seeking to branch out as well, trying to colonize the web (in the words of Forrester's Jeremiah Owyang) with tools like Facebook Connect.

But many of us may decide not to trust them anymore, and to use the tools that are becoming available to build and host our own systems of communication. People who control their own systems of communication can innovate on them outside the boundaries of the financial interests of big communication companies and we can all benefit from those innovations.

This summer is an important period in answering those questions.

For publishers the service looks very cool, it includes features we haven't seen anywhere else and offers access to the huge Stumble audience.

• Real time analytics showing how many people click through your links, how many came via StumbleUpon in particular and who the most prolific "reTweeters" have been.


• Easy publishing to Twitter and Facebook, including the ability to schedule those links and messages to be pushed out at a particular time.


• "Suggested posting time" metrics, based on historical data concerning when people are most likely to click through your links.


• A handy bookmarklet that makes submission of links quick and easy.

It's interesting to note that Stumble's business model is based on publishers paying 5 cents per visitor to have pages inserted into relevant Stumble streams already. Now publishers are being encouraged not only to put their pages into Stumble for free, but are also aggressively prompted to write their own reviews of pages.

What's Not So Super

Other possible critiques of Su.pr include that the framed pages aren't pretty in mobile displays (the frame is clunky and the obscured destination URL is a bummer) and there hasn't been a Su.pr API announced, something that competitors like Bit.ly, Cli.gs and Tr.im all offer.

Stumble says they are using the right kind of redirect to keep search juice on the page that's being linked to, (Update: SearchEngineLand's Danny Sullivan says this is not true) but we're not sure what Su.pr will do to third party analytics services like Google's. We also question whether the "clicks" are really clicks on Su.pr; just like all URL shorteners have happen, Su.pr links are sometimes "opened" by browser extensions that peak at the full URL without readers actually clicking on them. For example, the service reported 5 clickthroughs on one of our links just 5 seconds after we sent it to Twitter. That's possible but doesn't seem terribly likely. It's a hard problem to solve and one that is much more important for publishers with tech-savvy browser extension using audiences than it is for the vast majority of the world. In tech publishing, it's not uncommon for other URL shortening services to report 1k clicks when internal analytics have only seen 700, for example.

Su.pr encourages publishers throughout its interface to promote their own content, a reality of the web publishing world that brings with it some ethical questions. The company has always flirted with these questions by serving up paid content pages inside Stumble streams without disclosing that they were paid for, something that few other widely-loved technology companies could get away with. Mega corp eBay can't be blamed for any of this as Stumble's founders recently bought the company back (which is awesome).

Perhaps the bulk of Stumble-submissions were already coming from publishers though, not from fairies touching web pages with dew-drop-dripping magic wands as we naively hoped.

We're sure Su.pr will be great for StumbleUpon and for publishers, but we'll have to see how good it is for users. Fortunately some self-correction is baked in to StumbleUpon, viewers simply vote down weak content and other people are thus likely to be served that content as they Stumble through the web. The efficacy of that self-correction may be mitigated by a substantial increase in noisy publisher content pushed into the system out of self-interest though. We'll see!

If you would like to try out Su.pr for yourself, you can use the invite code "suprrww."