Joshua Schachter

Joshua Schachter (aka Joshua Eli Schachter) is the creator of del.icio.us, creator of geoURL and co-creator of Memepool. He has a B.S. in Electrical and Computer Engineering from Carnegie Mellon University in Pittsburgh.1

  • Born 1974

joshua's blog - http://joshua.schachter.org/

Blog

joshua's blog - Subscribe to feed

on url shorteners

1238784046|%e %b %Y, %H:%M %Z|agohover - http://feedproxy.google.com/~r/JoshuaSchachter/~3/1KBKIn2OfK8/on-url-shorteners.html

URL shortening services have been around for a number of years. Their original purpose was to prevent cumbersome URLs from getting fragmented by broken email clients that felt the need to wrap everything to an 80 column screen. Addendum: They're useful in print, too. But it's 2009 now, and this problem no longer exists. Instead it's been replaced by the SMS-oriented 140 character constraints of sites like Twitter. (Let's leave aside the fact that any phone that can run a web browser and thus follow links can also run a proper client, and doesn't have to hew to the SMS character limit.) Since TinyURL, there has been a rapid proliferation of shortening services.

Aside from the raw utility of allowing URLs to fit within a Twitter message, newer services add several interesting bits of functionality. The most important of these is that let the linker turn any link into THEIR link, and view metrics on how far it's spread and how many clicks it's gotten. Showing a user how popular his actions are is inevitably addictive. Shorteners are relatively easy and lightweight to set up. Adding a simple interstitial before the redirect provides an obvious way to monetize. And maybe someday all the link data will be worth something.

So there are clear benefits for both the service (low cost of entry, potentially easy profit) and the linker (the quick rush of popularity). But URL shorteners are bad for the rest of us.

The worst problem is that shortening services add another layer of indirection to an already creaky system. A regular hyperlink implicates a browser, its DNS resolver, the publisher's DNS server, and the publisher's website. With a shortening service, you're adding something that acts like a third DNS resolver, except one that is assembled out of unvetted PHP and MySQL, without the benevolent oversight of luminaries like Dan Kaminsky and St. Postel.

There are three other parties in the ecosystem of a link: the publisher (the site the link points to), the transit (places where that shortened link is used, such as Twitter or Typepad), and the clicker (the person who ultimately follows the shortened links). Each is harmed to some extent by URL shortening.

The transit's main problem with these systems is that a link that used to be transparent is now opaque and requires a lookup operation. From my past experience with Delicious, I know that a huge proportion of shortened links are just a disguise for spam, so examining the expanded URL is a necessary step. The transit has to hit every shortened link to get at the underlying link and hope that it doesn't get throttled. It also has to log and store every redirect it ever sees.

The publisher's problems are milder. It's possible that the redirection steps steals search juice — I don't know how search engines handle these kinds of redirects. It certainly makes it harder to track down links to the published site if the publisher ever needs to reach their authors. And the publisher may lose information about the source of its traffic.

But the biggest burden falls on the clicker, the person who follows the links. The extra layer of indirection slows down browsing with additional DNS lookups and server hits. A new and potentially unreliable middleman now sits between the link and its destination. And the long-term archivability of the hyperlink now depends on the health of a third party. The shortener may decide a link is a Terms Of Service violation and delete it. If the shortener accidentally erases a database, forgets to renew its domain, or just disappears, the link will break. If a top-level domain changes its policy on commercial use, the link will break. If the shortener gets hacked, every link becomes a potential phishing attack.

There are usability issues as well. The clicker can't even tell by hovering where a link will take them, which is bad form. Some sites offer link previews, but there's no way to make a preview preference stick globally across the many shortening services. And just like ad networks, link shortening services could track a user's behavior across many domains. That makes the paranoid among us uncomfortable. We hope the shortener never decides to add interstitials or otherwise "monetize" the link with ads, but we have no guarantee.

For these reasons, I feel that shorteners are bad for the ecosystem as a whole. But what can be done to improve the situation?

One important conclusion is that services providing transit (or at least require a shortening service) should at least log all redirects, in case the shortening services disappear. If the data is as important as everyone seems to think, they should own it. And websites that generate very long URLs, such as map sites, could provide their own shortening services. Or, better yet, take steps to keep the URLs from growing monstrous in the first place.

