Make your website resilient without a gatekeeping centralized CDN.
 
 
Go to file
Michał "rysiek" Woźniak 4b9f4fb2ec Merge branch 'link2xt/redirect-follow' into 'master'
Follow redirects with `fetch`

Closes #85

See merge request rysiekpl/libresilient!29
2024-10-19 21:51:26 +00:00
__tests__ additional test for activate event handling 2024-03-13 03:35:19 +00:00
cli cli: preparing lrcli.js for tests, part 2 (ref. #66) 2022-12-11 21:48:12 +00:00
docs Fix basic-integrity link in ARCHITECTURE.md 2024-10-19 13:49:13 +00:00
lib doh.js: bugfix (window is not a thing in service workers), improved errorreporting (ref. #36) 2024-02-25 15:35:08 +00:00
plugins tests passing for work done so far for error handling improvements (ref. #36) 2024-03-06 16:33:22 +00:00
.eslintrc.yml eslint and stuff for tests 2021-08-25 19:42:43 +00:00
.gitignore Rewriting tests into Deno 2023-09-26 20:32:54 +00:00
.gitlab-ci.yml Rewriting tests into Deno 2023-09-26 20:32:54 +00:00
CODE_OF_CONDUCT.md initial commit 2021-04-06 17:18:37 +00:00
CONTRIBUTING.md Add new file: CONTRIBUTING, containing a section on AI-generated code 2023-11-10 15:51:58 +00:00
LICENSE initial commit 2021-04-06 17:18:37 +00:00
README.md added funding section to README.md 2023-11-04 17:09:39 +00:00
config.json.example MIME type sniffing 2023-11-10 21:08:03 +00:00
libresilient-fancy.js libresilient-fancy.js: UI z-index set to a high value, fixing some display issues 2022-10-08 00:13:23 +00:00
libresilient.js simplified libresilient.js, older kept in libresilient-fancy.js 2022-03-09 13:25:37 +00:00
service-worker.js Follow redirects with `fetch` 2024-10-19 16:17:50 +00:00

README.md

LibResilient

A browser-based decentralized content delivery network, implemented as a JavaScript library to be deployed easily on any website. LibResilient uses ServiceWorkers and a suite of unconventional in-browser delivery mechanisms, with a strong focus on decentralized tools like IPFS.

Ideally, users should not need to install any special software nor change any settings to continue being able to access an overloaded LibResilient-enabled site as soon as they are able to access it once.

Project website: https://resilient.is
Documentation: https://resilient.is/docs

A Quickstart Guide is available, along with Frequently Asked Questions. These are good places to start. You can also read a more in-depth overview of LibResilient here. And here is a document describing the philosophy influencing project goals and relevant technical decisions.

Current status

LibResilient is currently considered beta: the code works, and the API is mostly stable, but it has not yet been deployed in production on a reasonably high-traffic site and would benefit from real-world testing. During development it has been tested on Firefox, Chromium and Chrome on desktop, as well as Firefox for mobile on Android, but it should work in any browser implementing the Service Worker API.

If you'd like to get in touch, please email create an issue.

Rationale

While a number of content delivery technologies exist, these typically require enormous centralized services. This creates opportunities for gate-keeping, and causes any disruption at these centralized providers to become a major problem for thousands of websites.

On the other hand, visitors have at their disposal many tools that allow them to work around potential localized problems with availability of certain websites — for example, Tor, proxies, VPNs, etc. These tools, however, require the visitors to install and configure them. While useful for few dedicated users, it is unreasonable to expect large part of the Internet using public to switch to them just to access certain websites.

LibResilient explores the possibility of solving this conundrum in a way that would not require website visitors to install any special software or change any settings; the only things that are needed are a modern Web browser and the ability to visit a website once, so that the JavaScript ServiceWorker kicks in.

Development

To test the service worker locally you will need a minimal web server. Probably the simplest way is to start one directly in the project directory, either using Python:

python3 -m http.server

...or Docker:

docker run --publish 8000:80 --volume="$PWD:/usr/share/nginx/html" nginx

In both cases you will end up with a very basic webserver running locally on port 8000/tcp. You will be able to access it under: http://localhost:8000/.

Running the test suite

Tests are written in Deno. You can run them using this command in the project directory:

deno test --allow-read --importmap=./__tests__/importmap.json

If you don't have Deno on your machine, you can run them by using Docker (also in the project directory):

docker run -ti --rm --volume "${PWD}:/code" denoland/deno:1.37.0 \
    /bin/bash -c 'cd /code && deno test --allow-read --importmap=./__tests__/importmap.json'

Funding

This project is funded through the NGI Assure Fund, a fund established by NLnet with financial support from the European Commission's Next Generation Internet program. Learn more on the NLnet project page.