Massa-web3: linking towards decentralized websites

Massa Improvement Proposals
1

massa-web3: linking towards decentralized websites

Intro

Relative links on the DeWeb

Currently, when a visitor is visiting a decentralized website, all the links towards other resources of that same website are relative (for example <img src="/img/mypicture.png"> or <a href="page2.html">Go To Page 2</a>). This allows the browser to automatically resolve the absolute URI of the resource in order to query it. Let’s illustrate this: if I am visiting https://mysite.massa.network on which there is the picture and the link taken as examples above, then my browser will automatically fetch the picture from https://mysite.massa.network/img/mypicture.png and if I click on the Go To Page 2 link, it will send me to https://mysite.massa.network/page2.html. If I am visiting the same website but from http://mysite.localhost:8080, this image and link will still work as my browser will automatically resolve their URIs to http://mysite.localhost:8080/img/mypicture.png and http://mysite.localhost:8080/page2.html respectively.

Therefore, for all relative URIs, everything works smoothly out-of-the box on the Massa deweb!

Links from a decentralized website to another decentralized website

If however a decentralized website needs to link to a resource hosted on another decentralized website, a question arises: what prefix should be used in the resource URI ?

Example: I visit mysite.massa from https://mysite.massa.network and that page needs to link towards myothersite.massa. A few options can be explored:

  • the page on mysite.massa can contain a hardwritten link towards a given provider, for example https://myothersite.massa.network but this solution has multiple issues:
    • it causes centralization around a single provider (massa.network in this example) and if that provider is down, the link will be broken
    • it forces the user to visit a pre-defined provider, not leaving the user the choice of provider (ideally local) they want to use
    • if the chosen provider is censored in a given country, the link will be broken in those countries
    • if the hardwritten provider is localhost:8080 then the link will be broken for all the visitors who have not installed a local provider
  • the page on mysite.massa can use a script to strip the provider part of the resource URI and rewrite it by inserting the current provider being used in the URI. In our example, a link to myothersite.massa/page2.html would automatically prefix the provider currently in use to query the resource: it would be https://myothersite.massa.network/page2.html when I visit https://mysite.massa.network/page2.html and it would be http://myothersite.localhost:8080 when I visit mysite.massa from a local provider).
    • That way there is no hardcoded provider and links between decentralized websites are more consistent with user choices since the provider chosen by the user is kept when accessing other deweb resources
    • The user would however not have the option to choose different providers for different resources. This is an issue if some providers block certain resources (typically through their block/allow-lists): links to websites blocked by the provider currently in use would be dead

Links from a normal clearweb site towards a decentralized website

Linking from a normal clearweb site towards a decentralized website raises similar issues as the decentralized-decentralized case above. However, since there is no “current provider” in use, automatically rewriting the URI would not be possible.

Proposed solution

To fix our issue we propose to update massa-web3 to expose a new function:

deweb_resolve(uri: String) -> [String]

That function resolves a resource URI in the format http://mysite.massa/subfolder/resource1.html?param1=3&param2=4#anchor1 to a list of available absolute links:

[
    "https://mysite.massa/subfolder/resource1.html?param1=3&param2=4#anchor1",
    "http://mysite.localhost:8080/subfolder/resource1.html?param1=3&param2=4#anchor1",
    "https://mysite.massa.network/subfolder/resource1.html?param1=3&param2=4#anchor1",
    "https://mysite.massahub.network/subfolder/resource1.html?param1=3&param2=4#anchor1",
    "https://mysite.someotherprovider.com/subfolder/resource1.html?param1=3&param2=4#anchor1"
]

then the developer of the page can choose how to present the choice to the visitor.
The list is considered prioritized from highest to lowest priority.

The way the function works is the following:

  • it first checks the URI (the domain must be in .massa) or returns an error
  • then it checks if the browser has directly access to mysite.massa adds the associated URI on top of the returned list if it is the case. This will be interesting for direct browser integration that supports .massa natively. This is on top of the list because it has the most native support.
  • then it checks the availability of mysite.localhost:8080and appends it to the returned list if available. This is to account for local providers.
  • then it loads a list of published providers from an on-chain list (see the Lists proposal) and checks the availability of the site from each of them in order to append them on the list or not

For every check, first an https request is attempted and if it fails, normal http access is attempted.

Note that if it is detected that a provider XXXX is being used by the current page, and that provider responds correctly to serve the linked resource, that provider can be listed on top of the provider list under “Keep current provider: XXXX”.

As for the on-chain list of providers, it eventually needs to be curated in a decentralized way (eg. by a DAO).

2

Hey,

I don’t think referencing a website using a link that includes a provider like https://myothersite.massa.network is a good idea. It’s a flaw of a website developer and addressing this is not responsibility of Massa.

Using scripts modifying links seems like a vulnerability.

3

I agree! What do you think of the proposed solution?

4

Simplified proposal

The above proposal is more complete but also more complex.
Here is a simplified option that pushes users towards better security and privacy:

  • if there is native support for mysite.massa, only return that possibility
  • otherwise, if there is a local provider mysite.localhost:8080, only return that possibility
  • otherwise, if there is a currently active provider, only return that possibility
  • otherwise (if there is no active provider) redirect to a deweb page that proposes two things:
    • link to install Massa Station with local provider or install a natively supported browser
    • with an UNSAFE warning, propose a link to a community-maintained list of public providers
    • the URI of the resource is passed in the arguments so that as soon as the user clicks on a provider or installs a native browser or massa station, it redirects them back to the resource they were looking for

In the provider server software, if the user attempts to visit a blocked URL, also propose that same selection page.

2 Likes
5

Hey,

This one looks good and clear.