gozala / lunet Goto Github PK
View Code? Open in Web Editor NEWExploration: P2P Network access through the service worker
Home Page: https://lunet.link
Exploration: P2P Network access through the service worker
Home Page: https://lunet.link
Just creating this issue so I can document use case her for w3c/ServiceWorker#1390 (comment)
At the moment lunet pretty much assumes that document loaded is an html document, however that may not be the case & it should handle that case
As I wrote in response to @patrykadas mockups (shown below). I would like something along those lines in the top right corner to communicate what application is doing at a time & have persistent way to take user to the library. Would be nice to take first stab at it as currently long loading times often provide no feedback and appear as not working.
If someone would like to help with this that would be absolutely welcome.
At the moment meta tag is used to set the IPFS path for the site being hosted, however it's problematic because on first load SW will cache and there for CID updates do not propagate. Either way HTML and meta tag isn't ideal so here are couple of alternatives to consider:
It might be a better idea to use DNSLink in which case SW could lookup CID via /api/v0/dns/
to figure out what the CID is and cache it locally. Occasionally it could check if it was updated and take that into account.
At the moment lunet looks at the meta tag and passes query argument to SW script. Instead of meta tag however we could pass CID to importScripts
instead in which case update of CID will in fact cause SW update as well.
We could leave everything as is. Just add some code to SW to quire index.html every now and then to pick up updates.
At the moment SW proxy does forward ArrayBuffer
for request / response bodies. Which seems to work in use cases currently being proved, however it won't be able to handle things like video streams etc...
Ideally ReadeableStream
would have being made transferable, but sadly they are not (, at least yet). In order to support this we need to polyfill that via MessagePort
API. We could either create one per request / responce and send it over with response or alternatively multiplex via same MessagePort
. Former has benefit of not needing to keep track of request IDs, however later might have non-negligible impact on memory use.
lunet.link should just register protocol handlers for ipfs
, ipns
, dat
, etc... to decouple system from the lunet.link
host.
That way each participant is free to deploy own lunet or choose compatible alternative while keeping all the links functional.
At the moment each app is hosted by an author on some domain which on first load imports lunet client which will setup a service worker to load app and generally make it available across sessions online or offline without having to interact with servers.
@jimpick and up implementing a simple server which generates bootstrapping doc / sw from subdomain. Specifically when loading https://cid.lunet.link/
it would serve html which mounts corresponding cid and lunet.js
SW script.
@autonome in our conversation made a good point that user in this case needs to trust lunet.link
because all the apps do more or less go through it.
This got me thinking about alternative way to architect lunet that would address both things in a really neat way.
https://lunet.link/
could be just a static site with a service worker setup such that when say https://lunet.link/peerdium.gozala.io/doc
is loaded it will redirect to https://lunet.link/?redirect=peerdium.gozala.io/doc
which will install SW and redirects back to https://lunet.link/peerdium.gozala.io/doc
causing a SW to serve it.
Note: Redirect will only happen only if
https://lunet.link/*
never had being loaded in the past, in all other instances it SW will just serve it.
SW on request to https://lunet.link/peerdium.gozala.io/doc
will do following:
Will lookup dnslink TXT record to determine CID, let's say it's a $cid1
.
Note: navigating to
https://lunet.link/$cid1/doc
will be equivalent, except we won't need to do DNS TXT lookups.
Will respond with a following markup:
<html>
<body>
<iframe sandbox src="://${cid1}.lunet.link/doc` />
</body>
</html>
lunet will serve same thing under all subdomains meaning that cid1.lunet.link
will just register SW which will route requests (similar to how it's done today) to the corresponding client document in this case cid1.lunet.link
that will route them back to the parent doc https://lunet.link/peerdium.gozala.io/doc
which will take care of fetching cid1 from the IPFS and serving it.
In this setup lunet.link
becomes commodity, you don't have to trust it. You can deploy it anywhere (in fact fork github repo & enabling gh-pages probably will do fine). So in a way it addresses point made by @autonome you don't have to trust it just fork & deploy, best part being you'll need to load it once per device.
We remove whole bootstrapping out of the equation. Knowing CID is just enough, better yet on first load we could allow user to choose to "install" it in local namespace meaning map it to say https://lunet.link/peerdium/
. App could provide name suggestions, lunet could pick on that isn't taken and allow user to use that or override in place.
Unlike current setup which requires app / site to cooperate (by serving bootstrap code which embeds lunet client from that domain) it always doc from own subdomain which will then serve corresponding app / site. In other words no cooperation is required.
In a way we are removing dependency on DNS, well not really because we made it far more loosely coupled because
User can just use CID
User can map to whatever name desired.
In a future we could offer alternative name resolution from DNS (web of trust anyone ?)
We put browser in your browser! However maybe in a future we could remove top browser layer.
Lunet applications are provided data from library they will work with, however app maybe lunched without a data (first run for instance). It would make sense for an app to provide a template data that is used in such case, any write to data would result in template + changes being written into user library.
At the moment dealing with UI is probably not the best use of our time. Instead we can create special URL pattern such that navigating to it would add a pinning bot to the lunet. e.g.
https://lunet.link/@invite/pinbot/https://mypinningbot.sh?token=apiAccessToken
Above will add pinning service with a name pinbot
to the registry. On pin requests it would issue request to the provided url https://mypinningbot.sh?token=apiAccessToken
and pass API access token via query argument.
Lunet will not know when user wishes to pin data there. In long term app will issue request to lunet triggering share user interaction, where user will be able to choose who (bot or person) to share with. But in the meantime we could introduce yet another URL pattern to address that e.g.
https://lunet.link/peerdium.gozala.io/${CID}@pinbot/`
Could tell lunet to load CID
document into peerdium.gozala.io
and pin all PUT requests into service named @pinbot
.
At the moment app url could be changing but that is not reflected in the acutall address-bar as app is loaded in <iframe sandbox>
.
We need to intercept pushState / popState / hashchange / load events and reflect those in address-bar.
Similar to Dat support #10 there is nothing preventing SSB support. In fact I think there is some opportunity to find synergy across protocols and I would absolutely love to explore future where these things could co-exist and enhance each other.
I think there is some interesting opportunities to bridge protocols like ipfs, dat, ssb instead competing. The way things are designed to work it does not matter what protocol has being used to deliver app or publish to. In fact app can be coming from one and data from another. While things are already complicated & there are obvious risks in making it even more complicated I still thing there is a huge opportunity to find synergy across protocols that currently lacks.
At the moment implementation uses CIDs
directly.
https://lunet.link/peerdium.gozala.io/
https://lunet.link/QmYjtd61SyXU4aVSKWBrtDiXjHtpJVFCbvR7RgJ57BPZro/
However maybe it would make more sense to follow follow a pattern used by IPFS already:
https://lunet.link/ipns/peerdium.gozala.io/
https://lunet.link/ipfs/QmYjtd61SyXU4aVSKWBrtDiXjHtpJVFCbvR7RgJ57BPZro/
https://lunet.link/dat/e56c7ad7bb3d27f516970d14ee5cb9d2cfa7eb15184278cf5a2dd5bbccd02a6b/
On one hand it makes URLs less usable, on the other hand it makes it more clear what underlying protocol is being used. Another alternative could be:
https://lunet.link/ipns://peerdium.gozala.io/
https://lunet.link/ipfs://QmYjtd61SyXU4aVSKWBrtDiXjHtpJVFCbvR7RgJ57BPZro/
https://lunet.link/dat://e56c7ad7bb3d27f516970d14ee5cb9d2cfa7eb15184278cf5a2dd5bbccd02a6b/
I think there is an opportunity for app to smuggle data by navigating to some controlled URL like smuggler.io?data=....&redirect=...
that would capture passed data and then redirect back to the app to stay unnoticed. We need a way to find a way to prevent such behavior.
Another maybe even more effective way to smuggle data might be to load <iframe src='//smuggler.io/' />
and keep passing data through postMessage
.
Need to verify if combination of CSPs and SW can prevent this behavior of if there are some other mechanism to do so.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.