Here we describe the present state and future directions of the Transporter concept.
# Current Features
This About Transport Plugin provides interactive access to remote services that can read content you drop and create from it useful pages that appear ready to be saved or used at one's discretion. github 
Features include: * POST to a URL specified
# Task: - [ ] Transporter Tools - [x] Fix Flag Drop onto Transporter
# Suggestions
Suggestion:
We suggest that transporters are able to advertise a regular expression or list of regular expressions which match dropped url's - indicating that they are able to respond to a Transporter Drop.
We handle drops on the background which goes through a different path from Factory and Transport. It adds remote or ghost pages (Import plugin) to the lineup. It could also match available transporters and offer a choice of all those that match. This raises some questions.
Do we poll all Transport plugins to see if their transporters are ready?
Do we offer to try Transport plugins that haven't described what they are able to transport?
Do we worry about abusive Transports? What is the attack surface?
Do we offer a second chance if the first Transport doesn't satisfy the user?
Do we want to make more of the hamburger menu (≣) in the web page footer? Things that apply to the server or the neighborhood should be brought up from there.
Do we demand that transporters meet some uniform expectation of behavior. When will we know what that is?
Do we look for an experience more like Kaiten? How does its 'connectors' relate to our transporters?
A new (2011) navigation model for web applications that allows you to browse thru one or several applications in a single continuous space, much like wiki's lineup. site