# Project BDSM: Browser Data Sharing Mechanism

## Problem
Web3 frontends suffer from 3 major issues:
1) Poor UX due to lack of data and/or slow load times
2) Web3 provider cost (e.g. Alchemy, Infura). Statically hosted frontends have no way to share redundant data requests from nodes and result in higher recurring costs.
3) Reliance on backend server infrastructure (e.g. AWS, GCP). This is an effective way to speed up the responsiveness of a frontend and reduce the redundant data requests to the web3 provider, but can result in complex infrastructure and a hard reliance on cloud provider uptime.
Web frontends in general suffer from other issues:
1) There is typically no way to see open source code to verify the security and consistency of a server or web application. If the code was compressed to a content hash and it could be verified when served to the user, pointing to a particular commit hash, the user can know exactly what the code is doing, its security implications and that the website or app didn't suddenly change their standards.
2) There is no verifiable way to guarantee that a centralised server does not store your private information, such as chat messages or adds data tracking later.
## Solution
BDSM aims to eliminate these tradeoffs by providing the data needed for a rich user experience, while reducing the number of queries to the Web3 provider all without the need for backend infrastructure or a centralized source.
## Architecture
The diagram below provides a high level view of how data is shared between peers. The solid line indicates that the leader selection algorithm picked peer id 4 to fetch the data and share the content hash with the other peers.

## Leader Selection Algorithm (LSA)
The leader selection algorithm has the following properties:
- cheap to compute
- peers are able to independently determine if & when it is their turn to be the leader
- the calculation required to select a leader is probabilistic in nature and can result in more than one leader

