A new look to our site

In preparation for our version 1.1 release, we have been updating elements of our website as you may have noticed. This new version will have many improvements to the user interface and performance, as well as new functions (such as our Private Storage Server). This will mark the coming of age for Kerika: the end of our official beta period and a transition to a very affordable subscription service. Stay tuned.

Apologies...

I realized yesterday afternoon that our "rendezvous server" died quietly in mid-day. I am still trying to figure out exactly what happened, but in the meantime please accept my apologies for the interruption in service...

Want a test drive?

As mentioned in my last blog entry, we are getting close to releasing our "private storage server" product. We would like to have a few small groups act as beta testers before we unleash it to the general public. If you are interested in participating in our beta test, please contact us.

Your Own Private Idaho

In my last blog entry I talked about how the Kerika storage server works in general, and I concluded by pointing out that we are in the privacy business, not the advertisement business!

And if you value your privacy, I have some great news: we are close to releasing our storage server software as a separate product! This means that you will be able to run your own private storage server, on any machine that you have that's reliably connected to the Internet. You don't even need to have a fixed IP address for running this server -- just make sure that:

1. You hook it up using an Ethernet cable, not wireless, since wireless connections can be flaky.
   


2. Don't let your computer doesn't go to sleep overnight, which would make your server inaccessible. (This can usually be done by setting your power management features on your computer to not let it go to sleep due to inactivity.)


3. And, finally, make sure you have an updated Java environment for the server computer, which is as easy as visiting www.java.com.

Setting up your own private storage server will provide great privacy: now you can be sure your project files and Idea Pages never leave the "ring of trust" that consists of your machine, your buddies' machines, and your private storage server. If you update a shared item and some of your buddies are not online, these updates will wait for them at your private storage server, not the public server at Kerika's data center. In effect, you will be able to run "dark" networks that are not easily visible from the outside.

Every storage server can be configured to work in two modes: Open and Restricted. The public storage server at Kerika's data center runs in Open mode, which means that it will allow any users anywhere to connect to it.

If you run your server in Restricted mode, you can control just who else can use the server. There are a couple of ways in which you can do this:

1. Specify individual Kerika IDs that go on the "Allowed" list.


2. Specify an entire domain, which means that any Kerika ID that is based upon that domain is automatically added to the "Allowed" list. For example, if you are running a company called Acipio, you could add "acipio.com" to the Allowed list. This would allow joe@acipio.com and mary@acipio.com and arjun@acipio.com (and so on) to connect to the server. Anyone whose ID does not end with "@acipio.com" would not be able to connect to the server.

And even when you allow an entire domain, you can also maintain a separate "Prohibited" list where you single out individual Kerika IDs that you don't want to allow. For example, you could add "acipio.com" to the Allowed list and simultaneously add arjun@acipio.com to the Prohibited list, which means that everyone whose ID ends in "@acipio.com" -- except for arjun@acipio.com -- would be able to connect to the storage server.

Pretty darn nifty, if you ask me...

Kerika's Storage Server

Kerika's storage server, which currently runs on our data center, works in a very simple way: if you are update a shared item (a page, a document, a task, whatever...), and some of your buddies are not online, they would normally not get your latest changes. That's how "pure peer-to-peer" technology works -- just think of instant messaging as an example: if your buddies are not online, you can't chat with them.

This can be a very significant problem when you have a team of people that are distributed by geography, or where you are working with people with different work habits (and sleep cycles!) than yourself: the chances that everyone is online at the same time can be very small indeed.

Kerika solves this problem very simply: we have a special peer that we call the storage server that runs all the time at our data center, just waiting to step and be helpful whenever you need to pass on an update to an absent buddy.

Here's how it works:

Your machine always knows when your buddies are online or not: we have another server at our data center, which we call the rendezvous server, that hooks you up with your buddies. If you update something that you are sharing with a bunch of other Kerika users, your machine can automatically detect if some of these buddies are not online. If anyone is missing from your team, your machine packages up a message for your absent buddy and sends it to the storage server to act as a forwarding service.