You could guarantee that the shortened link is the one that was originally shortened by using a cryptographic hash. But this causes URLs that aren't as short as is possible.

A variety of greasemonkey scripts resolve shortened URLs and replace them inline.

Finally, shortening services could provide archives of their entire database - but this raises all sorts of privacy concerns that I hesitate to even dig into.

The most likely, of course, is that we don't do anything and that the great linkrot apocalypse causes all of modern culture to dissapear in a puff of smoke. Hopefully.

With thanks to Maciej Ceglowski

Updates

  • June 15th, 2009: cli.gs, the "4th most popular" shortener, gets hacked, redirecting a huge number of sites to a new location. 93% of hacked urls can be restored from backup
  • August 9th, 2009: tr.im throws in the towel after being able to figure out how to monetize the site. There are zero interested buyers. The site will redirect links until "at least" the beginning of 2010, but no future is guaranteed.

overclocking the lecture

1225613661|%e %b %Y, %H:%M %Z|agohover - http://feedproxy.google.com/~r/JoshuaSchachter/~3/r-sY-bRXVo0/overclocking-lecture.html
The growth of both bandwidth and storage mean that in the last few years practically everyone from individuals to large universities have begun putting lectures and talks online. While I can easily pick out a dozen or a hundred videos that that would be fascinating and educational, I am hamstrung by my short attention span, and I drift off almost immediately. Not to mention the fact that one browser crash or accidental tab closure loses my place and probably the video itself as well.

After tinkering a while, I've managed to figure out a way to cut down the time it takes to watch a video. This works for me, on my Mac; your mileage may vary:

  1. Make sure you have the appropriate codecs installed. I generally use the Perian codec package. I additionally find that some FLVs require QTPro to be installed; it's not very expensive.
  2. Download the video somehow. Some sites, like Google Video, let you download a copy. Others, like YouTube, do not allow this. However, most embedded flash video can be grabbed via the technique in the bottom video in the demo videos at Perian.
  3. Open the video in QuickTime. The video is now happily outside the browser.
  4. Go to Window → Show A/V Controls; change the playback speed in the relevant window. I find that 2.0x generally works pretty well; the video will be faster and the audio is a little clipped but nicely de-chipmunked.
  5. Enjoy your new lecture! The glacial discussion now arrives at a rapid-fire pace. You'll be too busy trying to keep up to play Desktop Tower Defense, and you'll be done in a half hour.

how to watch lectures faster

amateur economist

1221281199|%e %b %Y, %H:%M %Z|agohover - http://feedproxy.google.com/~r/JoshuaSchachter/~3/odv8oYXhT7U/amateur-economist.html

Ever since seeing a presentation by Dolores Labs about Amazon's Mechanical Turk, I've been itching for an excuse to play with the system.

I recently saw a thread that highlights the distinction between expected value and utility. Would you take a more likely but lower payoff instead of a less likely but higher payoff? Similarly, the St. Petersburg Paradox takes the problem to its logical extreme. By constructing a game that has a series of increasingly rare payoffs of increasingly larger size, a game with infinite expected value is created.

So I constructed 21 versions of the questions, varying the size of the dollars as well as the rate of payoff for the second outcome.

Example Question

For one cent apiece, I sent the questions to be answered by one hundred people each, and collated the results. 2100 questions, three hours, and thirty dollars later, I have my results.

Batch_3890_result.csv

Clearly, people (or at least these Turks) begin to cross over at larger values, reaching equilibrium at around $1,000.

While this isn't the most groundbreaking work, it is nice to be able to generate an experiment and gather the results in the course of an evening and then have the results be so pleasing.

The Mechanical Turk is presented as a way to solve problems that are easily explained to people but difficult to implement for computers, frequently described as "artificial artificial intelligence." However, I think some of the most intriguing uses yet will be to explore the edges of our own uniquely human behavior and self-understanding.

beyond rest

