Atom K

A documentation prototype for next generation messaging

Core concepts

• Interoperability
  • A general messaging interface for messaging systems, not just email. Twitter, facebook, et al. should be optional means for messaging.
  • Backwards compatible with email.
• Messages and calendar events are one in the same.
  • Time has proven that email and calendar need to consistently work together, so why should their particles be different things?
• Supports the sending of HTML5 content.
• Possibility for a commercial standard in addition to open standard, just as Twitter is the commercial standard for tweets.
• Streams as subscribable endpoints
  • Replaces the awkwardness of periodical emails.
  • Vendors can write periodicals to streams, which users can attach (subscribe) to or detach (unsubscribe) from.

Syntax

Slashes (/) are used for separating a user from the domain, just as email separates with an @.

• to: john/example.com
• to: jane.doe/example.com
• to: alex-miller/example.com

For the commercial standard, user could use extensionless domains

• to: john/example
• to: jane.doe/example
• to: alex-miller/example
• The owner of example.com would need to successfully register "example" as a domain in the commercial application.

3rd party non-email messaging systems tap into the "@" prefix

• to: @username/twitter.com
• Default domains can be set via client app to omit the domain
  • to: @username

Message Types

Example Subject	Email Type	Email Meta Keyword
"Hi, Sweetie"	Message	None, default
"Charity News Weekly"	Periodical	periodical
"Confirm your registration"	Account-Website Handshake	handshake
"Payment Accepted"	Read-only notification	notification
"Note to self"	Personal note, file, or snippet sent to self to be saved or transfered between devices	storage

How this is solved

<meta 
  name="email-handshake" 
  content="
    description: 'Please confirm your account with Lab95', 
    url: 'http://lab95.com/confirm/SX29Sfd948dfjWss301LK'
  "
>
<!-- Optional -->
<meta name="email-meta-version" content="0.9.0">

With a simple tag denoting the type of email, email programs can sort by this universal protocol. Read-only messages can be put in little dialogue boxes. Periodicals can be grouped into newsstand organizers. It's really up to the email client.

Why would anyone do this?

• Better for senders
• Better for users
• Backwards compatible
• Unobtrusive
• Pretty cool implications (below)

Greater visibility is a collary of better organization. A sender including this meta tag isn't necessary, but would move their message into the user's field of relevance. And, of course, it's better for the user that emails are put into context. Instead of relying on an email program that "sniffs" the content of the email to guess a proper category, each message can register itself to the right place. Because this is valid usage of HTML meta data, it's unobtrusive and shows itself only to the discretion of the email client.

Potential User Experience Improvements

Here are some ideas for ways email clients could take advantage of the syntax:

periodicals can be set to automatically archive all but the last unread.

Emailing a photo to oneself could automatically be sent to a companion online storage folder, instead of mixed in with other messages and junk mail.

handshake emails could prompt desktop clients to open a UI element such as a Growl message to take the user right to the confirmation page. No need to check the email itself

Different types can be sorted into respective feeds. This means you can read through all your periodicals on the subway, your messages at work, and clear all notifications at once.

Unsubscription to newsletters can be delegated to an actual UI element in the client program. On the same token, being less annoying, users will be less likely to want to unsubscribe.

Where to go from here?

This is an open source project made for the advancement of humankind. It's a simple two way street: Email senders can start writing this meta data automatically. Email clients can impress their users with the ability to read these kind of emails. Just use the syntax in the API document of this repo.

Contributing

This branch is a starting point. Please send pull request to the 1.0 branch where a stable version of the API is in the works. Senders and sendees can still use 0.9.0 but should version using email-meta-version. (See API.md)