Difference between revisions of "WebCollab"
| (4 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| + | <noinclude>{{GoogleTrans-en}}{{TOCright}}</noinclude> | ||
Activities in Sugar may employ the Telepathy framework to implement collaborative behaviors over the network. The messages sent between participating Activities may be routed through a server, when using Telepathy's XMPP backend (Gabble), or they may be routed directly from the sender to the receiver, when using Telepathy's Link-local XMPP backend (Salut). Communication with Telepathy occurs over D-Bus, using the Telepathy D-Bus API. | Activities in Sugar may employ the Telepathy framework to implement collaborative behaviors over the network. The messages sent between participating Activities may be routed through a server, when using Telepathy's XMPP backend (Gabble), or they may be routed directly from the sender to the receiver, when using Telepathy's Link-local XMPP backend (Salut). Communication with Telepathy occurs over D-Bus, using the Telepathy D-Bus API. | ||
| Line 12: | Line 13: | ||
Common web browsers typically permit javascript programs to communicate only with the server from which they were downloaded. Therefore, it may be necessary to download the javascript program, or at least a portion of it, from the HTTPCollab server. | Common web browsers typically permit javascript programs to communicate only with the server from which they were downloaded. Therefore, it may be necessary to download the javascript program, or at least a portion of it, from the HTTPCollab server. | ||
| − | ==The Type-0 HTTPCollab Server->Client Interface== | + | ==Type-0 Design== |
| + | The Type-0 design is the simplest useful implementation of this architecture. It does not provide a high degree of efficiency or security, but it permits the full range of desired client behaviors. | ||
| + | |||
| + | ===The Type-0 HTTPCollab Server->Client Interface=== | ||
In the simplest case, the Server exposes an interface that is simply HTTP/1.1, specifically GET, PUT, and DELETE. Some directory on the server (e.g. http://karmashare.sugarlabs.org/schools/GPA/group22/collabdir/) is selected as the "collaboration directory", and the server is configured to accept PUT and DELETE within this directory. To avoid interference by malicious actors PUTing gigabytes of data or DELETEing indiscriminately, it may be appropriate to employ an access control mechanism such as an HTTP cookie. | In the simplest case, the Server exposes an interface that is simply HTTP/1.1, specifically GET, PUT, and DELETE. Some directory on the server (e.g. http://karmashare.sugarlabs.org/schools/GPA/group22/collabdir/) is selected as the "collaboration directory", and the server is configured to accept PUT and DELETE within this directory. To avoid interference by malicious actors PUTing gigabytes of data or DELETEing indiscriminately, it may be appropriate to employ an access control mechanism such as an HTTP cookie. | ||
As far as a simple server is concerned, this describes its entire interaction with the client. | As far as a simple server is concerned, this describes its entire interaction with the client. | ||
| − | ==The Type-0 JSCollab Client->Server Interface== | + | ===The Type-0 JSCollab Client->Server Interface=== |
The server allows the client to upload arbitrary files, and every webapp can make use of this system as pleases its authors. However, a simple structure may provide a valuable scaffolding on which to build more complex systems. JSCollab describes one such simple client-side behavior. | The server allows the client to upload arbitrary files, and every webapp can make use of this system as pleases its authors. However, a simple structure may provide a valuable scaffolding on which to build more complex systems. JSCollab describes one such simple client-side behavior. | ||
| Line 30: | Line 34: | ||
For efficiency reasons, it may sometimes be appropriate to delete messages. A client may delete messages using the HTTP DELETE command. Because messages always have unique names, and are immutable, there is no risk of races between a client deleting a file and another client creating a file with the same name or updating the existing file. | For efficiency reasons, it may sometimes be appropriate to delete messages. A client may delete messages using the HTTP DELETE command. Because messages always have unique names, and are immutable, there is no risk of races between a client deleting a file and another client creating a file with the same name or updating the existing file. | ||
| − | ==The Type-0 SugarHTTPCollab Server->Server Interface== | + | ===The Type-0 SugarHTTPCollab Server->Server Interface=== |
In the case of Sugar and Telepathy, the server runs on localhost, and acts as an interface to Telepathy. When the activity is initiated, the server is launched on any open port on localhost, and the browser is pointed at a known url on the host (e.g. http://localhost:42141/index.html) from which to download the first page. The javascript is already aware of the collaboration directory URL (e.g. http://localhost:42141/collabdir/). | In the case of Sugar and Telepathy, the server runs on localhost, and acts as an interface to Telepathy. When the activity is initiated, the server is launched on any open port on localhost, and the browser is pointed at a known url on the host (e.g. http://localhost:42141/index.html) from which to download the first page. The javascript is already aware of the collaboration directory URL (e.g. http://localhost:42141/collabdir/). | ||
| Line 36: | Line 40: | ||
When a new server joins, it must be informed of the current state of collabdir/. This is easy to do in a simple way; just pick a random participant upon joining and ask for the complete contents. Performing this update in a reliable and efficient manner is nontrivial, but should be possible. A sophisticated implementation is probably not necessary for a first release. | When a new server joins, it must be informed of the current state of collabdir/. This is easy to do in a simple way; just pick a random participant upon joining and ask for the complete contents. Performing this update in a reliable and efficient manner is nontrivial, but should be possible. A sophisticated implementation is probably not necessary for a first release. | ||
| + | |||
| + | ==Refinements== | ||
| + | ===The Type-1 HTTPCollab Server->Client Interface=== | ||
| + | The Type-0 Server has two obvious deficits: efficiency and security. Efficiency is low, in the sense that if A sends a message to B, C will have to download the whole list of messages again to find out that the message is for someone else. Security is low, in the sense that any user can easily impersonate any other, or interfere with others' communications. | ||
| + | |||
| + | To enable greater efficiency, an obvious step is to introduce directories. Messages to one user may be segregated in a separate directory, so that users do not have to monitor each others messages. | ||
| + | |||
| + | To enable greater security, an obvious step is to employ access control permissions on these directories. | ||
| + | |||
| + | HTTP provides, or at least enables, some types of access control, but it does not provide any standard way for users to create directories. We could build such a system with POST messages, but a more standards-based approach is available through WebDAV. The WebDAV HTTP extensions include a MKCOL message type, allowing clients to make directories. WebDAV also provides a suitable access control mechanism for directories, in the form of Write Locking. | ||
| + | |||
| + | A Type-1 HTTPCollab Server provides a WebDAV interface, including at least GET, PUT, DELETE, and MKCOL. If security is desired, it should also provide LOCK and UNLOCK. | ||
| + | ===The Type-1 JSCollab Client->Server Interface=== | ||
| + | A Type-1 JSCollab client implements the same abstraction as a Type-0 client, but using directory structures and locking to improve efficiency and security. | ||
| + | |||
| + | The client first chooses a unique id, then uses the LOCK directive to acquire a depth:infinity write lock on the directory with that name. This lock will never be released. If high security is desired, it may be necessary to choose a random name to ensure that no other user could have locked it already. | ||
| + | |||
| + | The client then creates the directory with that name. Within that directory, the client creates two subdirectories: "broadcast/" and "to/". A broadcast message that would be "{unique id}_broadcast_{index}_{key}" in Type-0 becomes "{unique id}/broadcast/{index}_{key}" in Type-1. | ||
| + | |||
| + | If a user wishes to send a message to another user, the user must create a subdirectory of "to/" with the desired target id. Once created, such a directory should not be deleted. A directed message that would be "{unique id}_to_{target id}_{index}_{key}" in Type-0 is "{unique id}/to/{target id}/{index}_{key}" in Type-1. | ||
| + | |||
| + | A Type-1 client must monitor the root collaboration directory for the appearance of new users. When a new user appears, the client must monitor that user's broadcast/ directory for broadcast messages. The client must also monitor that user's to/ directory in case a message with the client's unique id should appear. If such a directory does appear, the client may stop polling to/, but must start polling to/{unique id}. | ||
| + | |||
| + | The large amount of polling required here represents a potential decrease in efficiency. To achieve high efficiency, the client must employ a form of "long polling" or similar push-like technique. It is not clear whether such behavior can work with a typical unmodified WebDAV server. | ||
| + | |||
| + | ===The Type-1 SugarHTTPCollab Server->Server Interface=== | ||
| + | This interface is the same as the Type-0, updated to include directories and optionally locking. | ||
| + | |||
| + | JSCollab does not require any concurrency control, so locking is only relevant if it is implemented in a fashion that is at least somewhat secure against a malicious client. One obvious way to do this is for anyone who locks a path to issue a message indicating "I know the secret token for this lock". If any other server receives a request to modify or unlock a locked path, it must (privately*) forward the token from the request to the server that knows the token. If the token is correct, that server will issue a broadcast message, "X knows the secret token for the lock"; otherwise it will privately respond "no". The broadcast message forms a chain of trust from the creator of the lock, indicating who knows the token. Servers must reject requests to delete, modify, or unlock a file from a server that has not been identified as knowing the token. | ||
| + | |||
| + | This does not resolve concurrency issues, but it does prevent a malicious user from deleting locked files without knowledge of the secret token. | ||
| + | |||
| + | *: If private transmissions are not available, the system could instead transmit a cryptographic hash of the concatenation of the token and the sender's Telepathy identifier, which can easily be verified by the server, but cannot be reused. | ||
| + | |||
| + | [[Category:Idea]] | ||
| + | [[Category:Collaboration]] | ||
Latest revision as of 10:59, 3 August 2009
Activities in Sugar may employ the Telepathy framework to implement collaborative behaviors over the network. The messages sent between participating Activities may be routed through a server, when using Telepathy's XMPP backend (Gabble), or they may be routed directly from the sender to the receiver, when using Telepathy's Link-local XMPP backend (Salut). Communication with Telepathy occurs over D-Bus, using the Telepathy D-Bus API.
Programs written in Javascript+HTML+CSS, designed to run in a browser, can also provide online collaborative behaviors, as evidenced most famously by Google Docs. However, this collaboration typically requires a cooperating central server, because the standard browser security model does not permit a javascript application to communicate directly with any computer other than the server.
This page presents a simple design to enable decentralized, serverless collaboration between javascript applications. This model also extends naturally to environments in which a central server is available.
Architecture Overview
WebCollab employs a server, the HTTPCollab server. The javascript webpage interacts with this server by downloading files from it and uploading files to it. For a single central server, that's all there is to it.
To enable decentralized operation, such as would be expected when using Telepathy, the servers talk to each other. Every time a local user uploads a file to the local server, the local server transmits the file to all the other servers, which make it available at the same path. Javascript clients are expected to poll directories that may contain messages in which they are interested, so the system acts as a message-passing interface with named messages. A client that uploads a file can reasonably expect that all other clients will soon become aware of that file's existence.
Common web browsers typically permit javascript programs to communicate only with the server from which they were downloaded. Therefore, it may be necessary to download the javascript program, or at least a portion of it, from the HTTPCollab server.
Type-0 Design
The Type-0 design is the simplest useful implementation of this architecture. It does not provide a high degree of efficiency or security, but it permits the full range of desired client behaviors.
The Type-0 HTTPCollab Server->Client Interface
In the simplest case, the Server exposes an interface that is simply HTTP/1.1, specifically GET, PUT, and DELETE. Some directory on the server (e.g. http://karmashare.sugarlabs.org/schools/GPA/group22/collabdir/) is selected as the "collaboration directory", and the server is configured to accept PUT and DELETE within this directory. To avoid interference by malicious actors PUTing gigabytes of data or DELETEing indiscriminately, it may be appropriate to employ an access control mechanism such as an HTTP cookie.
As far as a simple server is concerned, this describes its entire interaction with the client.
The Type-0 JSCollab Client->Server Interface
The server allows the client to upload arbitrary files, and every webapp can make use of this system as pleases its authors. However, a simple structure may provide a valuable scaffolding on which to build more complex systems. JSCollab describes one such simple client-side behavior.
A JSCollab client has a unique id during each session. This id may be a random string, and it need not be the same from session to session. The id must be a valid HTTP path name and must not contain the characters "_" or "/".
A message in JSCollab has a key, a value, and an index. The key is a string subject to the same constraints as the unique id. The value is a sequence of arbitrary bytes. The index is an integer indicating the number of messages previously sent by the user, incremented for each message, starting at 0.
To broadcast a message, a JSCollab client uploads a file with the name {unique id}_broadcast_{index}_{key}. The contents of the file are the value of the message. The index is represented as a base-10 string.
To send a message to a specific user specified by a target id, the client uploads a file with the name {unique id}_to_{target id}_{index}_{key}
For efficiency reasons, it may sometimes be appropriate to delete messages. A client may delete messages using the HTTP DELETE command. Because messages always have unique names, and are immutable, there is no risk of races between a client deleting a file and another client creating a file with the same name or updating the existing file.
The Type-0 SugarHTTPCollab Server->Server Interface
In the case of Sugar and Telepathy, the server runs on localhost, and acts as an interface to Telepathy. When the activity is initiated, the server is launched on any open port on localhost, and the browser is pointed at a known url on the host (e.g. http://localhost:42141/index.html) from which to download the first page. The javascript is already aware of the collaboration directory URL (e.g. http://localhost:42141/collabdir/).
The server is configured to accept all PUT and DELETE requests in collabdir/. If the activity is already shared, the PUT or DELETE request is immediately also transmitted to all other collaborating server instances.
When a new server joins, it must be informed of the current state of collabdir/. This is easy to do in a simple way; just pick a random participant upon joining and ask for the complete contents. Performing this update in a reliable and efficient manner is nontrivial, but should be possible. A sophisticated implementation is probably not necessary for a first release.
Refinements
The Type-1 HTTPCollab Server->Client Interface
The Type-0 Server has two obvious deficits: efficiency and security. Efficiency is low, in the sense that if A sends a message to B, C will have to download the whole list of messages again to find out that the message is for someone else. Security is low, in the sense that any user can easily impersonate any other, or interfere with others' communications.
To enable greater efficiency, an obvious step is to introduce directories. Messages to one user may be segregated in a separate directory, so that users do not have to monitor each others messages.
To enable greater security, an obvious step is to employ access control permissions on these directories.
HTTP provides, or at least enables, some types of access control, but it does not provide any standard way for users to create directories. We could build such a system with POST messages, but a more standards-based approach is available through WebDAV. The WebDAV HTTP extensions include a MKCOL message type, allowing clients to make directories. WebDAV also provides a suitable access control mechanism for directories, in the form of Write Locking.
A Type-1 HTTPCollab Server provides a WebDAV interface, including at least GET, PUT, DELETE, and MKCOL. If security is desired, it should also provide LOCK and UNLOCK.
The Type-1 JSCollab Client->Server Interface
A Type-1 JSCollab client implements the same abstraction as a Type-0 client, but using directory structures and locking to improve efficiency and security.
The client first chooses a unique id, then uses the LOCK directive to acquire a depth:infinity write lock on the directory with that name. This lock will never be released. If high security is desired, it may be necessary to choose a random name to ensure that no other user could have locked it already.
The client then creates the directory with that name. Within that directory, the client creates two subdirectories: "broadcast/" and "to/". A broadcast message that would be "{unique id}_broadcast_{index}_{key}" in Type-0 becomes "{unique id}/broadcast/{index}_{key}" in Type-1.
If a user wishes to send a message to another user, the user must create a subdirectory of "to/" with the desired target id. Once created, such a directory should not be deleted. A directed message that would be "{unique id}_to_{target id}_{index}_{key}" in Type-0 is "{unique id}/to/{target id}/{index}_{key}" in Type-1.
A Type-1 client must monitor the root collaboration directory for the appearance of new users. When a new user appears, the client must monitor that user's broadcast/ directory for broadcast messages. The client must also monitor that user's to/ directory in case a message with the client's unique id should appear. If such a directory does appear, the client may stop polling to/, but must start polling to/{unique id}.
The large amount of polling required here represents a potential decrease in efficiency. To achieve high efficiency, the client must employ a form of "long polling" or similar push-like technique. It is not clear whether such behavior can work with a typical unmodified WebDAV server.
The Type-1 SugarHTTPCollab Server->Server Interface
This interface is the same as the Type-0, updated to include directories and optionally locking.
JSCollab does not require any concurrency control, so locking is only relevant if it is implemented in a fashion that is at least somewhat secure against a malicious client. One obvious way to do this is for anyone who locks a path to issue a message indicating "I know the secret token for this lock". If any other server receives a request to modify or unlock a locked path, it must (privately*) forward the token from the request to the server that knows the token. If the token is correct, that server will issue a broadcast message, "X knows the secret token for the lock"; otherwise it will privately respond "no". The broadcast message forms a chain of trust from the creator of the lock, indicating who knows the token. Servers must reject requests to delete, modify, or unlock a file from a server that has not been identified as knowing the token.
This does not resolve concurrency issues, but it does prevent a malicious user from deleting locked files without knowledge of the secret token.
- If private transmissions are not available, the system could instead transmit a cryptographic hash of the concatenation of the token and the sender's Telepathy identifier, which can easily be verified by the server, but cannot be reused.