1216924919|%e %b %Y, %H:%M %Z|agohover - http://feedproxy.google.com/~r/JoshuaSchachter/~3/1tvxhZE3F4A/beyond-rest.html
Rabble and Kellan's presentation, "Beyond REST? Building data services with XMPP" is both a great idea as well as a good introduction to coping with massive amount of traffic that large systems have to service.

A publish/subscribe architecture is natural to other problem domains such as instant messaging and financial data systems (Tibco, Reuters, and so on).

Similarly, Brad Fitzpatrick implemented something similar as a never-ending Atom feed a few years ago for Livejournal (sans XMPP, which wasn't as conceptually prevalent then.)

One important point in the presentation is that, for example, a single application would poll Flickr approximately three million times in a day to fetch only several thousand updates. At Delicious we saw a similar level of polling activity, made somewhat worse by speculative querying (hitting the URL information pages to see if there was any data for arbitrary URLs, which was generally unlikely.)

One solution that ocurred to me at the time was to build a simple callback system over HTTP. This would fall comfortably between full polling and full persistent publish/subscribe. The clever acronym even writes itself: PIMP Is Mostly Push, although maybe PRSS (Push RSS) would be slightly more polite.

Simply described, instead of polling frequently, a client would send a normal HTTP request with the resource to be subscribed to and an endpoint to deliver updates to: http://your.app/subscribe?resource=/some/user&callback=http://my.app/endpoint

Presumably the endpoint would then receive RSS item fragments when and only when that resource updated. For security, the exchange should include some kind of token, borowing from the appropriate protocols. The subscription would lapse after, say, 24 hours, or that could be passed in as a parameter.

In some ways this is slightly more elegant than the XMPP solution as neither side has to maintain a dedicated long-running process. A simple server-side implementation would justfetch items from a work queue and send out HTTP messages. A simple implementation on the client side would be a plain old web page that could accept and process a POST request. There are a number of people on inexpensive service providers who have at best web scripting hosting and not much else. The case where Delicious/Twitter/Flickr pushes my own items (and not much else) up to my blog is an important one. Additionally, there would not need to be any persistent TCP connections, which is probably more efficient in server resources (but less efficient in network resources; for billions of messages the TCP overhead becomes significant).

Of course, callbacks are totally infeasible for a variety of other uses, especially for mobile or desktop applications (which are likely to be firewalled).

rhizome

1210623255|%e %b %Y, %H:%M %Z|agohover - http://feedproxy.google.com/~r/JoshuaSchachter/~3/_ZqXnZ-AX9E/rhizome.html
I'm speaking briefly at the Rhizome 2008 Benefit in New York City later this week. There are still tickets available, so you have no excuses for not attending.

rhizome

tag mockery

1209682162|%e %b %Y, %H:%M %Z|agohover - http://feedproxy.google.com/~r/JoshuaSchachter/~3/bnrMpNQGvE0/tag-mockery.html
A sure sign that I've hit the big time:

dilbert on folksonomy GTA IV

stupid internet joke day

1206997054|%e %b %Y, %H:%M %Z|agohover - http://feedproxy.google.com/~r/JoshuaSchachter/~3/myld6XBqptk/stupid-internet-joke-day.html
While I might occasionally notice interesting inconsistencies in the structure of the world and phrase them into semi-witty banter, I know in my bones that I am not a funny person.

So when I realized that tomorrow's imminent arrival of Stupid Internet Joke Day (was: April Fool's Day) would require the avoidance of all unnecessary internet contact, it also occurred to me that I may as well point out some common Funny Anti-Patterns. But that's been done to death - thank you, internet hipsters. I merely wish to remind you all that elaborate hoaxes (press releases involving small company acquiring a large one, switching stylesheets with someone, etc) are immediately and transparently stupid. Instead, try to actually do something surprising. The ha you save might just be your own.

put a proxy in front

1200989792|%e %b %Y, %H:%M %Z|agohover - http://feedproxy.google.com/~r/JoshuaSchachter/~3/h40-ZzvNWlQ/proxy.html
When scaling from a single web server to multiple web servers, the typical practice is to put a load-balancing reverse HTTP proxy in front. This is a web server that forwards incoming HTTP requests to other internal web servers and thus distributes the load across all the different HTTP servers, allows for failover, and all sorts of good things.