**LSA Definition**
Let,
p = local peer id
n = number of peers
c = previous content hash
be the inputs to the leader selection algorithm. Execute the following steps to determine if p is the next leader:
1) calculate the Hamming distance H (or some other string metric) between p & c. We refer to this as H(p,c)
2) calculate the threshold distance T that results in a peer being selected with a probability = 1/n. We can refer to this as T(n)
3) return (H(p,c) <= T(n)) ? true : false
## Data Propagation
As mentioned previously, the current leader is only required to gossip the content hash of the updated data. This is beneficial because gossip networks aren't the most efficient means of propagating data and smaller payloads waste less bandwidth. Once a peer recieves the new content hash, it can query ipfs or other data availability layer to download the data.
## Running Source Code or Serving a Webapp
This model is used to share the source code for a webapp or even a "server" script. Similar to a traditional server, this results in updating data in an availability layer, similar to storing updated data in a database.
## Expanding into Merge Mining or Ethereum Nodes
As an expansion on this design, a restaking model can be used where the networking stack and processing capability of ethereum nodes are used to run scripts and update data accordingly. This should be more seamless since the node has all the data it needs vs. needing to query.
## Malicious Data
**Could someone maliciously supply bad data?**
Yes, but this can be okay for a few reasons:
1) projects like Dat protocol and Beaker browser have similar assumptions
2) there is no economic advantage to providing the incorrect data and it is a waste of resources. discovery protocols suffer from the same issue and there is much more incentive to attack a discovery protocol; however, Ethereum still works
**What if the Data is Important?**
For critical, sensitive information or code that needs to be run, having a proper settlement layer is important.
## Settlement Layer
For mission critical or sensitive data or scripts that nodes can supply malicious data for, we could ultimately revert to introducing a settlement layer on top of a data availability layer. This can utilise a mechanism around the optimistic or zk frameworks. Additionally, uploading the data could be done via a restaking mechanism.
## MVP
The mvp will utilise the following:
- Leader Selection Algorithm
- Content Hash gossip via libp2p
- Content stored on IPFS
This allows for the basic framework to be set up and answer fundamental questions. After, moving towards a settlement layer, data availability layer and a restaking mechanism would be ideal.
## Other Considerations
**Can a browser handle the bandwidth requirements?**
Yes, we are confident about this for two reasons:
1) a similar gossip model is used in eth2
2) Jonny built project at the first EthDenver that used a very similar design called [Arithmetica](https://github.com/arithm3tica/arithmetica)
**Is it possible to share the source code for the frontend and dynamically inject it in the DOM and eliminate the need for individual dapp portals?**
Jonny created a poc in the past called [Inception Host](https://github.com/jrhea/inception). It was built bc he hated url shortners and wanted to find ways to host any website in a url shortner's database. Most url shortners don't allow this anymore, but the concept still works. We just need a single url that hosts the code and can accept the site's content encoded as base64 - Inception Host does the rest. Here is an example [link](https://jrhea.github.io/inception/?command=load#?eJzVWW2P2zYS/itEgUBSVpZs7zqJV9YWmzQtrrgkRXL34WAbB1riykz0Volar5v1f+8MSVmSJfc27eGA2w9akTMccp554Yz83WIrkvhmla7SxZbREN4I/C0EFzG7+YUz8mZLC7Fw1QRwuZoNXjdZuK8XhPye8NA3Apre03K0zeKQFQYpxT5mvrHjodheX42fGZpfrlG8ahnuMqIFowZxa5kuCK3fN5UQWSp5C5qGWcJ/Yz9QQY2bj/WQ4HjhKs6BdTQMkaNkwri5DUOiB3+womBJds+Oiz7K4cC6lViUQcFzQcoi8I2tEHl57bpBmH4unSDOqvAuBt2cIEtc+pk+uDHflK5E1vlculPnhTPWw02VhjFzEp4CxbhZuEpwfbjjaCV2HPTeORK5N1mcFSXxyVekFCy8JkYRbczpbGaT+dwmk8upZdhIzAC+iLXpkxkwvLjS9D2L42zXpk/H8Hj1QtOjgrFUk1/i6vlUPjR5E1e18NkVEF4AdXo509S8KvK4pk9ml8AwRobZrJG+r/ceT3DvS3y8tIxVevDQ67Taygk+BTTmafQjDUAvUP+uSgPBs9S0aiREVaTEfEfFVi8B0g0ZOzPyPZk4Y3JNRvDPIs+J4skA/xP253DIseXVBzCPm0RxtqGx3uqeFuRdlootmmGJMyth/EzTihZ7pRuMf2SbojPxjhbB9ji6zQset2gN389VylqDuKHcVlFViuPwE8sFSzYQe/XMB8CmPX4PPtxh+IEFagLHa6mjUucTTcBaqI/S1KknHh+JeTIFrndAjFZCzziV4PHRJVfCdcltSOFwIbkrsoRgkECMgDU5i2hSyOCIWMoKKtioYDmDMNvE8CrtMEorPGM54ukIQkbJLJF23Vi9ZCy06g1XQmx56fwbJ+EY+M9TlIOtdAT/6K6HqLNJQh9aMhAHLaER59VUWAAE+fR9Aq7D7njKwu8JOhZMN4z0ARnx2WWcICN98AbPLBUC/5tfjifkglzNp/OXFnkGAXU5fTU+rtFejse4IGZLgqs50YdN3HyETFYPBo1tC4kgS+94dIJDcBfBoRQJfeDrwWuTFRjAhNkL6eMuWUIgyfAG5EmHLJ1C0eUrMCzXHY4AYlNoFvUOPK86LCELeEKl2yHXcdhjBCUETysu9keBx4ne0cK7Or/IxJBnO3Myto+bWX1dQ/BdTANdBbhN7inkR6/GfSXuQKzJ/bFH+ELq5JGLC97CHVfCEnQGhGXJ13I3CywtDY0e3Pit1yzjd9oVJIdFFn5L6c4GK4HHdfKq3JqtJFhr/Vwd2gJv0lPtbQ6ExSU7Jy6t4rjDXb8eGgi09+KinmPGdAPi/9d+OR5/q9+VguVoIpAwwggDrJQ1/5Rzfru/5QXkk1oNPQAmw+hwSTuWA37Zd0jMXeCSmJkIv/BRv75TlsrIer8LMug8fNBx+vZXEnsekMgr9S96wKAFJ9OuCZmUr7n06Gnw/aWwVjXDUmIXMB6b3Ho2ma69Yazlu1NWm1IUUPiY4Bb6qNafABfvvzKHyhTywm+sAzLUkzbJchp0swXqS+N8i9lNU3tXH9RW13CvjWqG03tKFbpbFudw5zhyK7Wh5UjRpnxaDhSBn5SW/RsrYQUWsaei0P7vkIRcB22QTkHiyJrBhBqeOSkEloItlfXJT1kWxYzcpjTeCx6UOI1pNMyCKgGMnDgLKOLjbLNSpDRhUndjt9NlOFT7WREZR7yaUpHbpZ3ZkV3Y1E6sr3xpqM2Oe33YfAY7Gmu/8PiyWPv4eHxs6tlaIs47v/rq3+Pjcm0px6BFJM9YWgdbEmN/8jxlO+xWGABIfcAH2ivB3sYMGc3M0gVgAqSICT1fvt7/g0bvQTngWI7XHnVouU8DfwJv2N5EXuIon3mfhczhackK8ZqByzMTldOmskxVqds1erahmhfDNlwXIYskAiNaQ6Dao+MI2h/biKhRGz+ipqE0MGxi/PN2NH01H88n86vRJU7QSmQd3pKlIRJyGrF7znaaKIPjIK/Go+3Pdlk4Qpd/SrdRt7Xay/9zO4HMykfrbXQC89vixD7Hhinnsv6vZ/G2vG6z1ZPQmEK2XJ5QmiXLPkEeuq+gadn//7zrgbkNDb5E0jKybT6LSb/BdqCzPnOgAWbVaT+dX3XeT+eXnfjT2bEzfyJCsuwCp9NfOsjE6PIcThfVddoAksZHFhoDexgfJDyDpH9JJAZJP6HSg5TXoN/JOdfN8NBakuUYtWUvfgpW5jDP7yHgRFGx1urTaNX4Zmmc0fBsKpAxLbAuO14hTaJ9vf9baLY/fFlIfAPlAHsQpjENjTpJtDZM9vhNzieY2eXlZ4J8WyeOflI5u233GxpcvGH49h6of+dQ6kEPDgeLefAF8uewZmpDR1b6ddpx4Ap4S4Ntc+tpinUmUTm6TWoPoQjPzeE9GzPJBDuYArwTR21PqO8Tg4g6VR6qe1IjaJ3kZYggvBKx+lM3tfOF7UuzH2a1hLPIt75CfjvseBgwfR2X/ik8/dR2Gqn6FhgMYIj49+BX2hzEgJJ+0M4xSyOxbUk4dICVxa8sjKEoROfHMli+LjryVNLQ0mSBjEw9kzf6Ok1jOWj8rn17xpMdQm3IpTrRs9aUPsna8/pC4BASUZDRt/nyKGPtnT37iWl0f6zFdty0rcQg/vVSLfpcmvgDpz6fFzpfvP9LeaHMYQ3DXmXyTWfFl1ZptnD1Dw7yV4j6Z4tV+t3v/F0NmQ==).