@rysiek before i forget, i wanna bug you about running a samizdat instance on tilde.black somewhere soon.

@tomasino let's do it

@rysiek @tomasino Is there a tutorial for samizdat? How it works...?

@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

@rysiek @tomasino It’s nice to minimize traffic over IPFS thusly, eh? No need to fetch what is already on tap.

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

@rysiek @Shufei it'll be a fun test on tilde.black for sure! I have the site available on tor already so seeing how it all plugs in with actual content will be fun.

@tomasino @Shufei it would also be a good test case for the deployment procedure -- and an opportunity to simplify it.

Patches welcome! (in fact, I just merged a patch from @syntax, woo!)

@rysiek @tomasino @syntax So, the site with the server has to be outside the firewall or can it be inside? Let’s say there’s a company town called... Zhima. If Zhima blocks all Samizdat servers from outside its LAN, can someone run it inside? Would it be less trouble for someone with a subnet to do so?

@Shufei @tomasino @syntax readers need to be able to access the site *once* via https so that Service Worker gets loaded and kicks in. After that all content can be served via IPFS and from cache (and via any other hypothetical plugin).

The "fetch once via https" thing is a requirement of the Service Worker specification, and is there because you don't want an adversary injecting a malicious Service Worker to a site they don't like. I have not found a way around it.

@Shufei @tomasino @syntax however, the https site can be just a basic index.html with the necessary JS to kick-off the Service Worker. Nothing else needs to be there, from that point on everything can be fetched from IPFS or whatever.

So, it could even be a super-damn-simple site on some huge hosting thingy, with *no content* on it. All content would then live in IPFS. The hosting company would get the metadata of the first connection from a given user, but nothing else.

@Shufei @tomasino @syntax now, pushing content to Gun and IPFS is a separate thing. I am honestly not sure how it manages with NATs and firewalls.

I am hosting my IPFS node myself, and as part of the publishing pipeline I push content to it, and then fetch it *from a different public node* so that I know it actually propagates.

But it would be possible, I think, to push to some public node somewhere.

@Shufei @tomasino @syntax tl;dr:

1. you need a basic HTTPS-enabled site, can be anything as long as it can serve the necessary JS for the domain
2. you need a way to publish data to Gun and IPFS; would need to check if/how this can be done using only public instances.

@Shufei @tomasino @syntax here you go: https://0xacab.org/rysiek/samizdat/-/issues/46

Also, I think I misread your question -- yes, you could run a Samizdat-enabled website *inside* the firewall as long as you can ensure a working https connection at least once.

@rysiek @tomasino @syntax Yes, that was my concern, if the Samizdat server sites were blocked.