ilya haykinson >> blog

This weekend is the sixth instance of BarcampLA, and for the fifth time I’m presenting. This time it’s a somewhat technical topic - multithreading. Here are the presentation slides:

Scott Hanselman in this tweet (and on his blog) proposed a sort of a distributed tweet server to serve as an alternative to Twitter. He points out that this has been proposed before, and even implemented to some degree.

On the surface, Twitter is a feed of messages — combined with many ways of getting messages to the service, as well as many ways of getting messages from the service, plus a framework for subscribing to others’ feed and seeing others’ friends’ feeds.

A single user can certainly host their own feed, and (via some soon-to-be-established) microformat link to this feed. Assuming that we discount the issue of maintaining your own feed, how will people find your feed? How will they subscribe to it in a way that incorporates the rest of their friends’ feeds? How will replies and direct messages (both excellent features of twitter) be implemented in such a model? Let’s dissect these in more detail.

Finding a feed

The low-tech, least-usable way of doing this is, of course, to just tell the reader to find the publisher’s site, find the tweetfeed link, and add it to their reading software. In practice, this won’t really work: nobody wants to search the net to find your tweets. My suggested solution: a set of web sites where users can register; a federation of registration servers, of sorts. So ilya@mytweetserver.com may be my default indexing location; yours may be johndoe@leettweets.net. If each server publishes a list/directory of nicknames (usernames) in a standard format, we can build search engines to search these registries. In theory this will mean some networks will be effectively private until a search engine finds them, but such is the normal mode of Internet operation anyways.

Subscribing and reading

Feed consumption need not be anything fancy. Something akin to online or offline RSS readers will be enough, albeit probably optimized for very short messages without bodies. When you subscribe, you subscribe to the tweetfeed of the publisher; your reading software will integrate all the tweets into a single, coherent timeline.

Replies / direct messaging

In order to support replies, we need to determine how we will address users, and how we will deliver the messages. I’m commingling replies and direct messages here as follows: to me, replies are public messages plus notifications to the target user that a new reply has been created, while direct messages are notifications to the target user that contain the reply, and the reply is not posted to the feed.

So how do we address users? The @user syntax is a very convenient one, so we can try to piggy-back on that by having @user mean user@SERVER — and the SERVER is my default registration server. If I want to address a user on another server, I can always use the fully-qualified @user@someserver.com. So for example, let’s imagine that there are three users in the world: john@serverA, jane@serverB, and jeremy@serverA as well. When john wants to reply to jeremy, he simply needs to start the reply with @jeremy, since jeremy is a user on the same server. When replying to jane, however, john would need to start the reply with @jane@serverB. Perhaps client software can make this easier via address book lookups. When john’s tweetfeed is published, the feed contains john’s default server name, serverA. A client consuming the feed would know how to resolve the usernames, and thus where to look up these other users’ feeds.

So that’s addressing, now what about delivery? This may be approached much like trackbacks: a standardized way of submitting a short snippet of data to your registration server. In a way, your registration server is your notification server. Some servers may be configured to forward the message on to your own tweet feed engine as an actual comment-like post; others may email you; others may publish a reply-feed that you may then consume with your own reader. This will then solve the problem of the privacy of direct messages as well — your private reply-notification and direct message feed will only be known to you.

Finally, we need to address spam. In a distributed system, combating fake-reply or direct message spam may not be trivial at all. My initial thoughts are to a) force reply messages to include a computed hash of some value from your feed, or b) have the reading software filter out any messages from people that it knows aren’t your friends, and requiring your friends to include a public key in their feed and to sign their messages with their private key.

Conclusion

This may all be a bit overkill, but on the other hand may result in a nice, friendly Twitter-like service that doesn’t really lose any of the functionality that makes Twitter so attractive and even gains some capabilities to create private networks.

Oh yeah, and follow me at http://twitter.com/haykinson

Microsoft’s new version of IE will have RSS feed management based on the new Microsoft Feeds API. This API is also going to be used by the upcoming Office 2007, notably in Outlook.

This is actually a great development. I’ve been a big fan of using mail reader based feedreaders, and totally love the fact that now I don’t have to use third party software. What I’m not happy about is feed synchronization.

I fairly regularly use three computers: a desktop at work, a desktop at home, and a laptop that I bring back and forth. I run Outlook 2007 (beta, of course) on my laptop. However, I sometimes want access to my feeds on one of the other machines, whether because I quickly want to check one of the blogs, or because I find a site that I want to add to my Outlook reading list. But, being on another machine, I’m out of luck.

Outlook makers thought of this, somewhat. Since feeds get delivered into Exchange folders, I can actually just read the posts being retrieved by my laptop from wherever I can run Outlook. But what if I don’t want to run Outlook everywhere?

