Mea Vita: Carpe Diem

Twitter is the haiku of the new millennium.

But, there is serious discussion to remove the 140 character limit in tweets.

Removing a tweet's 140 character limit is the equivalent of showing up at a haiku conference and telling everyone to stop using 5-7-5 and, instead, to use 7-5-7 since that would generate more content.

If Twitter removes the limit, what will differentiate it from other platforms, such as Tumblr, Medium, Blogger, etc? Twitter has recently removed this limit in their direct messages and I've already felt the negative effect of this decision.

In Corporate America, we detest e-mail because of its unlimited length. But Twitter's loved because it's short and to the point. The beauty of 140 characters is I always finish reading what I've started. ​It keeps everything short and to the point with the option to link to detailed content.

A few weeks ago, I blogged about the benefits of the 140 character limit in direct messages (DMs). Recently, I had a customer service issue I addressed through DMing. My DM was not read, in detail since it was more than 140 characters. The CSR asked me for information I had previously included in my original DM. At 500 characters, my DM, written like a short e-mail, was too long. It's a fast and noisy world out there – clear and concise communications is appreciated more than we realize. 

Unique

Twitter is unique. It's both a micro-blogging platform and a two-way communications medium. One key feature that makes Twitter unique is the mention. What other blogging platform enables this type of communication? Remove the 140 character limit and you have what we already have with Medium, or most any other blog.

We the People of the Internet used to enjoy Posterous.  It was a longer form than Twitter, but simpler than Tumblr. You could even blog on Posterous without setting up an account. Then Twitter acquired Posterous and shut it down (so as to not compete with Twitter). Twitter gave me my Posterous content, but it looked nothing like it did when Posterous was alive and kicking.

My favorite part of Twitter is the absence of an over-lawyered, one-sided, postscript disclaimer: This E-mail and any attachments are private, intended solely for the use of the addressee. If you are not the intended recipient... When has that disclaimer been of any use in an e-mail? Increasing the Twitter character limit beyond 140 characters will definitely add more noise. And I also fear that it would lose its simple two-way dialog via mentions.

Active Writing

For me, the personal beauty of Twitter is it has improved my writing, in a Hemingway sense. I enjoy writing fact, fiction, non-fiction, and narrative. A key to writing well is using the active voice which is direct and to the point, much like Twitter. Many times, I've drafted a "long-winded" tweet, that wouldn't fit into 140 characters, and had to pare it down to a more active voice:

never heard before vs. never heard
tell anyone else vs. tell anyone
a friend of mine vs. a friend
taking care of vs. fixing
But, in the end, Twitter, the corporation, needs to grow, so it must generate more content.

How much better would Twitter be if it expands beyond 140 characters? Fundamental changes like this are bold risks. Perhaps it will payoff. Then again, what is haiku without 5-7-5?

Simplicity is the ultimate sophistication.
–Da Vinci.

PS – Tweetstorms, on the other hand, are a great way to link tweets together to say more.

The key to good customer service: Be respectful.

Twitter is all about 140 characters. At least it was, until a couple weeks ago and that could be a problem.

The 140 character limit was driven by the 160 character limit of SMS. A 140 character tweet, preceded by the, up to, 15 character Twitter username along with punctuation fits perfectly into an SMS text. (The reason SMS is limited to 160 characters is an interesting story in itself.)

For the most part, tweets are public which anyone can see; no Twitter account required. On the other hand, a Twitter direct message (DM), which's limited to 140 characters, is always private. Originally, a DM couldn't be sent to any random Twitter user. The recipient has to be a follower of the sender to limit unsolicited, spammy, DMs. A smart decision.

With so many other communication channels to choose from, DMs weren't nearly as popular as messaging on other platforms such, as Facebook and other mobile apps.

The Perfect DM Application 

Over the years, though, I found the perfect application for Twitter's DMs: Customer service with "Big" companies (think: oligopolies).

Why can't we, as consumers, e-mail a tech support question to our ISP, phone company, etc? The answer is obvious: because Cox, AT&T, etc would be inundated with e-mail manifestos, tirades, and diatribes.

However, with more and more "Big" companies using Twitter, the drama of a public customer/company battle could escalate into a PR nightmare. Enter the Twitter DM.

Over the past few years, when I've had a problem with Cox, AT&T, and GoDaddy, I've used Twitter DMs to get ahold of their customer service department without drama or waisting my time navigating an interactive telephone menu.

