diff options
| -rw-r--r-- | proposals/0002-hypercore.md | 2 | ||||
| -rw-r--r-- | proposals/0006-session-data-extension.md | 5 |
2 files changed, 5 insertions, 2 deletions
diff --git a/proposals/0002-hypercore.md b/proposals/0002-hypercore.md index bafcedb..5469cbb 100644 --- a/proposals/0002-hypercore.md +++ b/proposals/0002-hypercore.md @@ -171,7 +171,7 @@ The nodes in this tree would be calculated as follows: 10 = h(chunk5) ``` -In the Hypercore feed, we only want one active root. Therefore, when there are multiple roots we hash all the roots together again. At most there will be `log2(number of data blocks)`. +It is convenient to capture the state of the Hypercore feed as a whole with a fixed-size hash, regardless of how many root hashes there are. This is achieved by always re-hashing all the individual root hashes together into a single hash value. At most there will be `log2(number of data blocks)` such individual root hashes to re-hash. ``` root = h(9 + 3) 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 |