The Share Protocol
------------------

)c( Sam Watkins, 2001

Peers communicate over an ordered reliable secure authenticated uninterruptible
flow-controlled message routing network using a symmetrical protocol.

To create a message channel over a stream channel, end each message with a
blank line, and escape other blank lines and lines beginning with "." (or
indeed, any line) by prefixing ".".

For a reliable secure authenticated stream channel, use ssh or similar.

For an uninterruptible message channel, buffer messages while the underlying
channel is down and send them when it comes up.

For a reliable message channel, use checksums, ACKs and NAKs, and buffer sent
mesages until they are ACKed.  A single ACK or NAKs can refer to multiple
messags.

To get an ordered message channel from an unordered channel, prefix a message
count.

To get an ordered message channel from a set of parallel ordered message
channels, send with each message the number of the channel that will be used
for the next message.

To get a flow-controlled channel, send data slightly faster than it is
acknowleged, and limit the amount of unacknowleged data.

To increase efficiency of a message channel, join escaped messages together into
a single message.

For a routing network, each peer must maintain a routing table, and each
message must be prefixed with its source and destination (if not an immediate
peer).

For a distributed object network, routers must multicast changes between images
of an object.  Images must buffer unacknowleged changes and resolve conflicts.

Here is an example - Sam Watkins (a person) connects to bruno hub (a program)
using ssh, and they are introduced and authenticated.

1 sam:
	type?

1 bruno:
	share hub

2 sam:
	route

3 sam:
	> hello world
	type?

3 bruno:
	< hello world
	text utf8 ed

4 sam:
	> hello world
	data?

4 bruno:
	< hello world
	hello world

5 sam:
	<> hello world
	s/ /, /

5 bruno:
	<> hello world
	s/h/H/

6 bruno:
	<> hello world
	s/w/W/

7 bruno:
	<> hello world
	ack 

6 sam:
	<> hello world
	ack 2
	s/$/!/

8 bruno:
	<> hello world
	ack

7 sam:
	bye

9 bruno:
	bye

If an object image Alice receives a request Ri from her peer Bob that
contradicts an unacknowleged sent request Ro, Alice can NAK Ri.  Bob must then
negate the sense of Ri and transmit that request to other images.

Object transmission queues might be intelligent and merge or cancel requests.

There are some ideas in 9P which are worth stealing - walking, for instance.

routing:

A message may be sent to one image of an object (a query) or to all images (a
change).

Finding objects - use the not-necessarily-hierarchical filesystem rooms idea -
you can navigate around between spaces.  The links between objects (doors)
are not attributes of those objects.  This sounds quite similar to moebius.

Could also have objects that provide other searching services.

walking - provide multiplexed channel, different named or numbered virtual
channels with different contexts - this allows pushd popd like functionality.
Should be able to fork and close the virtual channels.  Should it do this by
default?  Do we have a "current channel" idea, or specify with each message?
Seems a bit recursive!  Can we do this channels thing using channel objects in
a space?

Rooms - do you listen to everything in the current room at once?  Carrying
things?  Every object has a "container" - or possibly more than one - or use
links / doors?  or both?  texinfo isn't a bad model.  Can objects have multiple
images?  not realistic - maybe an image is just that - not the "real thing", or
at least images have distinct identities.

groups / users idea - talking to a group is broadcasting.  images of an object
form a group.