The process is simple: Send a respectful tweet to the corporation's customer support Twitter account:
"Hi, I'm having a problem with my service. Could you follow me so I can DM you?"

These companies have active social media customer support personnel, so it usually takes only five or ten minutes, during business hours, before they've followed me. In many cases, they'll immediately DM me, before I've even noticed they started following me.

For this to work, you need a reproducible problem. With Cox, my connectivity, which is typically 100+Mbps had dropped to less than 100Kbps. I DM'd them a screen shot of the slow bandwidth with a note that I've restarted the cable modem and other steps I took to troubleshoot the problem. They're responses have typically been, "We're seeing the same issue. We can have a technician out there, tomorrow, between 8am-noon, noon-4pm, or 4pm-8pm. Which works best for you?"

Now that is amazingly quick and simple. This entire interaction might take place over the course of 30 minutes, but I actually spend less than five minutes documenting my troubleshooting steps and DMing the CSR.

This technique can work for complicated support issues, too. GoDaddy consolidated my domain names into a single account, but the DNS for some of the domains didn't transfer, which I discovered the next day when incoming mail was bouncing back to the senders. I explained the issue all within 140 characters. They quickly responded that they were on it, as they reinstated the backup copies of my DNS.

Concerns

So, that gets to my concern. Twitter has removed the 140 character limit in DMs which could mean CSRs might be reluctant to continue using it if they begin receiving long and unreasonable messages. And I'm wondering what Twitter will gain by making this change. Of course, they could always switch back to the 140 character limit and use e-mail when needed, as GoDaddy and I did.

Perhaps I'm old-fashioned, but I feel like removing the 140 character limit is the equivalent of showing up at a haiku conference and saying, "Hey, everyone, instead of doing 5-7-5, we're going to do 7-5-7 so we have more content."

Yes, I'm a customer service snob. But I've been on both sides of the fence and I give as good as I expect.

If you've ever hosted a domain name with Google Apps, keep in mind that a hacker has a good chance of accessing your e-mail long after your domain's expired since Google stores your e-mail indefinitely if it's a free Google Apps account. This worked to my benefit, tonight, but it badly stung Twitter about five years ago: The Anatomy Of The Twitter Attack

My Story

2.5 year e-mail gap

Two and a half years ago I let a domain name expire that was hosted on Google Apps. It was a domain I no longer needed. But, I forgotten that this domain was tied to a four letter Twitter account that I occasionally used which receives a lot of inquiries – mostly from people asking me to transfer this account to them.

When my Keychain became corrupted, several months ago, Twitter would not let me log in to this Twitter account without confirming my e-mail address. Obviously, I couldn't receive e-mail since I no longer owned the domain name. The problem was, over the years, I've owned a lot of domain names and I had no idea which e-mail address was tied to this Twitter account. When I tried to reset this Twitter account on the twitter.com website I was told that an e-mail had been sent to my e-mail address on file. That was of no help since I didn't know which defunct e-mail address the confirmation was sent to.