The storage server gets the message from your machine and unwraps it just enough to figure out who it is intended for: i.e. the names of your absent buddies. It then sits waiting for your buddies to come back online, which could minutes, days, or weeks later.

Whenever a Kerika user comes online, their computer first checks in with the rendezvous server to let the Kerika community know that this user is now online. The rendezvous server lets this user's machine know if any of his or her buddies are currently online, and if so, how to reach them (i.e. it tells each user the IP addresses of the user's online buddies).

The users' computer also checks in with the storage server at our data center to find out if there are any messages waiting for him (or her).

(This is just like coming back to your hotel after a day's sight-seeing: you ask the front desk or concierge if there are any messages waiting for you. Checking in at the front desk also lets the hotel know that you have returned, so if anyone calls and asks for you they will be connected directly to your room.)

All of this works silently in the background: you, as the user, need never concern yourself with the details of how Kerika magically connects you with your buddies regardless of where they are, what sort of machine they are using, or even whether they are currently online or not!

If you do have any messages waiting for you, the storage server hands them off and then gets rid of its local copies. This is a critical point to note: the storage server does not keep messages any longer than necessary: once the absent buddy shows up and gets his or her messages, the storage server cleans out its queue!

So the bottom line is that the storage server only gets involved when it needs to, and stays involved only for the minimum time involved. We do not have any humans or computer programs running on our data center that scan these messages, because we are in the privacy business not the advertisement business!

Peer-to-peer vs Hosted Services (or why we are not a Web 2.0 company)

The notion that all software will eventually be delivered as hosted services has become something of an idee fixe du jour among the technical punditry. Everyone is scrambling to get on to the Web 2.0 bandwagon, in ways that are reminiscent of companies rushing to add the ".com" moniker to their names just a few years ago. If you aren't delivering a hosted service, it is assumed that you "just don't get it".

So, why isn't Kerika a hosted service yet? Why are we bothering to deliver an application to our users instead of just creating a bunch of jazzy web pages like every other bubbly entrepreneur in flip-flops?

The answer is simple: our prototypical user has a laptop and tends to move around a lot. Sometimes he is working from his office, sometimes she is working from a coffee shop, sometimes from home or a commuter train. And our user doesn't always have reliable and cheap Internet access: even though we have a proliferation of hotspots across urban areas, and wireless access through cellphone providers, these are not quite ubiquitous yet, and they are certainly not cheap.

In this scenario, we feel our users are best served by always having a complete set of project files and artifacts, without having to rely upon gaining access to a remote server. Kerika's peer-to-peer technology ensures just that: every member of the project team always has a complete set of project documents.

Another problem with hosted services is that very few people are always self-disciplined in not keeping duplicate files on their laptops. We have observed that even where there is an "official" central repository of files, e.g. a SharePoint portal, individual users tend to keep duplicate versions of key documents on their own machines, and these inevitably get out of synch with the "official" versions that are sitting on the central servers.

So, if people are going to keep local files anyway, why fight our users? We prefer to support our users the way they actually work.

Kerika's peer-to-peer model offers a couple of other key advantages:

1. There is no single point of failure. If your machine gets trashed, the project team can continue working, and you can restore all your old files from your teammates. In a hosted model, if the server is down, the project comes to a halt.
2. Greater privacy: the Web 2.0 business model is implicitly based upon serving up "targeted advertisements", which inevitably means a loss of privacy. All hosted services companies that offer so-called "free software" have automated ways of scanning your emails, your documents, everything that you do so that they can figure out just what advertisements they should display -- after all, this is a critical element of the Web 2.0 business model. With a peer-to-peer model you can work within a "ring of trust" consisting of machines and people that you select as part of your workgroup.

This is not to imply that we would never offer a hosted version of Kerika in the future, but for now, we think there is a good argument to be made in favor of the peer-to-peer model.

What do you think?