From 503cd2a75e07e6ebe5f34f8db22ae2f8708fac8e Mon Sep 17 00:00:00 2001 From: Paul Frazee Date: Sun, 10 Jun 2018 16:44:22 -0500 Subject: Add more context & background to proposals/0006-session-data-extension.md --- proposals/0006-session-data-extension.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/proposals/0006-session-data-extension.md b/proposals/0006-session-data-extension.md index fa94187..8d8bad4 100644 --- a/proposals/0006-session-data-extension.md +++ b/proposals/0006-session-data-extension.md @@ -23,7 +23,10 @@ This DEP defines the non-standard `session-data` extension message used in the D 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. +This DEP was motivated by the need for a quick solution to these use-cases. It's expected to be a stepping stone to a more sophisticated solution. It outlines an extension message which broadcasts user and session data. The two primary use-cases considered are: + + 1. For small apps to be able to discover peers when shared. Examples include a dat-app containing an event invite, or a collaborative document. Scale would be kept small by the fact that the dat-app is only shared with friends. If too many people start showing up, the app could stop authorizing or reading their data. + 2. For dat-apps like Cabal and Fritter to experiment with discovery policies at a larger scale. Cabal (a chat app) intended to use a HyperDB which any user can "join" as a writer and start posting to. This DEP would make it simple for Cabal to send the local keys of joining users to the owner, to be added to the "channel" HyperDB. # Reference Documentation -- cgit v1.2.3 From 61ac7786a514f0bf58ac65cdd0f60ef433850ff1 Mon Sep 17 00:00:00 2001 From: Paul Frazee Date: Sun, 10 Jun 2018 16:48:52 -0500 Subject: Expand on motivation --- proposals/0006-session-data-extension.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/0006-session-data-extension.md b/proposals/0006-session-data-extension.md index 8d8bad4..23761fa 100644 --- a/proposals/0006-session-data-extension.md +++ b/proposals/0006-session-data-extension.md @@ -25,8 +25,8 @@ Applications frequently need to discover which users of the application are onli This DEP was motivated by the need for a quick solution to these use-cases. It's expected to be a stepping stone to a more sophisticated solution. It outlines an extension message which broadcasts user and session data. The two primary use-cases considered are: - 1. For small apps to be able to discover peers when shared. Examples include a dat-app containing an event invite, or a collaborative document. Scale would be kept small by the fact that the dat-app is only shared with friends. If too many people start showing up, the app could stop authorizing or reading their data. - 2. For dat-apps like Cabal and Fritter to experiment with discovery policies at a larger scale. Cabal (a chat app) intended to use a HyperDB which any user can "join" as a writer and start posting to. This DEP would make it simple for Cabal to send the local keys of joining users to the owner, to be added to the "channel" HyperDB. + 1. For small apps to be able to discover peers' identities when shared. Examples include a dat-app containing an event invite, or a collaborative document, which want to know the identities of visitors in order to receive data from them. Scale would be kept small by the fact that the dat-app is only shared with friends. If too many people start showing up, the app could stop authorizing or reading their data. (Identity data broadcasted via this DEP should not be considered highly trust-worthy.) + 2. For dat-apps like Cabal to experiment with authorization policies at a larger scale. Cabal (a chat app) intended to use a HyperDB which any user can "join" as a writer and start posting to. This DEP would make it simple for Cabal to send the local keys of joining users to the owner, to be added to the "channel" HyperDB. # Reference Documentation -- cgit v1.2.3