However, a simple trick I learned early on is that even if you have only a single web server, a proxy in front can help out performance significantly. Through the simple expedient of buffering the communication with slow web clients, your potentially heavyweight (especially when mod_perl meant that each process was dozens or even a hundred megabytes apiece) and/or expensive Apache processes don't have to waste time serving every request for the entire length of time the client is connected. This allows you to run vastly fewer Apache processes. In the past, I've used pound and perlbal. Pound is fast and lightweight, and allows routing based on the HTTP query; for example, everything under /img/ got routed to a high-speed thttpd instead of the Apache itself. Perlbal is much more configurable but slightly harder to get running, and the documentation was sparse.These days, I'd also investigate nginx and varnish. Pen, a generalized TCP load-balancer with server affinity (connections will go to servers they've gone to recently in the past) is also quite interesting but will not help with the slow client problem. Finally, a second set of apache processes, configured to reverse-proxy via mod_proxy, will also do the trick. A

unsubscribe

1193806453|%e %b %Y, %H:%M %Z|agohover - http://feedproxy.google.com/~r/JoshuaSchachter/~3/AVEB9y5k91U/unsubscribe.html
Chris Anderson is fed up with PR folks spamming him.

Me too.

unsubscribe

These were sent to the email address listed on my blog; I use tear-off addresses for subscribing myself to things.

social spring cleaning

1188292564|%e %b %Y, %H:%M %Z|agohover - http://feedproxy.google.com/~r/JoshuaSchachter/~3/6mh7Y6p-UNQ/social-spring-cleaning.html

