search

ethersphere / bee

Bee is a Swarm client implemented in Go. It’s the basic building block for the Swarm network: a private; decentralized; and self-sustaining network for permissionless publishing and access to your (application) data.
https://www.ethswarm.org
BSD 3-Clause "New" or "Revised" License
1.45k stars 338 forks source link

Bee in browser #432

Closed Eknir closed 3 years ago

Eknir commented 4 years ago

User story

Story

As a user of Swarm Dapps, I want to connect to the Swarm network in the browser, such that I can browse the BZZ without running a Swarm full node.

Acceptance criteria

Background

In the research office hour (9th of July), the team spoke about the possibility of browser integration of Bee. Integrating Bee in the browser is crucial to onboard new users. Browser integration should be thought of as mobile first and hence, should not consume any more than necessary resources. We should not expect a user to upload very big pieces of data via the mobile.

There are two proposed paths

Larva node One path is to make a special type of browser-only node (let's call it larva), which only creates push sync requests and retrieve requests. In order to send these requests, the node must be connected to at least one node. Light nodes must also have the option to announce themselves to the network, to request current price information from nodes in the network. Light nodes will choose a different peer if the peer to which they are connected is more expensive than others. This automatically creates load-balancing.

By being a light node, some information is leaked (the full node to whom the node is connected knows the data which is requested). This can be mitigated by splitting the requests to many full nodes. The node always has the choice not to leak anything by being a full node.

Incentives is handled by "normal" SWAP accounting. The private key of the chequebook-owner is stored in the browser (and hence can autonomously sign). The chequebook is funded by the main key of the browser (e.g. MetaMask account). The chequebook should be topped-up with the amount that is expected for the session, because the money in the chequebook is at risk.

WebAssembly Golang can compile to web-assembly and, hence, it would be theoretically possible to run a Bee full node in the browser.

Tasks

Task Assignee Done (1), or 0
Eknir commented 4 years ago

I had a discussion today, with @metacertain .

The Larva model probably creates a high UX-barrier to people accessing content from Swarm, as it implies a payment upfront.

The lightnode with Webassembly model probably creates an unhealthy situation for the network, with a lot of churn and slow-forwarders.

We spoke about a third alternative (Pupa model) which is making it very easy for people to connect to their own Swarm full node. It is possible to make a normwal web2 website, which would allow the user to make a connection to a libp2p underlay address. The user may have it's own address (scanned with a QR code) or the address from a friend (shared a link). Some authentication is needed (may be simple password). The big advantage of this model is that is actually incentivizes people to run their own Swarm full nodes: they make money by doing so and have the possibility to access content and share it with friends.

Eknir commented 4 years ago

Pupa model

In the Pupa model, the premise is that you always connect via your own or a trusted (friends) full node. To make this connection, we use the libp2p underlay address.

The experience for the user will probably be that he can scan a QR-code on his Swarm full node with the Pupa application. The QR contain information about the address, as well as authentication. The Pupa app stores this information and now allows the node to browse BZZ resources (using low-level APIs of his own Bee node).

Sharing of an URL to friends is possible with the Pupa app. A URL will contain a reference of the link to be shared, but also contains the needed information to connect to the full node to which the Pupa app is connected. Authentication may be limited (time/resources/access count/address).

A Pupa app may be exposed via different means. It may be a "normal" web2 website (pupa.ethswarm.org), which may be mirrored as it is open-source (pupa.rinke.nl). We may also release it as an application (electron) in the app-stores for mobile phone or it's functionality may be included in other applications (e.g. fairdrive mobile app).

A big advantage to the Pupa model is that it creates an additional (and I argue very strong) incentive to run your own Swarm node for a longer period of time. People like to have possibilities and if they have the possibility of accessing Swarm resources (and sharing it with friends!) by running their own node on their machine, then this is a very strong incentive to actually always run a Swarm full node. If they, on top of this, also earn some tokens, then that will be great. If we think about the future and about the this being the way to access Swarm, this means that many people will run Swarm full nodes. Not only for the money, but also for having access to the network themselves.