Seeking suggestions for a FAQ

I am planning to put together a Frequently Asked Questions (FAQ) page on Kerika. We haven't done very much in the past in terms of providing user documentation (most people simply email me when they have a question), but as we get larger we need to get better organized.

If you have suggestions for items to include in this FAQ, please let me know!

Enterprise version of Kerika

The second question I got to my earlier post was:

Q: Will the server side technology ever be offered to companies? Kerika looks like it would be useful for my company but we can't use any outside application server companies because of security reasons.

Yes, but not in a classic enterprise software style... Here's how Kerika works right now: our storage server is actually just another Kerika application that happens to run without a user interface or have any particular user associated with it -- what techies might call a "headless peer". With the exception of not having a user interface, its innards are the same as what you would run on a Mac or Windows (or Linux, once we get around to building a RPM!).

The storage peer acts as a silent member of every project team: you cannot deal with it directly since it never shows up in the user interface. If you update a shared object and one or more of your buddies is currently offline, your Kerika peer simply passes on the updated object to the storage peer, to act as a kind of proxy for your absent buddies. To do this, it takes the original object and wraps it in a new message addressed to the storage peer.

When the storage peer gets this message, it unwraps it to find a message that's intended for another peer (i.e. your absent buddy). It then holds on to that message until your absent buddy comes back online again, at which point it sends the message to your buddy. Once your buddy gets the message, the storage peer discards its messages. (Which means that unlike email servers, our "storage server" never keeps messages any longer than it needs to: once your buddies get their updates, the messages are scrubbed from our server.)

In the "near future" we hope to do a wonderful enhancement to this basic structure: you will be able to start up your own storage peers, on any machine that you have lying around that's Java-capable and reliably connected to the Internet. You will be able to designate which storage peers your computer can use, and set up private or "dark" networks where your data never leaves a trusted machine: the ring of trust would include your machine, any machines you have set up as storage peers, and your buddies.

This could be used by anyone who wants greater privacy: all you would need is at least one machine that can be accessed reliably on the Internet, which pretty much means having a fixed IP address.

The best part of this vision is that it isn't classic enterprise software:

• Everyone -- not just big companies -- would have access to these features, so long as they can set up a spare machine to act as a server.
• You can easily set up as many servers as you need.
• There won't be any need for consultants or systems integration staff: everything will be as easy to set up as the basic application is today -- you just download and double-click and you are on your way.

The rendezvous server at kerika.com would still stay in the picture so that we can control registration and billing, but you would have completely private networks where no one sees your data. Greater privacy, in fact, than you can get from email!

Sounds great, doesn't it? So why haven't we done it already...? Well, it's a question of resources. We are a typical startup that needs to stretch its dollars and we have a couple of other items we need to roll out in the next month or so that are higher priority. Once we get that done, this is next on the queue.

Of course, if some company were willing to pay us some money up-front to get the development done quickly that would certainly change our priorities...

Kerika on Linux

A comment to my last post included two questions, which I would like to answer separately...

Q: Did you ever get an offer in regards to making a Kerika/Linux rpm? I would like to test it out.

A: I didn't get an offer to make a RPM, although one person did suggest that I create a partition on my PC using VMware and then run Fedora on this.

This was an interesting suggestion, but not an entirely practical one since I don't have the Linux expertise myself to take on this job.

I know that Kerika does work on Linux because I had a user in Australia take the jars and simply copy them into the relevant directory -- and everything worked just fine! So why don't I just zip up the jars and post them on the site? Because I need to have the click-through license agreement in place before giving people the code or else I will get strung up by my lawyer. With the fellow in Australia I went through a laborious process of having him print out the EULA, sign it, scan it and then email me back the signature -- not a process that would scale up very well! I also want the process of copying the jars into a standard set of directories to be as painless as possible.

Good news is that I might be able to get a Linux package done within a month: I have a developer working on some networking improvements that has a Linux box so maybe I can get him to put together a RPM for me once he is done.