I find myself lately re-entering everyone I know into the system every year or two; I remember Six Degrees, Friendster, Linkedin, (I skipped MySpace -- I'm too old,) Facebook, Dopplr, Flickr, and so on. Brad Fitzpatrick seems to agree that this is an annoying waste of time, and says so in his thoughts on the social graph.

Most social systems never forget anyone. Given that recent behavior appears to send friend requests to anyone you've ever met even briefly, I find my contacts list ends up filled with people I don't really know. In many systems, removing someone from your list is either buried or simply impossible. Further, since these systems make implicit relationship information explicit, deleting someone becomes a loud signal. In real life you would merely back off a bit, but the systems only allow you to express a binary sort of relationship.

Therefore, switching networks becomes a way to regularly cleanse your contact list. There is evidence that younger internet users regularly start new instant messaging IDs; this likely serves a similar purpose.

So perhaps frequent switching is less a function of fashion but instead a coping mechanism to deal with the mismatch between reality and software.

ouch

1186097585|%e %b %Y, %H:%M %Z|agohover - http://feedproxy.google.com/~r/JoshuaSchachter/~3/g7_58JNinTE/ouch.html

ouch

elevator camera obscura

1185950313|%e %b %Y, %H:%M %Z|agohover - http://feedproxy.google.com/~r/JoshuaSchachter/~3/LdbYQn7JnZw/elevator.html
The elevator in my apartment building opens to the outside, and on clear, sunny days, a brief picture of the world snaps into focus on its brushed metal interior. The narrowing elevator doors focus the image, counteracting the blurring of the vertically brushed metal; in one dimension, a mirror, and in the other, a camera.

I'd like to thank the tender ministrations of the Northern California Kidney Stone Center and the resulting painkillers for allowing me spend a happy afternoon attempting to capture the effect. I tried using a fancy DSLR, but none of the photos really came out; the short video embedded below works quite well, though.

new york essentials

1184825311|%e %b %Y, %H:%M %Z|agohover - http://feedproxy.google.com/~r/JoshuaSchachter/~3/nbaI34AzN4c/new-york-essentials.html

When folks ask me where they need to go in NYC, I have a short list of places I send them to. I'm not saying these are the best or anything; I just miss them.

At Gray's Papaya on W 72nd and Broadway, the Recession Special, consisting of two hot dogs (just mustard) and a papaya drink, shared with my wife, is a reliable late-afternoon snack.

Pam's Real Thai is a tiny hole in the wall on West 49th Street and 9th Avenue; I always get the red curry with chicken. After eating chicken and associated vegetables, I feel so badly about abandoning the remaining sauce that I douse the remaining rice with it or just get a spoon and eat it like a sweet and spicy soup.

The omakase (chef's choice) at Sushi of Gari on Columbus at W 78th isn't deeply concerned with being authentic and I don't much mind; the sushi is amazing fish with all sorts of interesting garnishes. I my favorites are the salmon sushi with roasted tomato and the marinated tuna with pine nuts on a tiny crisp flake of fried nori. The Upper East Side location is supposedly better (Gari himself presides) but I've found the Upper West Side spot easier to get into on short notice.

I am told that the shakes at Shake Shack in Madison Square Park are amazing, but honestly. I always get the Shack Burgers, which are transcendently good. The only hard decision is whether to get the Single Shack, which has an excellent sauce-to-meat ratio, or the Double Shack, which has more of the tasty, tasty meat. The lunchtime lines are too long to deal with; go early (11:30 am or so) or late (2:30 pm) and the lines won't be too long.

Joe's Shanghai, on Pell Street, has amazing xiao long bao - tiny dumplings filled with a bit of meat and soup. They're a bit challenging to eat and there are a variety of strategies; I prefer to poke a hole in one and let it drain into a spoon, then add a bit of gingered vinegar, and then drink the soup and finally eat the remaining dumpling. There's an location on West 56th Street, which is much more expensive but equally good. Twice a year, a famous Taiwanese chef, whose xiao long bao are even better, makes an appearance at the Sheraton in Flushing, but the scheduling is just too difficult to work out.

finally, a mission i am qualified for

1176318753|%e %b %Y, %H:%M %Z|agohover - http://feedproxy.google.com/~r/JoshuaSchachter/~3/vdJzsqFzugw/finally_a_mission_i_am_qualifi.html

finally a mission i am qualified for

fidelity

1170177646|%e %b %Y, %H:%M %Z|agohover - http://feedproxy.google.com/~r/JoshuaSchachter/~3/sMSwftt_3ek/fidelity.html

While software systems tend to strive towards accuracy and fidelity, I have frequently observed that these exact qualities may hurt social software.

When you walk down the hall and see someone you know, you raise your eyebrows to acknowledge their existence, and expect the same from them. If they don't reciprocate, you can plausibly tell yourself that perhaps they didn't see you, or were otherwise distracted. However, when you send someone an instant message, and they never reply, you can be reasonably sure they got it and are ignoring you. Thankfully, in the email world, we can at least blame the spam filter as to why you never replied.

It occurs to me that not every factoid gleaned from the constellation of behavioral data should be presented.

For example, the emminently social Twitter, happily informs me that while 34 people count themselves amongst my friends, only 31 of them care to be informed about I'm up to every day -- and then shows me who those folks are. While these lists are on different actual web pages, it's not a herculean task to figure out the actual people involved. Even though it's possible to show all the information, from a social perspective a degraded view would be better.

Del.icio.us

http://del.icio.us/joshua - Subscribe to feed

  • Ciao Python, Hola Go! / python vs go. lots of good pointers for python multiprocessing. / 1259351280|%e %b %Y, %H:%M %Z|agohover
  • Elefant Machine Learning toolkit / Elefant (Efficient Learning, Large-scale Inference, and Optimisation Toolkit) is an open source library for machine learning / 1259133720|%e %b %Y, %H:%M %Z|agohover
  • The Longest Way / Dude tries to walk from Beijing to Germany. Way more hardcore than Matt / 1259113680|%e %b %Y, %H:%M %Z|agohover
  • Captain Successor / brilliant little space game... build your ship / 1259086020|%e %b %Y, %H:%M %Z|agohover
  • South / schema migration / 1259051760|%e %b %Y, %H:%M %Z|agohover
  • Node.js is genuinely exciting / server-side javascript but not mod_js, probably a good thing. also points for v8 / 1259006460|%e %b %Y, %H:%M %Z|agohover

Twitter

http://twitter/joshu

Latest tweets from joshu

/protected/

Meta Search Alerts

Meta Search Alerts: Joshua Schachter
Run Pipe... | Subscribe to feed

  • To Sell or Not to Sell: Silicon Valley Acquisitions Market Heats Up | Fast Company / One of the Valley's recent poster boys for this phenomenon is Joshua Schachter, who sold his social bookmarking service Delicious to Yahoo in 2005 for a reported $30 million. This summer, on an online discussion board, he told a commenter that Yahoo has "killed a lot of good startups, wasted a lot o ... / 1259195280|%e %b %Y, %H:%M %Z|agohover
  • To Sell or Not to Sell: Silicon Valley Acquisitions Market Heats Up | Fast Company / One of the Valley’s recent poster boys for this phenomenon is Joshua Schachter, who sold his social bookmarking service Delicious to Yahoo in 2005 for a reported $30 million. This summer, on an online discussion board, he told a commenter that Yahoo has “killed a lot of good startups, wasted a lot o ... / 1259195280|%e %b %Y, %H:%M %Z|agohover
  • The Entrepreneur Spotlight: Michael Arrington / Image: Courtesy of Joi TechCrunch.com is a name very familiar with most tech enthusiasts and internet entrepreneurs. TechCrunch is a technology, social media, and internet start-up focused blog that now attracts over 3,000,000 visitors monthly! For this reason and many others, this week in the spotl ... / 1259181360|%e %b %Y, %H:%M %Z|agohover
  • Delicious 支持帐户与已有 Yahoo! ID 合并 / Delicious（美味书签）10月底起 支持 Yahoo! ID 注册新帐户，并表示将在几周内整合到雅虎帐户中。现在，整合工作已经完成，用户可以将现有的 Delicious 帐户和已有 Yahoo! ID 进行合并，就像当初的 Flickr、MyBlogLog 一样，整合到雅虎帐户中。 要进行帐户合并，请登录 Delicious 后台，在设置中按指导进行操作。请放心，帐户合并后，你的个性网址和内容都不会丢失，只是登录的用户名和密码改变了。而且要注意的是，合并是不可逆的，请谨慎操作。 另外，用 Yahoo! ID 注册的新用户，及合并后的用户，你的公开书签将自动更新到 Y!Update ... / 1259125680|%e %b %Y, %H:%M %Z|agohover
  • Will the Ace Hotel embrace the innovation community? / Almost overnight, the Ace Hotel lobby has become something of a phenomenon. On any given day, you’ll run into an actor, a fashion designer, a model and—randomly enough--an tech entrepreneur. Just this week, as I was taking meetings in my relatively new role on the First Round Capital investment team ... / 1259100000|%e %b %Y, %H:%M %Z|agohover
  • Memepool versus Twitter / Memepool – Desde de a Era TCP-IP-olítica, os sites que fazem curadoria estão entre os mais populares da internet. São publicações cujo principal objetivo é descobrir e compartilhar links. Alguns dos mais visitados existem há cerca de 10 anos —como o Boing Boing e o Slashdot. Mas, de 1998 a 2008, o M ... / 1258983360|%e %b %Y, %H:%M %Z|agohover
  • Flickr co-founder tries his hand at another Web startup - Globe and Mail / T he last time Stewart Butterfield invented the future it was by accident. In late 2003, his Vancouver startup was almost out of money and it had to abandon work on Game Neverending, a Web-based video game heavy on social interaction. The nine-person ... / 1258790100|%e %b %Y, %H:%M %Z|agohover
  • The Entrepreneur Spotlight: Reid Hoffman / Image: Courtesy of Joi LinkedIn is a popular business-focused social networking site for people in any profession. Millions of visitors flock to the site each month to update resumes, look for jobs, and communicate with past and current colleagues. LinkedIn now gets millions of visitors each month a ... / 1258655160|%e %b %Y, %H:%M %Z|agohover
  • Herramientas online para calificar y compartir favoritos con otros cibernautas / Las herramientas online para calificar y compartir favoritos con otros navegantes. ¿Qué son y cómo usar los servicios de Delicious, Reddit, StumbleUpon, Digg, Menéame y más? El siguiente es un artículo publicado en La Nación de Argentina, miembro del Grupo de Diarios de América, por el periodista Ri ... / 1258561320|%e %b %Y, %H:%M %Z|agohover
  • Essay: Social Media in the Classroom / Abstract With the rise of Web 2.0 social media has exploded on the internet. It permeates almost every aspect of your internet experience. The biggest question here is how can we utilize social media to enhance our online and offline lives? I have always been interested in how social media can help ... / 1258551060|%e %b %Y, %H:%M %Z|agohover
  • APIs In The Late Afternoon / After our weekly team meeting yesterday afternoon, I hopped into a cab to the far west side of manhattan to attend the Business of APIs conference. In the cab, I opened socialscope on my blackberry to check into twitter and saw this tweet from my partner Albert: Love APIs -- so excited about @ fours ... / 1258455960|%e %b %Y, %H:%M %Z|agohover
  • joshua's blog: on url shorteners / "But the biggest burden falls on the clicker, the person who follows the links. The extra layer of indirection slows down browsing with additional DNS lookups and server hits. A new and potentially unreliable middleman now sits between the link and its destination. And the long-term archivability of the hyperlink now depends on the health of a third party. The shortener may decide a link is a Terms Of Service violation and delete it. If the shortener accidentally erases a database, forgets to renew its domain, or just disappears, the link will break. If a top-level domain changes its policy on commercial use, the link will break. If the shortener gets hacked, every link becomes a potential phishing attack." / 1238971941|%e %b %Y, %H:%M %Z|agohover
  • Joshua Schachter /

    Joi posted a photo:

    Joshua Schachter

    "Deconstructing the Stonehenge before we accidentally summon something terrible."

    / 1215878268|%e %b %Y, %H:%M %Z|agohover
  • Foo Camp 2007 /

    Laughing Squid posted a photo:

    Foo Camp 2007

    See the blog post for more info: Foo Camp 2007

    This photo is licensed under a Creative Commons license. If you use this photo within the terms of the license or make special arrangements to use the photo, please list the photo credit as "Scott Beale / Laughing Squid" and link the credit to laughingsquid.com.

    / 1182738140|%e %b %Y, %H:%M %Z|agohover
  • Loaf / / 1179322420|%e %b %Y, %H:%M %Z|agohover
  • Newsvine - joshua-schachter / technology, google, del-icio-us, joshua-schachter, yahoo, industrial-relations. 1. 0 ... We just got confirmation from Joshua Schachter, the founder of delicious, that ... /
  • Flickr: joshua's Photostream / Flickr is almost certainly the best online photo management and sharing ... blogged at joshua.schachter.org/2008/11/ove rclocking-lecture.html. All rights reserved ... /
  • joshua schachter (joshu) on Twitter / anjaleef Lexi loves you too.about 9 hours ago from web in reply ... Name joshua schachter. Web http://joshua.sch... 318 Following. 4,723 Followers. 211 Listed ... /
  • Joshua Schachter Profile / In January 2009 Joshua Schachter joined Google. Joshua Schachter is the founder of delicious, a popular bookmark-sharing service founded in /
  • Joshua Schachter / Joshua Schachter is the founder of several Internet companies, including social ... Joshua Schachter Professional Profile. Past Projects: ... /
  • joshua's blog: overclocking the lecture / joshua schachter's blog. Previous Entry: amateur economist. Next ... Posted by joshua on November 2, 2008 12:14 AM. Comments. What's the ... Joshua ... /
  • Technology Review: TR35 / From MIT. Information on Emerging Technologies ... In 2001, a wonky Wall Street quantitative analyst named Joshua Schachter had a problem. ... Joshua Schachter ... /

Backlinks

Social bookmarking

BlinkListblogmarksco.mmentsconnoteadel.icio.usdiggFarkfeedmelinksFurlLinkaGoGoMa.gnoliaNewsVineNetvouzRedditSimpySpurlWistsYahooMyWebFacebook

Footnotes
Page tags: del.icio.us flickr people technology yahoo
page_revision: 2, last_edited: 1209051457|%e %b %Y, %H:%M %Z (%O ago)
EditRate (0)TagsDiscuss History Files Print Site tools+ Options
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License