Thursday, September 07, 2006

Dual Filesystem/Mail Server

System administrators do their best to discourage people from sending large files via email. It hogs resources that need to be used for quickly sending short messages, and mail clients aren't generally made to handle lots of large attachments. I think it would be wonderful to have a system that completely rethought the idea of email and shared file storage, and combined them with some of the ideas behind version control systems.

If we imagine everything as data and links, emails become text data with links to other files that are normally called "attachments". There are many different types of links — the metadata on the email (like to/from/subject etc.) would be separately stored and linked to using the respective link types (a "to" link, a "from" link, etc). Forwarding turns into the act of identifying a new recipient for an email and creating a link to them. Replying would entail a link to the replied-to email. "Recieving" an email would simply be recognition of a "to" link associated with your address. If someone would like to modify the document "attached" to an email, it would be edited locally and then added as a branch of the original version — ready for merging if others agree on the changes.

The strength of this would be in a corporate or academic environment. The difficulty comes in when you get people from the "outside" replying to your email with something that is hard to automatically recognize as a "reply", etc. Handling permissions is something else to think through.


Jason said...

This is a beautiful way to expand the Memex and obsolete CVS, SVN, and email all at once.

Permissions aren't so difficult as you might think, provided careful consideration of a standard and rethinking the purpose of a mail server (rather, you may want a combination of mail server and web/gopher server for something like this).

Kyle said...

I think Remail is getting closer, but they're still thinking about email as just email.