Tonight, on a whim, I tried to reset my password for this Twitter account with the iOS app instead of their website. Lo and behold, the app reported that a confirmation e-mail was sent to a slightly redacted e-mail address (it looked something like this: jo***@ex***.** – let's pretend that my expired domain name was example.com). It was just enough of a hint to point me in the right direction. I visited https://www.google.com/a/example.com and logged in. When I checked my Gmail account I could see that the last e-mail received was in 2012 – which was when I let this domain name lapse. A quick visit to GoDaddy and $9.17 later I re-owned the domain name I once had a couple of years ago. With the new domain name in hand I updated the MX records with the info for Google's mail servers and I received my confirmation e-mail immediately. The entire process took about 30 minutes.

Yes, it's very handy that Google keeps my e-mail forever, but it can be very dangerous too.

Balboa Park, 7 AM: The perfect place to think about outliners and this blog post.

Two years ago, while having lunch with Dave Winer at Carnegie Deli, I embarrassingly confessed to him that I didn't fully understand outliners. He told me, "That's OK, you will."

Fargo

While I'm a big fan of writing down tasks in flat to do lists, I never took the time to structure my to do lists into an outline. Since the beginning of last year, Dave has been working on a very interesting web based outliner that runs and stores your outline inside your web browser with the ability to also save it to your Dropbox. While saving data to Dropbox isn't a big deal, the ability to save data using a web browser's local storage feature seems underutilized by developers. The overlooked beauty of Fargo is that Dave's web based app can scale, big time. The Fargo web app is served up as a static HTML web page with dynamic Javascript (Node.js) so all the heavy "thinking" and storage is done in the client's browser. Since the outline is saved either locally or to Dropbox that means Dave doesn't have to worry about customer storage requirements if he gets a billion users, overnight.

Little Porkchop and Happy Friends

Alcazar Garden and the California Tower

Two weeks ago, Dave launched Little Porkchop which lets Twitter users send out a tweetstorm. As I played with it, Dave hinted that he had something bigger on the horizon. That "something bigger" came a couple days ago when he released Happy Friends.

Happy Friends is an outliner that let's you embed a Twitter user's feeds into an outline. And, since it's an outline, you can indent, outdent, and rearrange Twitter users while archiving individual tweets. Twitter and Facebook are very flat formats consisting of a post with comments threaded to it. Happy Friends, on the other hand, turns a flat Twitter feed into a mailbox style reader. Once again, the beauty of Happy Friends is it can scale to the moon and back without any load on Dave's servers.

So, after all of Dave's arm waving, I'm starting to get it. Slow and steady wins the race.

It's better to pass command line args as an array than a string.

If you've ever needed to rotate, resize, or convert an image, programmatically, then take a look at the OS X SIPS command. SIPS is a highly optimized part of Core Graphics (Quartz) designed for the Automator app. It's been around for nearly a decade (Tiger 10.4). I first heard about it when chatting with another Apple engineer who was developing it in Cupertino.

Since Java's early days I have been manipulating images inside of web apps. In the 1990s, Java image manipulation was very crude and slow. If I recall correctly, it could not be done, easily, on a headless server. I believe it required instantiating a Java applet (canvas) to do the manipulation, hence the need for a windowing system.

I've tried other Java image APIs including ImageMagick, but none could hold a candle to OS X's SIPS when it came to speed. The first time I tried SIPS, in 2005, I resized a 24 megapixel image into a thumbnail. When I hit enter the command prompt immediately returned so I thought it failed. It turns out it worked, flawlessly. A quick call to the command line is an elegant and simple way to implement SIPS in Java, or any other language. If you want to get fancy, you can spin it off in it's own thread so it doesn't block. As always, be careful to avoid any race conditions. (Now that I think about it, it's probably a better idea not to spin it off in it's own thread until you need to scale your code.)

I used SIPS exclusively with my photo sharing website (Epics3) that let users upload photos for storage in their own S3 bucket as a static web page. Although the Epics3 (and Adjix) servers are now defunct, along with Posterous, my images live on in AWS S3:
http://pics.joemoreno.com/2gi3

The downside of SIPS is it hasn't been continuously developed. Some of the things it can't do is overlay text or read GPS EXIF metadata.

But, after reading Dave Winer's request for a text image overlaying API, it got me thinking again. Especially when I proposed this idea for Twitter 519 days ago. I'm surprised there isn't already a popular text image overlaying REST API. Perhaps soon, very soon, there will be the API we seek.

Dave Winer has repeatedly pointed out that Twitter is, in itself, a single point of failure since it's centralized. No one can argue with that. But, the upside is that it's fast – very fast. The only noticeable latency is the time it takes for a tweet to be uploaded from a client to Twitter's servers. When considering distributed infrastructures like SMTP and DNS it's obvious how much slower they are due to propagation. The upside of these fundamental Internet services is no one owns them which means no one can inherently stop them or advertise against them, yet they're cheap enough that companies can provide them for free. But, just because no one owns these protocols, doesn't mean they can't go down, at the end points.

So, it begs a couple questions. Is a fast, free, Twitter, better than the alternative? More importantly, is Twitter a key, fundamental, Internet service worthy of an RFC?

Author: Joe Moreno

In the ancient days of social media (circa 2008) people frequently said, "I don't get it." Back then, people didn't realize that social media was simply taking our spoken conversations about nothing and moving them online. But, as more and more people got involved an interesting crowdsourcing phenomenon began to unfold.

I first observed this crowdsourcing solution in the fall of 2008 when Guy Kawasaki forgot his MacBook power supply.


At the time, I was at home about 40 minutes away and I could have easily made it to Coronado by the top of the hour. After thinking about it for five minutes I responded to Guy's tweet but it was too late. Jerry Jones had sealed the deal. However, I did get an honorable mention from Guy (back then, my Twitter username was @JoeLeo.)

About two years later, I explicitly and successfully tried crowdsourcing to figure out the name of song. It's amazing when it works.

What struck me, today, is that crowdsourcing via social media still works. So much so that we simply take it for granted.

Last week, I reminisced about telephone landlines. I was imagining a home phone solution where my cell phone would link to a ringer so that I could hear it ring throughout the house without carrying it from room to room.

A college buddy quietly observed my tweet and found what I had described when he was shopping at Costco, today. We joked that he was my personal social shopper. He found several models, but the Panasonic KX-TG155 seemed to foot the bill as he passed along a photo of the collateral.

I originally drafted this piece on August 17, 2012 but didn't publish it until speaking with Dave Winer, today.



After yesterday's API announcement from Twitter, do we really need an open alternative? Probably not. Your average Twitter user doesn't care and won't notice, but here's the litmus test - it's one that App.net is currently going through. Let's build it and see if they come.

A tweet is, at most, 160 charters of text. That's 140 charters prefaced by a username. Of course it can be longer when we start adding in metadata. But, my point is that it's just short messages full of text characters. The big challenge is that Twitter is a system that's both a static blog and a dynamic communications system. It's one of the first main stream systems to serve those two purposes, similar to Usenet.

You only need to look at a couple Amazon web services to see that they've not only implemented a scalable infrastructure for a Twitter alternative, but they documented the API so thoroughly that any third party could reimplement the API and decouple themselves from AWS, if they wanted to.

How Would It Work?
If I were to implement a simple Twitter alternative it would behave like RSS with push notifications. They key is that you'd have to be able to read, post, mention, and follow via a web browser without needing to set up your own server. This is not as hard as it seems thanks to JavaScript. If we can make this work while running inside of a web browser, then building a desktop app or server to augment the basic service would be simple.

Overview
Notification is the easy part. Simply use AWS SNS to post updates to followers who are subscribing (following you). SNS updates would be posted to each follower's SQS queue.

The hard part is where and how to store static tweets. Originally, I proposed storing them as linked lists in DNS TXT records. Dave Winer pointed out that, although DNS could scale like this in theory, it probably couldn't in reality. He said that we already had the scalable solution with AWS S3. So, my proposal is to store each tweet as either standalone text or as an HTML webpage in an S3 bucket. Each S3 object contains the entire tweet with a link to the previous tweet and the next tweet. Any third party app could access these tweets and the links and meta-data could be nicely stored in the the S3 object HTML headers. (S3 HTML headers begin with x-amz-meta- and they're beautiful for associating meta-data with S3 objects.)

