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/

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.

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

This would address this TODO:

And also simplify bunch of code all around.

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.

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.

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.

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:

1. 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.

2. Will respond with a following markup:

   <html>
   <body>
      <iframe sandbox src="://${cid1}.lunet.link/doc` />
   </body>
   </html>
   

3. 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.

Why / How is this better

1. 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.

2. 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.

3. 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.

4. In a way we are removing dependency on DNS, well not really because we made it far more loosely coupled because

5. User can just use CID

6. User can map to whatever name desired.

7. In a future we could offer alternative name resolution from DNS (web of trust anyone ?)

8. We put browser in your browser! However maybe in a future we could remove top browser layer.

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.

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.

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.

Just creating this issue so I can document use case her for w3c/ServiceWorker#1390 (comment)

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:

DNSLink

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.

Pros

• No need to deal to generate anything, meaning all the every app / site could just point to static site returning same html / sw js.
• config free!

Cons

• Updating DNS records isn't necessarily an improvement. Use of IPNS might be a way to avoid however IPNS update in practice propagates even slower than DNS records do.
• DNS Lookup requires a server in case of in-browser implementation.
• Everything will need an origin in this instance.

CID in importScripts

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.

Pros

• Fixes the issue

Cons

• Awkward way to configure / update

Just fetch index.html occasionally

We could leave everything as is. Just add some code to SW to quire index.html every now and then to pick up updates.

Goals

• Use may want to pin data in the remote IPFS node for availability.

Proposed solution

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.

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.