o So what is a message (and consequently, what can you do with it)?

o To a first approximation, a message is a short text string, posted by a single user, to a designated message pool.

SYSTEM META-DATA
o But there is also a lot of metadata that's automatically associated with the message:
     -- Sender
     -- Posting timepoint
     -- Group (or pool)
     -- is this a reply?
     -- if so, then to what message?
     -- etc.

USER-SUPPLIED METADATA
o There is also metadata that the user can add at his/her discretion:
      -- tags
      -- directed recipients (via @username)
      -- expiration timepoint?

PAYLOAD
o I suggest that we also allow users to attach "payloads" to messages.

o One form of payload is a URL.  A URL is a long text string, that if contained in the message body would make the message too long.  So we should make it possible to select a run of text in the message to use as the "name" of the URL, then to define the text of the URL elsewhere.  There could be two UIs for this:  For the novice, let the user type the URL in a separate text box.  For the expert, let the user use a special syntax to type the URL inline with the message body.

o Another type of payload would me an email address...

o Another type of payload could be a file...

o In all cases we might require that each payload have a run of text in the message body to act as the name, anchor and access point for the payload.  payload names might be styled to look like HTML links; and clicking on them might invoke the payload (opening a link in a new window or tab, opening an email address in the user's mail client, downloading a file to the user's computer, etc.).

o It should thus be possible for a message to have an arbitrary number of payloads.

o If we require that every payload have some "name" in the body of the message, then it should be easy to copy and paste these names (and thus the payloads) between messages. This would be useful, for example, when you want to share a file or a link from a message you received with another user; or to include it in a new message you are sending out.

FILE PAYLOADS
o My first idea about payloads that are files is that the ESME server should act like a file store and forward server.  As long as there is any message in any pool that references a given file we should store it, and allow it to be retrieved whenever a user asks for it.

[Daniel] Good point: if we see this extension, we should provide an interface for virus scanners.
Another one: if there is a library to shorten urls by default, we could incorporate it here.

o Privacy and security is, to a first approximation, enforced by the group pools:  if a file is attached to a message, it can only be accessed by users in that pool.  If a user chooses to copy the name of (and hence a link to) a file and to paste it into a message posted to another pool, then it becomes available to that pool too; at the responsibility of the user.

o One might ask how to remove a file from circulation once it's been attached to an intial message and uploaded to the ESME server.  Once might ask if the file has an owner, who can get a list of his/her files and force them to be deleted.  Reasonable questions.  But I'm wondering if it makes sense to treat files the same way we do URLs. Each URL points to a resource (typically a file of SOME sort) on the internet, and once published there's no way to retract the distribution of a URL string.  So maybe we could treat files the same way....

[Daniel] How would it be if we supply a personlized list of documents posted and an option for the user (and the admin) to explicitly delete a certain file. 

o Or we might say that when the original message either expires (because the sender put an expiration timepoint on it) or is purged from the system (because there's a server policy in place that purges all messages older than a certain age), that only then does the file get deleted from the file store.

[Daniel] We should provide a means to archive conversations from ESME.

TEXT MESSAGES, ETC.
o It's easy for a payload reference (in essence, perhaps just a URL) to be embedded in the message string itself if the message string is HTML.  If so, then we embed URLs as part of anchor tags and the web browser automagically displays just the name of the anchor while carrying with it the full URL string.

o On the other hand, what happens when we forward a message to a non-HTML-based system; such as cellphone text messaging (SMS)?  In these cases we'd have to strip out the payload, and perhaps just insert a payload stub -- a special symbol that means "there used to be a payload attached to this word", etc.