diff options
| author | Paul Frazee <pfrazee@gmail.com> | 2018-06-10 19:06:34 -0500 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2018-06-10 19:06:34 -0500 |
| commit | 747296b2382c4eb50dbe90222050c5bb22f01afd (patch) | |
| tree | 142f2c1b56405e34182fc3417b607a1683300598 /proposals | |
| parent | 4d83bebadd487d581388a4fa49aab142f35dc6de (diff) | |
| parent | 61ac7786a514f0bf58ac65cdd0f60ef433850ff1 (diff) | |
| download | dat-deps-747296b2382c4eb50dbe90222050c5bb22f01afd.tar.gz dat-deps-747296b2382c4eb50dbe90222050c5bb22f01afd.zip | |
Merge pull request #30 from pfrazee/session-data-context
Add more context & background to 0006-session-data-extension
Diffstat (limited to 'proposals')
| -rw-r--r-- | proposals/0006-session-data-extension.md | 5 |
1 files changed, 4 insertions, 1 deletions
diff --git a/proposals/0006-session-data-extension.md b/proposals/0006-session-data-extension.md index fa94187..23761fa 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' 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 |