💾 Archived View for tilde.team › ~tomasino › journal › 20200708-black-on-samizdat.gmi captured on 2022-07-16 at 14:25:42. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2020-09-24)

-=-=-=-=-=-=-

Black on Samizdat

Tonight I met rysiek [1] at a downtown cafe to try and plug his censorship avoidance software, samizdat [2], into tilde.black.

[1] rysiek on fediverse

samizdat: Interpret censorship as damage

Samizdat is a combination of a powerful service-worker and a very thin front-end script which uses the power of JavaScript for good instead of evil. Specifically it uses the service-worker to find alternate sources for web resources beyond the normal fetch operation of a browser. If you live in a region where censorship may block your access to a news website, for instance, the service-worker will fetch content from Cache in the short term, and then look on Gun for the resource. If it's newer, that thin front-end client will notify you that you can refresh to see the new info. Brilliant, right?

The Gun example is only one potential use of its plugin architecture. Currently rysiek is also exploring IPFS/IPNS as an alternate system that could be used instead of, or in addition to Gun. There's also some future thought that DAT may be fitting as well (and even Tor if a websocket bridge can be worked out by reverse engineering Snowflake).

With rysiek having two upcoming conference talks on samizdat it seemed like a good opportunity to work through the deployment process with him and iron out any issues. The biggest known challenge is that Gun is really annoying to set up and deploy content to. So we skipped it today! Instead I deployed samizdat with the simple fetch & cache plugins. These won't work around censorship on their own, but they do provide a nice cache backup if your internet goes down or if I experience DNS issues for any reason.

How it works

Lets get to the specifics on how this works, though. That's probably what you're interested in.

Samizdat is primarily a service-worker, which means that you need to be able to load the website via HTTPS at least once. That's unfortunately an innate limitation of service-workers. Once that's done, however, all future visits to that web property will have their fetch() processes hijacked by samizdat. Being that everything happens via fetch (html, css, js, images, etc) that means that samizdat can step in and help in lots of ways.

Samizdat starts by shoving every (small) resource you have into Cache for later. This Cache then becomes the master that will also be served immediately upon future visits. It's quick! But that's not all. While the Cache is being displayed, the normal fetch() process also runs asynchronously in the background. If a resource is found and is newer, the Cache is updated and the front-end client informs the user that new information is available if they refresh. But again, that's not all! Any additional plugins that are enabled ALSO run asynchronously in an attempt to find a newer resource. Gun, IPFS, DAT, whatever. If any of them find something newer than Cache, BAM! New content is cached and the front-end updates.

Practically speaking this means that if your internet is disrupted and the site is running Samizdat you'll continue to be able to get the content and fetch new content. Censorship is just treated as "damage" to your browsing experience and these alternate channels are automatically navigated to work around it. Powerful stuff.

Black specifics

When considering samizdat for tilde.black I was walking into the meeting with two big questions/concerns:

User Spaces

The first question revealed some interesting details about how service-workers apply to browsing sessions. If you load a service working on a website then it will function on that path and any child paths automatically. Since the samizdat service-worker is at the root of the tilde.black domain it will automatically run on all user pages… to a point.

I mentioned that samizdat has two parts: the service-worker and the thin front-end client. Well, this front-end client is what displays to users when cache invalidates and new content is available. If that script is not included on the page then the page will not display the message to the user that new data is available. The service-worker will continue to run regardless and do its awesome work, but a visitor may not know it.

If you are a tilde.black user and want to include this front-end snippet on your site, you can do so by adding this to your page headers:

<script defer src="/samizdat.js"></script>

Having that on your page will also initiate the service-worker if it isn't there already. If a visitor comes directly to your site without visiting the tilde.black homepage they will not have triggered the service-worker to load normally since it's only included on that page by default.

Tor

The question of tor wasn't as easily dealt with, sadly. The tor browser locks down a number of things for security reasons. Service-workers are one of these things. They can easily be misused to reveal identifying information, so it's probably a good idea in general. Thankfully, if you're using tor then you're probably working around censorship issues already and samizdat is unnecessary.

In fact, one of the stretch goals rysiek has is to find a way to build a tor plugin for samizdat that will leverage websockets and bridges into the tor network to load relevant resources for a page. This is how the Snowflake program works and is theoretically possible, though it may take some sort of resource mapping between the HTTP & Tor versions. If that pathway is cracked it would be a significant win for samizdat.

Future development

It's important to note that samizdat is not mature software. It's been a pet project of rysiek's over the last year and has come a long way in features and implementation. He is currently exploring offering samizdat-as-a-service in a way where he handles the Gun plugin portion including spidering sites for updates and scheduling pushes. It sounds like a fantastic offering for those that don't want to go through all the Gun setup and management headache. I'll be sure to help him test that bit out as it develops. Following his conference talks at the end of the month I hope to pressure him back into IPFS plugins as well.

It's a really great project with the potential to help real people facing real issues. If you have JavaScript skills or knowledge around Gun, IPFS, Tor, or other distributed protocols and want to help, you can find rysiek on the fediverse and the source code linked from the bottom of the samizdat website.

Originally Published 2020-07-08 at: gemini://tilde.team/~tomasino/journal/20200708-black-on-samizdat.gmi

If you have questions or thoughts to add please send me a link to your response.

Contact Information