The solution has got to be feed synchronization. A simple service can receive OPML files containing your blogroll and then synchronize them across Windows devices. Run a small client software, and it keeps track of your feeds — updating any clients with changes from other clients. All your machines would of course start checking all your feeds, but that’s a small cost to pay for keeping your computing environments synchronized.

Requirements for such a service:

1. Create and manage an account
2. Support initial import of an OPML file
3. Configure itself as either a reader only, or full synchronizer
4. Regularly query the service and update the local Common Feed List with new feeds
5. Regularly query the local Common Feed List and upload any changes to the service
6. Support export of OPML file

It would really be best if a service like Bloglines just built an API for this; they already have OPML capabilities and have a feed-savvy account base.

Thoughts, anyone?

Yahoo just released a Creative Commons search — it lets you find web resources that are licensed under the various Creative Commons licenses. Way to go, Yahoo!
(read the annoncement on the Yahoo search blog)

del.icio.us is a very good social bookmarking site. It’s both a way to keep your online life organized, a place to see what others are interested in, and a method for information lookup.

It looks like this point isn’t lost on Microsoft. The MSN Sandbox site start.com seems to have a playtest version of an online bookmark management site — without the social aspects yet, though, but that could easily follow. The new site also seems to integrate with RSS in some ways. And only works in IE, for now. But it’s a “start”…

This is the second project from the sandbox site — the first, start.com/1, is an online RSS reader. This one is at start.com/2, and I suppose many people are pretty curious about what’ll pop up on start.com/3

Yahoo yesterday released their Search API. I’m joining the chorus saying that this is a Good Thing, for a few reasons.

• The application key is a really good idea Some applications like Google and Flickr require developer tokens. While a good way to regulate who uses your application, and curb abuse, the application token holds an advantage for a developer: it allows the application’s source to be distributed in a working state. For source-only applications (such as websites or scripts) a developer code is not possible to hide. Since the companies typically don’t want you to show people ”your” code, people have been distributing the source code with “INSERT_YOUR_TOKEN_HERE” instead of the actual token. In Yahoo’s model the application is easily distributable. The downside is of course that Yahoo has no way of knowing if I just stole an application code from someone else’s app. It also would allow the developer to register for a large number of application keys and query Yahoo using those keys in round-robin fashion. These are curbable abuses though, and the benefit to developers likely outweighs the downside of server management.
  
• REST API While REST is not the best way to access data (SOAP is definitely more structured, more standard), the REST model allows people using languages without good native SOAP support to query the service. I think it’s still really important to offer a SOAP interface, however — those of us using platforms with good SOAP support dislike having to hack around REST.
  
• Developer communication Unlike Google’s somewhat marketing-rich blog, the Yahoo folks actually have a real developer blog. They also have a Wiki — nice!
  

Add a high query limit to this list, and you’ve got a great service that definitely moves the web service evolution of the Net forward.

I’ve written a utility that syndicates CVSNT commit logs as RSS.
The idea is that it’s a lot easier to subscribe to an RSS feed of commits than to manually hunt through the repository, or to use a similarly-hokey commit emailer.

The software is still kind of raw, but if you are really missing this functionality then it might come in handy. It is licensed under the GPL.

I’m frustrated with FlexWiki — it’s a good system, but it lacks some features which I find ‘’so” useful on Wikipedia. For example, [[bracket links]] and the related lack of need to SmashWordsTogetherToMakeLinks. It’s far too techy for my purpose, which is to use a wiki as a way to keep documentation in progress.

I looked around for other wiki software. Mediawiki is an obvious candidate, being mature and by definition containing all the features I want. Yet it’s far too much trouble for me to install on our production systems (it’s a LAMP product, whereas our environment is WISA – Windows IIS SQLServer ASP.NET). Other wiki systems either look crappy or have no features, or are just as hard to install as Mediawiki.

So I guess I struggle with Flexwiki for now. Ugh.

Microsoft released their anti-spyware tool (it’s in beta, and free), and I decided to try it out. I’ve been a long-time fan of Lavasoft’s Ad-Aware software, but the Microsoft tool on first glance seems nearly as good. Lavasoft’s benefit is the software’s simplicity — install the thing, update to the latest definition file from time to time, and just run the scan. Microsoft’s software on the other hand seems to be more complex in its user interface but has features like background protection (with Lavasoft’s free version that feature wasn’t available), auto-updating, and a pretty usable interface.

Of course, my problem is that there’s far too much persistent software running on my computer now. Between Norton Antivirus, Google Desktop, and now this AntiSpyware tool, I have a bunch of things to disable or shut down when I want my tablet’s battery to last for a long time.