User:Sj/coralline

(link from user:sj/internal and coralline-on- web)

It is common for a shared thought to reach the wrong audience because the tools by which senders and receivers cooperate to exchange messages are crudely discrete. This results in both sins of omission:

messages fail to reach people who would like to read them

and of and of commission:

messages reach people who would prefer not to receive them.

It is also common to regard the audience of a message as something fixed when the message is first sent or published. This attitude belies the ways that messages are used in practice.

Asheesh says CC uses Roundup (the issue tracker) to handle much of these features. 22:02, 19 April 2009 (UTC)

A coralline system

1. Let Flows be transcoding Message queues.
2. Let Messages evince Features.
3. Let each Message's Features be initialized by a Classifier defined on the Flow from which the Message became known.
4. Let Audiences
   1. search for and browse Messages by Features,
   2. create synthetic Flows by Comprehension, and
   3. create new bindings (e.g. of features to a message, of a classifier to a flow) at will or subject to notification, confirmation, or capability as appropriate.
5. Let typical Flows consist of mailboxes and feeds. (Fancier interfaces, e.g. to bug trackers, review systems, etc., can come later.)
6. Let every Flow carry with it an optional opposite reply Flow.

Principles

Here is a coral-like broadcasting system in line with principles that capture and preserve the intent of the creator[1]:

• Define messages in terms of topical tags defining their subject, origin, &c

  this is a way to specify how messages can be manipulated. not necessarily exclusive.

• Define the type of service/site a message comes from (email, trac, wiki edits, &c), along with their originator and a set of tags describing their content / context / originating intent.
• Define recipient profiles (similar to mailing list user preferences) according to what tags and tag-sets a recipient wants to find out about, and how aggressively updates are desired. (for instance : all topics related to XMPP and Sugar should be flagged in weekly summary-format for online review; all topics from or to Zdenek related to languages or dictionaries should be sent in their entirety without delay.)
• Automatically produce tags for each current named mailing list.

  automatically produce from-foo tags for senders? an advantage here would be defining the equivalence class of addresses which belong to a single sender and unifying their tags.

• Provide interfaces for
  • defining memberships and receipt/email-preferences for individuals
  • setting up a tag tree, indicating where a specific tag implies a more general tag as well
    • and the related detailed authority file associating tags with one another; recipients could indicate narrow vs. broad interest in a given tag
  • reviewing 'replies' that haven't been successfully passed on to the originator in question : because there was not yet a way provided to post pingbacks, for instance
  • defining a new source of input, scripts to extract messages and their metadata, and the proper way to send back notice of any replies

There are many ways in which this system can be recursive for maintenance : generating internal messages about events noticed that bear acting upon (including dealing with unsent replies, system bug and abuse reports, &c).

Some interesting features

• Support drawing in tags from external sources. Define a few privileged prefixes. For instance x-TAG could indicate a tag that came from some outside repository -- two different messages with that tag could have been tagged in different contexts. So x-library could apply to both book libraries, code libraries, and other ideas or terms referred to on some site with that name.
• Extract entries by polling and other mechanisms from sources that are not explicitly set up to produce tagged messages.
• Handle replies effectively : figure out how likely it is that the originator of a message wants a reply, and the level of detail that will be interesting : both from the level of significance of the reply and how normal anonymous or bot-generated replies are in the source context.
• Support entries that are associated with patterns of distribution and correspondence. An ack that a message is received might simply be one of many possible patterns: from workflows, confirmations and other transactions to links in a relayed collaboration.

  Possible support for time-limited responses, reminders, anniversaries, transactions waiting on input from all members of a group, &c.

• Support a variety of different sorts of receipt and response in a single shared meta-channel.

  A cluster of people working towards a shared end should be able to work closely with different personal channel preferences, time availability, and bandwidth for reading or writing.

• add yours here...

footnotes

[1] see related thoughts here.