@rysiek before i forget, i wanna bug you about running a samizdat instance on tilde.black somewhere soon.
@tomasino let's do it
@Shufei @tomasino I started working on deployment docs here:
https://0xacab.org/rysiek/samizdat/-/blob/master/DEPLOYMENT.md
There is also some basic documentation of #samizdat architecture:
https://0xacab.org/rysiek/samizdat/-/blob/master/ARCHITECTURE.md
I need to work on those, and on making deployment simpler; there was some work done but I hit a bug in Gun.js, perhaps it's fixed.
Also, I need to write an IPNS+IPFS plugin, which would be easier to deploy in some cases.
And I have a #HOPE2020 talk and a #RightsCon2020 tech showcase on Samizdat end of July. Oof!
@Shufei @tomasino but basically there is a service worker that handles all requests for a "samizdated" website; if regular fetch fails, stuff is retrieved from local cache, and in the background requests through Gun+IPFS continue.
If there is newer stuff from IPFS than what's in cache (for certain definitions of "newer"...), that is cached and displayed next time. The user should get a message then saying "refresh for newer content".
There's still plenty of stuff to do to make it seamless.
@Shufei @tomasino now, all of this is implemented by plugins, so it's ~easy to say "don't even use fetch, always just IPFS it" or "instead of IPFS use <this-new-plugin-right-here>".
Plugins are here:
https://0xacab.org/rysiek/samizdat/-/tree/master/plugins
And here's the main logic running them:
https://0xacab.org/rysiek/samizdat/-/blob/master/service-worker.js#L283
@Shufei @tomasino yeah. Depends on the website, really.
For many websites, #Samizdat will be mostly a fall-back in case stuff does not work.
But it totally makes sense that for some content will only be available via IPFS or whatever. It might offer a Tor plugin in case that's available for some reason, for example. It might implement WebTorrent.
Thing is, fetch remains the fastest. Tor, IPFS, others will always be somewhat slower. Trade-offs are a thing.