<img src=“https://travis-ci.org/nelsonblaha/hermes.png” />

Hermes is a response to the changes in messaging and notifications likely to come with wearable technology over the next few years. The way we handle messaging today is not designed for an environment with several screens, nor does it properly take into account contextual information when deciding when and how to present messages.

Objectives

• Deliver messages when they are relevant, according to user preferences and externally-determined contexts.

• Coordinate message delivery across devices to avoid redundancy.

Message delivery behavior is based on rules that act on traditional filter contexts:

• Sender of message

• Time received

• Text filters

• Originating service (e.g. Twitter, Gmail, Reddit, Facebook, Google Voice, XMPP/Jabber)

Third-party services will use a RESTful API to supply additional context. Hermes could conceivably consider the following when determining how to present messages:

• “Is user wearing Google Glass?”

• “Where is user? Work? Home?”

• “Where is user located relative to others? Is he face-to-face with anyone? Is his microphone indicating an ongoing conversation we should avoid interrupting?”

• “What browser tab is user active in, and what kind of activity does it suggest? Is he studying and not to be distracted by low-priority messages?”

• “Is user currently riding a bicycle?”

• “Is user walking?”

• “What events are occurring right now on user’s calendar?”

• “Is user asleep?”

Arbitrary contexts may be added to messages by the sender, and the recipiant may choose to take those attributes into consideration in rules as well:

• Sender’s location

• Priority or urgency

These contexts will be made available to third-party context services as well. A sender could, for example, include credentials to access their location for a limited time.

Syncs messages’ read-unread status across multiple clients, such as:

• Web client

• Browser extension

• Google Glass, Pebble, other wearables

• Android/iOS

• TV

Clients such as televisions or cars could easily be made to handle messages for multiple users simultaneously

Rules generate one or more presentations for the messages, typically one of three archetypes:

• Blip: momentary “pop-up” with variable display length. Optional explicit-dismissal requirement.

• Inbox item: user defines an unlimited number of inboxes, which require explicit dismissal of messages. (work, todo, leisure reading)

• Stream: like an inbox, but without explicit dismissal. Useful for combining low-priority leisure feeds such as Reddit, Google+, Facebook. User can dismiss items to ensure that the feed is not repetitive. Items could be made to expire after some specified period.

On the backend, these are really simple Presentation and Inbox objects, differentiated only by Inbox attributes that define their behavior.

Clients may offer the user the chance to perform Actions in response to Presentations:

• Reply (and other traditional actions)

• Send to another inbox for later action (yields menu of inboxes)

• Share with Person (menu of People and their contact methods)

• Share with Service (menu of social network services)

• Third-party RESTful actions user has added

Presentations may carry with them instructions to the client to display certain response actions. (“Make this a to-do item”. “Share this on all social networks”.) Hermes may use the message’s context or some context about the user (or both!) to decide which actions should be most prominent.

Example use cases of Hermes:

• Show Glass popups of overnight work email when entering work area.

• While at work, show a Glass popup for each new email along with the normal work inbox presentation.

• When I’m driving (third party context), add to all incoming texts a quick-reply button to send back a Google Maps driving-distance ETA to the sender (generated by a third-party web service) When I’m not driving, don’t include this action in the quick list of actions, but hide it in ‘all actions’ to reduce clutter.

• While at an event, deliver tweets with the relevant hashtag in Glass (third party application).

• Combine Reddit, Google+, Facebook into one stream the user can scroll through at will. For the user waiting in line, present items from such stream one at a time, without repeating a dismissed item.

Unorganized other requirements:

• The user should be encouraged to subvert the Message object as a todo-item. This should not feel hacky, as when one sends one’s self an email as a reminder.

• Clients are encouraged to provide a shortcut for each message that quickly displays all rules affecting that message, so that users may have awareness of the logic structures they have built and easily remember and change them.

• Intelligent defaults are important. A few typical inboxes exist by default, and as services are added to the user’s Hermes logic they behave similarly to their standalone counterparts from the outset.

Here’s what needs doing:

• Android, iOS, Chrome etc developers to write clients. I’ll write Android eventually if no one else does.

• REST ‘contexts’ (web services Hermes can check or send messages to know when to behave differently for the user). The first obvious one is Google Latitude, IMO. If no one else takes this on, I’ll be modifying my own project ifttt-latitude.herokuapp.com for the purpose.

• Rails devs to write in new sources of messages (I’ve written RSS via @PaulDix’s Feedzirra, Twitter is next on my list via Omniauth)

• AJAX on the front end for a prettier web client and easier rule creation.

• Most challenging for me, Hermes as it’s written now needs a very tricky ruby sanitizer. I’ve decided to use Ruby to represent message-processing logic… Ruby that’s written by the user. It allows Hermes to have incredible flexibility, but is extremely insecure. The user cannot be allowed to write raw ruby that’s evaluated, so something that converts the permitted (and layman-friendly) syntax to safe Ruby is needed.

See mechanics.txt for an explanation of Hermes’ inner workings, to get started.