The Rules
1. Users would sign up for SNS and SQS.
Users, in this context, would be users of the service who could be the developers. They, in turn, could build apps that abstract this so the layperson user wouldn't need to sign up for SNS or SQS.

2. If you want to follow someone, you subscribe to their SNS notification and use your SQS as the endpoint for message delivery.

3. If you want to message (@) someone, you post to their queue.

AWS already has APIs to handle permissions so each user can block followers.

4. User's AWS credentials can be stored in their own web browser database. This eliminates the need for a third party database server that could be compromised.

________
January 30, 2013: This is still a work in progress with some unanswered questions, but, since it was tweeted about, yesterday, I dug it out of my drafts folder and published it.

Yup, Twitter is down. I can't recall the last time I've seen an outage like this. Although it was very frequent back in 2008 – 2010, it has been extremely stable the past couple years.

While Twitter's not 100% down, it's mostly down. It's been having fits and starts all afternoon. I guess that's like being mostly-dead, which is slightly-alive. It really depends how you're accessing Twitter (web, client, api, etc) and from where.

The interesting part is how fragmented the Twitter conversations became as others quickly stepped into to fill the Twitter void.
http://threads2.scripting.com/2013/january/outageTheater
http://news.ycombinator.com/item?id=5094389
http://news.ycombinator.com/item?id=5093964
http://status.twitter.com/post/41136790651/twitter-site-issue

Summary
How to squeeze more than 140 characters into a tweet with indexable text.

Background
Last Friday, I half jokingly sent out a tweet demonstrating how to squeeze more than 140 characters into a tweet.

Basically, I tweeted that it was possible to take a screen shot of text longer than 140 characters which could then be attached to a tweet as an image.

