|LCCOM | Messaging | Space Station | Server|
Email is too hard, so lets junk it.
Thanks to Eric Murphy for discussions on this..
The question is, how do you manage files, attatchments, and even keep note of whats going on in a thread. And how do you do it securely? How do you transform messaging into something which creates a sense of community. How do you let workgroups collaborate; how do you let workgroups happen dynamically? Version Control?
Here are some interesting recent artcicles: On Smuggling P2P into the enterprise. (by Clay Shirky, VC and very good pundit..see www.shirky.com for his writings..)
On killing Email. This is by Andy Oram, OReilly editor..
I read these two recently, and this rung a bell..converging with something I read from Eric Murphy (jabberzilla.mozdev.org) at Eric's Thoughts
My thoughts started crystallizing, and this is what came out of it: Consider this, a application, for messaging, and a company selling it:
- A new messaging client based, say on the mozilla browser, using (a) http client suppoer (b) jabberzilla jabber client support (c) smtp client support Consider further a web server attatched to this client through protozilla, or better through a database which can server as a repository and message queue holder, and which supports transactional characteristics and triggers.
Consider a message in which dragging a
file right into the text flow to create a link to the local http URL, and
if you are behind a fireewall an upsteam server
which has both apache and jabber server.
Not an attatchment, that is, a link. The same can be done with message bodies, transporting only the headers, if desired.
- Separation of message format from transport; conversion of mail headers into XML..call it message. Transport may be http, jabber, or smtp(the regular). http between peers behind the firewall using web servers built into the http client, jabber with other users having the same client outside the firewall, SMTP with non-client users.
- All messages are html/xul, not text, and people not having ready access to client can use a crypto enabled plugin on a normal browser to get to their upstreamer (we've developed one for mozilla, soon for IE). People who dont have the client ought to be able to participate in a stripped down fashion by web based interface.
- Now consider the notion of a space created by each message, and further a more persistent space created for a group, the former space can be a subspace to this later space. Messages can be replyed to by choosing messages in the former space, much like the threaded jabber-slashdot. If users are online , then jabber can be used for instant communication in both the group based and message based space.
- The space is constructed out of database backed web stores at each participants machine. An "email/message" space is locally created on sending or replying to a message, group spaces need explicit invitations, just like Groove. Using events and event subscriber models, all subscribers to a space can have their views of the space synchronized. With the "attatching" of files to messages, and explicit dropping of files into group spaces which would produce an event that sunscribers to this space get, transmitted by http and jabber, as the case might be, one has a nice file sharining network. "Attatching" puts files into a context, so thats even better.
Emails can be "typed" to be event planning emails, discussion emails,
nosy list emails. what are the properties of some of these things..?
See: http://software-carpentry.codesourcery.com/entries/second-round/track/Roundup/ for Ka-Ping Yee's nosy roundup lists and tracking database ...
See especially sections 1 and 2 for more about roundup, and timedance event planning. As you can imagine such a system will make this very easy to do.
So this is a hybrid email-web-IM peer-peer solution. Filering can be group based, and even thread based. Far better than procmail.
- All messages, irreleavant of transport are signed and encrypted, and the client must authenticate the reader for the reader to be able to see the messages..messages can have the recipient necessarily sign on receipt too e.g. a subpoena :-) The web server on the fly createds a authentication domain for the messges attatchments, and the client automatically satisfies that auth domain..the user probably needs to log on to the client using a asymmetric key mechanism to start with, from which point onwards something can be done about generating space specifickeys....
- Due to the ability to share files and typed messages like event planners , and create bulletin board like structures in mail specific or group specific spaces, without system adm (IT) intervention, the app can spread fast in much the same way as ICQ. Say, the company maintains the global jabber, web servers used for upstreaming in talking to people outside the company and for external access which does not need to breach the firewall.
- The company produces servers with web and jabber and authentication built in which by now the IT department wants because everybody is using the client and because they want to be the message upstreamer. Now IT can put policies like no "exe" attatch downloads from internet where internet is not defined as having company crypto keys, so that cost of virus software goes down and ofcourse the hassle with viruses.
- So this "company"'s business model would be the selling of these servers, and charges for additional upstreaming space and bandwidth on its own upstreamers. This could be a role for jabber.com; though it is probably done better separately, so that jabber.com can deliever even better enterprise servers. No reason why this new company wouldnt act as a VAR for the jabber enterprise servers..
- The funny thing about spaces is they can also be used to organize ones own projects, ones information, ones surfing, ones weblog, into which im and msging tie in very nicely. One can even do big netnews type groups based on what cache consistency model you choose and how many upstreaming servers you have. So one can now bootstrap to the second generation Internet Client very nicely. Furthermore since the messaging interface is rich it can be integrated further with more detailed apps running on the web server portions of the clients to even do supply chain management type stuff which needs human or agent intervention. And more centrally to messaging, one would want to assciate messaging with certain granularity in documents, like eg editirs of a subsection of an article...