From 83bcec91b8d01ab57777e8bb602b3774d5a178b6 Mon Sep 17 00:00:00 2001 From: Paul Frazee Date: Wed, 30 May 2018 14:50:44 -0500 Subject: Add proposals/0000-session-data-extension.md --- proposals/0000-session-data-extension.md | 61 ++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 proposals/0000-session-data-extension.md diff --git a/proposals/0000-session-data-extension.md b/proposals/0000-session-data-extension.md new file mode 100644 index 0000000..d7cffa9 --- /dev/null +++ b/proposals/0000-session-data-extension.md @@ -0,0 +1,61 @@ + +Title: **DEP-0000: Session Data (Extension Message)** + +Short Name: `0000-session-data-extension` + +Type: Informative + +Status: Undefined (as of 2018-05-31) + +Github PR: (add HTTPS link here after PR is opened) + +Authors: [Paul Frazee](https://github.com/pfrazee) + + +# Summary +[summary]: #summary + +This DEP defines the non-standard `session-data` extension message used in the Dat replication protocol. This message provides a way to attach application data to a connection, commonly used for identifying the users and broadcasting personal keys. + + +# Motivation +[motivation]: #motivation + +Applications frequently need to discover which users of the application are online (presence) in order to establish bidirectional communication. For example, a chat application which uses a shared HyperDB as the channel state may need to broadcast the Hypercore keys of each user in order to authorize the joining chat-users (as in the case of "Cabal"). It would also be useful to broadcast Hyperdrive archive keys (as in the case of "Fritter" and "Rotonde") or even simple plain-text identity (eg "my name is Bob") to be used with other communication mechanisms. + +This extension message will establish a common mechanism for broadcasting user and session data. + + +# Reference Documentation +[reference-documentation]: #reference-documentation + +This DEP is implemented using the Dat replication protocol's "extension messages." In order to broadcast support for this DEP, a client should declare the `'session-data'` extension in the replication handshake. + +Session-data can be announced at any time after the connection is established by sending an extension message of type `'session-data'`. The message may include a payload up to 256 bytes in length. Any additional bytes should be truncated by the receiving client. The payload is a buffer of any encoding. The session-data message should not be sent frequently and a client may choose to rate-limit its handling of the events (this DEP suggests "once per 5 seconds"). + +The client should maintain a `sessionData` variable on each connection. This variable should be empty when a new connection is established. Any time a `'session-data'` extension message is received, the value of the `sessionData` variable should be updated to contain the payload of the message. + +The client may respond to the message by emitting an event, so that it may be handled by the client's application logic. The client should also make the most recent `sessionData` buffer available to the application logic after message is received. + +After publishing this DEP, the "Beaker Browser" will implement a Web API for exposing the `'session-data'` protocol to applications. It will restrict access so that the application code of a `dat://` site will only be able to set the session data for connections related to its own content. + + +# Drawbacks +[drawbacks]: #drawbacks + +This DEP may present privacy concerns, as it may be used to track users in a similar fashion to HTTP Cookies. + + +# Rationale and alternatives +[alternatives]: #alternatives + +Some applications have used the `peer id` and/or `userData` fields of the replication handshake message in order to broadcast this information. Those mechanisms are unsuitable for Web applications (as in the "Beaker browser") because the sites' applications are not executed reliably prior to the replication handshake. + +By using an extension message, we provide the same presence & discovery without relying on the timing of the application-code execution. + + +# Changelog +[changelog]: #changelog + +- 2018-05-31: First complete draft submitted for review + -- cgit v1.2.3 From 833f0b8bbc96e379ba2ad48c30a964ec7d2eddd7 Mon Sep 17 00:00:00 2001 From: Paul Frazee Date: Wed, 30 May 2018 14:56:48 -0500 Subject: Expand on drawbacks in proposals/0000-session-data-extension.md --- proposals/0000-session-data-extension.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/proposals/0000-session-data-extension.md b/proposals/0000-session-data-extension.md index d7cffa9..659e70d 100644 --- a/proposals/0000-session-data-extension.md +++ b/proposals/0000-session-data-extension.md @@ -43,7 +43,9 @@ After publishing this DEP, the "Beaker Browser" will implement a Web API for exp # Drawbacks [drawbacks]: #drawbacks -This DEP may present privacy concerns, as it may be used to track users in a similar fashion to HTTP Cookies. +- This DEP may present privacy concerns, as it may be used to track users in a similar fashion to HTTP Cookies. +- The payload of the `'session-data'` message is not authenticated in any way. If a public key is sent, proof of ownership of the private key is not provided. The lack of trust must be considered by applications which leverage the data. +- If the recipient of the `'session-data'` message is not authenticated (as is currently the case in all Dat replication connections) the client will not know who is receiving the payload and may broadcast sensitive information. # Rationale and alternatives -- cgit v1.2.3 From e339c9b7369477ea38c1aef6d7d8d27429d029d0 Mon Sep 17 00:00:00 2001 From: Paul Frazee Date: Wed, 30 May 2018 15:01:33 -0500 Subject: Expand on rationale in proposals/0000-session-data-extension.md --- proposals/0000-session-data-extension.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/0000-session-data-extension.md b/proposals/0000-session-data-extension.md index 659e70d..56e39e4 100644 --- a/proposals/0000-session-data-extension.md +++ b/proposals/0000-session-data-extension.md @@ -51,9 +51,9 @@ After publishing this DEP, the "Beaker Browser" will implement a Web API for exp # Rationale and alternatives [alternatives]: #alternatives -Some applications have used the `peer id` and/or `userData` fields of the replication handshake message in order to broadcast this information. Those mechanisms are unsuitable for Web applications (as in the "Beaker browser") because the sites' applications are not executed reliably prior to the replication handshake. +Some applications have used the `peerId` and/or `userData` fields of the replication handshake message in order to broadcast this information. Those mechanisms are unsuitable for Web applications (as in the "Beaker browser") because the sites' applications are not executed reliably prior to the replication handshake. By using an extension message, we provide the same presence & discovery without relying on the timing of the application-code execution. -By using an extension message, we provide the same presence & discovery without relying on the timing of the application-code execution. +An alternative approach would be to establish an ephemeral messaging channel, perhaps using a different extension message. This ephemeral channel would broadcast the payload to the client's application code as an event when it is received, but would not retain the most recent payload as session-data. This ephemeral channel would be less effective in Web applications (as in the "Beaker Browser") because it would rely on the application-code being active (loaded in a tab) at time of receipt, whereas the builtin session-data semantic makes it possible for the browser to retain the last payload on the applications' behalf. # Changelog -- cgit v1.2.3 From d19820dc11c6dbd498a2cac3c36a0ead94a4482e Mon Sep 17 00:00:00 2001 From: Paul Frazee Date: Fri, 1 Jun 2018 09:46:53 -0500 Subject: Set PR link on proposals/0000-session-data-extension.md --- proposals/0000-session-data-extension.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/0000-session-data-extension.md b/proposals/0000-session-data-extension.md index 56e39e4..f9c0b9e 100644 --- a/proposals/0000-session-data-extension.md +++ b/proposals/0000-session-data-extension.md @@ -7,7 +7,7 @@ Type: Informative Status: Undefined (as of 2018-05-31) -Github PR: (add HTTPS link here after PR is opened) +Github PR: https://github.com/datprotocol/DEPs/pull/27 Authors: [Paul Frazee](https://github.com/pfrazee) -- cgit v1.2.3 From 029b506984107725d9bee46052ecab8a236db69b Mon Sep 17 00:00:00 2001 From: Paul Frazee Date: Wed, 6 Jun 2018 13:05:41 -0500 Subject: Publish 0006-session-data-extension as a draft --- proposals/0000-session-data-extension.md | 63 ------------------------------- proposals/0006-session-data-extension.md | 64 ++++++++++++++++++++++++++++++++ 2 files changed, 64 insertions(+), 63 deletions(-) delete mode 100644 proposals/0000-session-data-extension.md create mode 100644 proposals/0006-session-data-extension.md diff --git a/proposals/0000-session-data-extension.md b/proposals/0000-session-data-extension.md deleted file mode 100644 index f9c0b9e..0000000 --- a/proposals/0000-session-data-extension.md +++ /dev/null @@ -1,63 +0,0 @@ - -Title: **DEP-0000: Session Data (Extension Message)** - -Short Name: `0000-session-data-extension` - -Type: Informative - -Status: Undefined (as of 2018-05-31) - -Github PR: https://github.com/datprotocol/DEPs/pull/27 - -Authors: [Paul Frazee](https://github.com/pfrazee) - - -# Summary -[summary]: #summary - -This DEP defines the non-standard `session-data` extension message used in the Dat replication protocol. This message provides a way to attach application data to a connection, commonly used for identifying the users and broadcasting personal keys. - - -# Motivation -[motivation]: #motivation - -Applications frequently need to discover which users of the application are online (presence) in order to establish bidirectional communication. For example, a chat application which uses a shared HyperDB as the channel state may need to broadcast the Hypercore keys of each user in order to authorize the joining chat-users (as in the case of "Cabal"). It would also be useful to broadcast Hyperdrive archive keys (as in the case of "Fritter" and "Rotonde") or even simple plain-text identity (eg "my name is Bob") to be used with other communication mechanisms. - -This extension message will establish a common mechanism for broadcasting user and session data. - - -# Reference Documentation -[reference-documentation]: #reference-documentation - -This DEP is implemented using the Dat replication protocol's "extension messages." In order to broadcast support for this DEP, a client should declare the `'session-data'` extension in the replication handshake. - -Session-data can be announced at any time after the connection is established by sending an extension message of type `'session-data'`. The message may include a payload up to 256 bytes in length. Any additional bytes should be truncated by the receiving client. The payload is a buffer of any encoding. The session-data message should not be sent frequently and a client may choose to rate-limit its handling of the events (this DEP suggests "once per 5 seconds"). - -The client should maintain a `sessionData` variable on each connection. This variable should be empty when a new connection is established. Any time a `'session-data'` extension message is received, the value of the `sessionData` variable should be updated to contain the payload of the message. - -The client may respond to the message by emitting an event, so that it may be handled by the client's application logic. The client should also make the most recent `sessionData` buffer available to the application logic after message is received. - -After publishing this DEP, the "Beaker Browser" will implement a Web API for exposing the `'session-data'` protocol to applications. It will restrict access so that the application code of a `dat://` site will only be able to set the session data for connections related to its own content. - - -# Drawbacks -[drawbacks]: #drawbacks - -- This DEP may present privacy concerns, as it may be used to track users in a similar fashion to HTTP Cookies. -- The payload of the `'session-data'` message is not authenticated in any way. If a public key is sent, proof of ownership of the private key is not provided. The lack of trust must be considered by applications which leverage the data. -- If the recipient of the `'session-data'` message is not authenticated (as is currently the case in all Dat replication connections) the client will not know who is receiving the payload and may broadcast sensitive information. - - -# Rationale and alternatives -[alternatives]: #alternatives - -Some applications have used the `peerId` and/or `userData` fields of the replication handshake message in order to broadcast this information. Those mechanisms are unsuitable for Web applications (as in the "Beaker browser") because the sites' applications are not executed reliably prior to the replication handshake. By using an extension message, we provide the same presence & discovery without relying on the timing of the application-code execution. - -An alternative approach would be to establish an ephemeral messaging channel, perhaps using a different extension message. This ephemeral channel would broadcast the payload to the client's application code as an event when it is received, but would not retain the most recent payload as session-data. This ephemeral channel would be less effective in Web applications (as in the "Beaker Browser") because it would rely on the application-code being active (loaded in a tab) at time of receipt, whereas the builtin session-data semantic makes it possible for the browser to retain the last payload on the applications' behalf. - - -# Changelog -[changelog]: #changelog - -- 2018-05-31: First complete draft submitted for review - diff --git a/proposals/0006-session-data-extension.md b/proposals/0006-session-data-extension.md new file mode 100644 index 0000000..fa94187 --- /dev/null +++ b/proposals/0006-session-data-extension.md @@ -0,0 +1,64 @@ + +Title: **DEP-0006: Session Data (Extension Message)** + +Short Name: `0006-session-data-extension` + +Type: Informative + +Status: Draft (as of 2018-06-06) + +Github PR: https://github.com/datprotocol/DEPs/pull/27 + +Authors: [Paul Frazee](https://github.com/pfrazee) + + +# Summary +[summary]: #summary + +This DEP defines the non-standard `session-data` extension message used in the Dat replication protocol. This message provides a way to attach application data to a connection, commonly used for identifying the users and broadcasting personal keys. + + +# Motivation +[motivation]: #motivation + +Applications frequently need to discover which users of the application are online (presence) in order to establish bidirectional communication. For example, a chat application which uses a shared HyperDB as the channel state may need to broadcast the Hypercore keys of each user in order to authorize the joining chat-users (as in the case of "Cabal"). It would also be useful to broadcast Hyperdrive archive keys (as in the case of "Fritter" and "Rotonde") or even simple plain-text identity (eg "my name is Bob") to be used with other communication mechanisms. + +This extension message will establish a common mechanism for broadcasting user and session data. + + +# Reference Documentation +[reference-documentation]: #reference-documentation + +This DEP is implemented using the Dat replication protocol's "extension messages." In order to broadcast support for this DEP, a client should declare the `'session-data'` extension in the replication handshake. + +Session-data can be announced at any time after the connection is established by sending an extension message of type `'session-data'`. The message may include a payload up to 256 bytes in length. Any additional bytes should be truncated by the receiving client. The payload is a buffer of any encoding. The session-data message should not be sent frequently and a client may choose to rate-limit its handling of the events (this DEP suggests "once per 5 seconds"). + +The client should maintain a `sessionData` variable on each connection. This variable should be empty when a new connection is established. Any time a `'session-data'` extension message is received, the value of the `sessionData` variable should be updated to contain the payload of the message. + +The client may respond to the message by emitting an event, so that it may be handled by the client's application logic. The client should also make the most recent `sessionData` buffer available to the application logic after message is received. + +After publishing this DEP, the "Beaker Browser" will implement a Web API for exposing the `'session-data'` protocol to applications. It will restrict access so that the application code of a `dat://` site will only be able to set the session data for connections related to its own content. + + +# Drawbacks +[drawbacks]: #drawbacks + +- This DEP may present privacy concerns, as it may be used to track users in a similar fashion to HTTP Cookies. +- The payload of the `'session-data'` message is not authenticated in any way. If a public key is sent, proof of ownership of the private key is not provided. The lack of trust must be considered by applications which leverage the data. +- If the recipient of the `'session-data'` message is not authenticated (as is currently the case in all Dat replication connections) the client will not know who is receiving the payload and may broadcast sensitive information. + + +# Rationale and alternatives +[alternatives]: #alternatives + +Some applications have used the `peerId` and/or `userData` fields of the replication handshake message in order to broadcast this information. Those mechanisms are unsuitable for Web applications (as in the "Beaker browser") because the sites' applications are not executed reliably prior to the replication handshake. By using an extension message, we provide the same presence & discovery without relying on the timing of the application-code execution. + +An alternative approach would be to establish an ephemeral messaging channel, perhaps using a different extension message. This ephemeral channel would broadcast the payload to the client's application code as an event when it is received, but would not retain the most recent payload as session-data. This ephemeral channel would be less effective in Web applications (as in the "Beaker Browser") because it would rely on the application-code being active (loaded in a tab) at time of receipt, whereas the builtin session-data semantic makes it possible for the browser to retain the last payload on the applications' behalf. + + +# Changelog +[changelog]: #changelog + +- 2018-06-06: Merged as draft +- 2018-05-31: First complete draft submitted for review + -- cgit v1.2.3