I say half jokingly because, even though it works, it's a bit of a hack. It wasn't until Dave Winer – who actually didn't support this technique – retweeted me that I saw a surprising interest in it. The interest probably wasn't so much the solution as it was the part that was a joke. One person called it "twaxing" (tweeting + faxing). And Dave half-joked, "the web cries" for me. But I noticed, over the weekend, that a number of people have started adopting this technique.

It's handy that Twitter now, organically, hosts images on their servers which means that a link to an image in a tweet is much less likely to break when compared to hosting an image with a third party.

A couple people pointed out the obvious shortcomings to the twax technique which was that an image of text isn't indexable (searchable). That got me thinking… what if a twax was indexable? Would there be any benefit for those times when you needed, say, 400 or 500 characters in a tweet? Perhaps.

Searchable Solutions
My initial twax search solution was to embed the tweet's meta-data in the text of the tweet but that is too ugly, inelegant, and incomplete.

After some more thought, I realized a very workable solution: embed the tweet's meta-data as a QR code inside the tweet. Any third party server could simply scan the image and decode the QR code while any human could read the text.

Technically speaking, this will work. But, would anyone use it and how would it work?

I can easily see a mobile app or Twitter web feature that would notify you once you exceeded 140 characters while continuing to let you type. When you clicked the Tweet button, to publish your tweet, the tweet would contain the first 140 characters of the tweet while the entire tweet's text would be displayed in the image, followed by a QR code of the tweet's text and meta-data.

The nice thing about this technique is that a single QR code can encode thousands of characters of text. Plus, the tweet text and its image with the QR code could stand alone without network connectivity.

The beauty of Twitter is that it's simply 140 characters of text. Shorter than an SMS text message - akin to a headline. Any other payload in the message is a hyperlink which is also text.

Why only 140 characters per tweet? Because it was designed to fit into a 160 character SMS message preceded by the sender's user name:
"@joemoreno: Just arrived at the Top of the Rock. http://epics3.com/piqk"

Which begs another question: Why only 160 charters for an SMS? Because the inventor of SMS, Friedhelm Hillebrand, typed out random sentences and noticed that they fit into 160 characters.

Worthy Competition
There have been some alternatives to Twitter, but they're just copies. What's the point of making a copy of Twitter if it still suffers from the same Achilles' heel: a centralized single point of failure controlled by one corporation?

A worthy competitor to Twitter requires fundamental integration into the Internet's infrastructure. This shouldn't be too difficult, after all, it's just text --- or another way to think about it, it's just TXT.

DNS? Seriously?
The Twitter alternative that I'm proposing simply uses DNS. In other words, a tweet would simply be stored as a DNS TXT record. Since it's widely recognized that DNS is the Internet's single point of failure, it has multiple, redundant and distributed, servers to keep it running. DNS servers have impeccable uptime stats because, without DNS we have no practical Internet connectivity.

Advantages.
1. No additional servers required. Simply add a new DNS record for each TXT tweet.

2. Redundantly propagated across multiple DNS servers.

3. Server load distributed to ISP DNS caches. In other words, massive traffic for a single tweet would not need to go back to the authoritative DNS server. Set a long TTL for the TXT tweet, say 24 or 48 hours, and each local ISP should only hit the authoritative DNS server once every day or two to refresh a particular tweet's TTL.

Disadvantages
1. Can't easily delete tweets since they're cached at each ISP's DNS server, especially if added with a long TTL.

2. Tweets would need to be inserted into TXT records using a robust API - the only one I'm aware of is Amazon's Route 53 API.

3. Each TXT tweet would need to be a linked list to the previous tweet; or, perhaps, a double linked list to both previous and next TXT tweet.

4. Each TXT tweet would need an embedded timestamp (either UNIX timestamp: 1342472514 or a human readable dateTime object: 2012-07-16T20:38:00Z).

5. TXT tweets, unlike Twitter tweets, can be edited.

6. TXT tweets can expire after the TTL timesout.

TXT Tweet Proposed Standard
Since the TXT tweets are a single (or double) linked list, we need to know where to start. The logical place to start is with the most recent (i.e. last) TXT tweet. That could be defined in the domain's root TXT record which can be found via the dig command:

dig -t txt joemoreno.com
joemoreno.com.   1 IN TXT "2012-07-16T20:38:00Z|tweet4.joemoreno.com"

