First, whilst I did waste a few days coding an IRC bot to facilitate Tent:

* http://github.com/tav/scripts/blob/master/tentbot.py

I've decided that IRC is not quite the right basis for this. The
advantages are that it's there and some of us are very comfortable
with it, but the downsides are:

a) IRC is susceptible to network splits, which will render the service
inaccessible and out of sync.

b) Not everyone is familiar with IRC and has an existing client.

c) Not everyone is familiar with IRC authentication, /msg NickServ identity ...

d) It requires people to be on IRC as well as check the Tent site ...

I also briefly contemplated Twitter -- but the downsides are that
Twitter isn't really suited for "chat" -- it misses the "live" chat
element and the API limitations Twitter imposes makes this pretty nigh
impossible.

However, people tend to have a web browser and be familiar with
traditional login mechanisms. And live chat is easily possible as a
web app -- see Campfire from 37Signals for a much-used web-based chat
service.

So, Tent is a wholly contained web app. The ~user/links can also be
linked automatically and thus be click-able.

Now, I didn't explain it earlier, but the notion of channel in IRC,
e.g. #esp and the notion of #hashtags on Twitter are closely related.
In both cases, you're simply saying "send this message to those
subscribed to this topic".

In Tent, I'm imagining a bastardised combination of IRC/Twitter.
Imagine multiple columns of communication for each #channel. And being
able to toggle between seeing messages from *just* those who you
follow for a given #channel or seeing everyone's messages for it...

One can send a message to multiple #channels easily, e.g.

<tav> Morning everyone #esp #openkollab

Then, those who follow me for #esp will see it in their #esp column if
it was active, and likewise with those for #openkollab.

Unlike in Twitter, where one has to specify #hashtags in the content
of the message, we could provide a single optional *To:/Meta:* field
for messages where a user could list as many channels as they want --
allowing them to send the message without cluttering it with #channel
names if they wanted to.

And, oh, there would be no need to impose 140 character limits either
-- though, practical considerations mean that individual line items
would probably have a limit of something like 50kb -- which should be
enough for now...

Anything which doesn't have a #channel can automatically go into the
default #mainstream channel.

All channel names would be normalised, e.g. #WorLDPeace becomes
#worldpeace and #Friedrichstraße becomes #friedrichstrasse.

And, the equivalent of direct messages on Twitter or private messages
on IRC could be achieved by putting @usernames in the "To:/Meta:"
field. You can send the same message to multiple people by putting
multiple @usernames, e.g.

<tav> Hey guys, what do you think of Tent?
[To: @Suresh @sdhorn]

Of course, the private "flag" would only be set by the system if one
hadn't also specified a public #channel, e.g.

<tav> Hey guys, what do you think of Tent?
[To: @Suresh @sdhorn #openkollab]

^ the above would obviously not be private... but would pop up in the
personal messages column for both @Suresh and @sdorhn...

Also, much like how Retweeting and how Git differentiates between
author/committer, one can +1 an Item by pressing a simple +1 button.
This would also allow the user to provide an optional comment on the
item as well as "re-publish" the item into their own stream (but
formatted with the original content) for those who are following them.

This provides a simple, but unified mechanism for: a) promoting items
from users that one's followers aren't following b) a way of marking
something as being useful for later reference (i.e. star-ring it or
marking it as a favourite) c) a way to do basic "threaded" comments
without getting into the pains of nested comments d) a way to
"republish" content into a different channel -- one could add
different channels for one's own comment...

[Aside: this mechanism could also perhaps be used to define
"dependencies" more explicitly.]

Now that #channels are hopefully explained, let's take a look at those
line *Items*.

First of all, "file sharing" could be enabled by having a form which
allows users to attach a file to an Item by uploading directly to an
Amazon S3 instance.

Secondly, the ability to create new Items with the same
<named-identifier> gives the system a very basic, but useful,
versioning capability -- it just needs a view to see previous items
with the same name...

Now, from this, it's just a hop, skip and a jump away to that
favourite tool of many of us... Wikis! =)

So, how would that work? Well, slightly differently to traditional
wikis. In place of the limits of the single flat + global namespace
that most wikis impose, we already have personal namespaces in the
form of ~user/items.

So there would be no "shared" editing of the same item (page). In
place, a user could either just make a new edit as a new item in their
own stream or "push" an edit to the original author.

When a user hovers over an Item, an "edit" link could appear which
just copies the existing Item's contents and let's the user make
changes before pressing either "send" (to their own stream) or "push
to @original-author". Simple!

And if the original author chooses to accept the push, then all it
does is create a new Item with the pushed content. And *if* it
happened to have the same <named-identifier> as a previous Item they
had created, the references would be updated. That's all!

Now, on the user inteface side, a user should be able to just "chat"
without knowing any of this shit.

The usual chat line items would be "sent" every time they press the
"enter" key (i.e. hit return) or clicks on the "send" button.

But to allow for long "page" Items, the frontend could switch to
treating the "enter" key as a line break if the content starts with a
format shebang (#!), e.g.

 #! markdown
 This is an item with **bolded** content.

In which case the rest of the content is assumed to be in the
specified format. A <named-identifier> could be also be specified for
these items e.g.

 #! html <hello-world>
 <strong>Hello World</strong>

These items could be arbitrarily long. Unlike the "normal" items,
where both ~/links and http://foo.com are automatically handled and in
case of links like flickr/youtube links -- automatically embedded --
one would need to explicitly mark links using either the format's
linking syntax or the common link syntax, e.g.

 http://google.com or
 ~tav/plexnet

Items could also be "included" (transcluded) using:

  Add ~tav/plexnet

And variables substituted using:

 (|`username|)

In the "To:/Meta:" field, one could define additional metadata for the
item if wanted, e.g.

 start=2009-08-16 end=2009-08-20 price=$300

In fact the earlier usage of !type, #channel and @user was just a
builtin shorthand for defining certain metadata, i.e.

 #openkollab --> channel=openkollab
 @mattcoop  --> channel=@mattcoop
 !intention --> type=intention

Super "power users" could use the powerful transclusion language and
builtin services to build "applications" easily, e.g. want to let
others see a calendar view of events taking place this week related to
the #channels they're subscribed to?

Just create an item with the following content:

{{.foreach `subscriptions | .find {'type': 'event', 'channel': _} |
.if _.start == (.thisweek) | ~mattcoop/calendar}}

Now this is obviously not something for the average user, but power
users could leverage it to create useful apps from the various data
being created and add unthought of new functionality...

In fact, I imagine that the "builtin" shaila functionality would
basically be such an app that provides just a frontend for creating an
appropriate Item.

That is, this system can start out being very easy for someone to use
-- it's just like an IM chat! But, they can gradually become a power
user in small, but comfortable steps!

* Line/Page Items
* !Types
* <Named-identifiers>
* ~user/links
* To:/Meta: field
* #Channels
* @Userspaces
* +1 of Items
* #! Formats
* Links
* Add Transclusion
* .Services

By itself, each of the elements are straightforward and can be found
in existing systems -- IRC, Wikis, Wagn, Unix, Twitter, etc. -- but
together, it can provide a collaboration platform that is both simple
for the novice user and yet unparalleled in it's power.

Thoughts?

--