So, the most recent TXT tweet is at tweet4.joemoreno.com. (A simpler naming convention could be host names with integers, such as 0.joemoreno.com, 1.joemoreno.com, 2.joemoreno.com, etc.)

Left for the Student
Several services need to be built on top of this proposal. Displaying a single user's TXT tweets can be rendered by a simple script running on a web server to display a specific user's feed. Mixing different user feeds, chronologically, is a little harder, but very doable.

However, where it gets challenging is how to handle "follows" and "mentions." In both cases, a server would need to either push or pull these notifications in real time. Pulling could be simple polling, like an RSS feed query. But, push notifications can be a bit more challenging. I'll have to think about how this part would work.

"Getting" Twitter isn't really that hard. Most people understand that an e-mail is an online version of a written note or letter. But there are a few short falls of e-mail that don't match how we communicate in the real world.

First, it's difficult to have a real time conversation over e-mail. Second, people usually do not talk to each other by speaking several paragraphs before getting a response during a casual conversation. Third is the fact that you can't easily start a conversation with someone you don't know.

Twitter and Facebook simply take the conversations that we have at parties, cafes, bars and mixers into the online world.

Facebook is the private party or water cooler chat we have with the people we know, whereas Twitter is the place to have a random conversation, in public, usually with strangers. The beauty of Twitter is that you can search the conversations and jump in at any time.

Just like many people don't go to bars or cafes for atmosphere, the same is true for logging onto Twitter or Facebook. You don't have to do it if it doesn't float your boat.

Is it really necessary for Twitter to put my cell phone number and e-mail address in the HTML source code, in the clear?

To see your cell phone number and e-mail address, log into your Twitter account and then view an individual tweet. For example, view this tweet's source code and search for "Init CurrentUser Method":



Usually, sensitive information, like this, is encoded in a cookie. The cookie can change the information encoded, from time to time (for example, each time you log in). However, I can't change my cell phone number if it's compromised.

Trying out a test of Twitter's Blackbird Pie which lets users embed tweets into blogs.

It seems that there is no shortage of search engines combing tweets for links. Whenever a tweet is sent, that contains a link, within a few seconds search engines start to spider the tweet. In the first two minutes each link in a tweet has been hit by a bot 12-20 times.

Here are the first ten hits on a link within three seconds:

Click to enlarge

Why 140 characters? The obvious answer, which I'm sure you know, is so that a tweet can fit into the 160 character limitation of an SMS text message. In other words, the Twitter user name (which can be up to 15 characters) followed by the 140 character tweet can all be packaged nicely into a single SMS text message.

Which begs the next question: Why restrict a tweet to the limits set by SMS when this is the World Wide Web? One of the "limitations" of e-mail and the Web is that you need Internet access for connectivity. In developed countries, we take Internet connectivity for granted. Having spend some time living in East Africa I was amazed to see how important SMS was to the locals who don't own computers, printers, or even have an e-mail address. But, nearly all of them had pre-paid cell phones and they used SMS just like we use e-mail (they also had trivial SMS to e-mail and e-mail to SMS bridges).

Additionally, their cell phone networks have features which I wish we had here in the US. Basically, people in developing countries have substituted the computer, printer, and Internet with the cell phone, fax, and the carrier's wireless network. This is how most of the world gets "online" with technology.

Imagine if Twitter didn't just go after the consumer market who own computers and smart phones with Internet access (I'm guessing about one billion people), but, instead, what if Twitter went after every person on the planet who's an active cell phone subscriber (which will reach 4.6 billion by the end of 2009). Now, that would be a fantastic communications tool!

Twitter's website begin counting clicks inside of tweets. Obviously, they do this to track stats, i.e. how many people click on links from the Twitter web site.

The interesting thing is that they're passing on the simple referrer that you'd expect. In other words, instead of the referrer looking like:

http://twitter.com/link_click_count?url=http%3A%2F%2Fadjix.com%2Fsx4d&linkType=web&tweetId=3696834541&userId=-1&authenticity_token=8c678e082a5ee88d47f03b05cf6f6887b8903acd

It simply looks like:
http://twitter.com/joeMoreno

This is very clean for link tracking websites like Adjix which track clicks by IP address and referrer:


Update: Just discovered a clear downside - when the Twitter website is slow, clicking on these links are painfully slow since you have to first be redirected by Twitter's servers.