Battling Link Rot
Battling Link Rot
Brandon Tauszik’s journey with decentralized tools to protect his multimedia projects from the pervasive threat of disappearing online content.
Reading Time: 5min
Contents
Background
Brandon Tauszik is an independent photographer and filmmaker based in California. His multimedia projects are often built into custom website experiences. Incorporating the largely unexplored medium of cinemagraphs, as well as text, video, and 360 VR, these projects push the boundaries of digital storytelling. Projects included in this fellowship include Syria Street (commissioned by the International Committee of the Red Cross) and Facing Life (supported by the Pulitzer Center).
As a freelancer whose work tends to be hosted by a variety of publishers, Tauszik’s pieces, like the work of many freelance journalists, are often vulnerable to disappearing from the internet. Even when published by a large organization, maintaining and hosting the project websites can become a challenge.
To combat link rot, some artists, journalists, and website owners regularly update and maintain their content, which is an expensive and time consuming task. While web archiving services like the Wayback Machine and Conifer attempt to preserve websites for future reference, they generally have important limitations. For example, there may be challenges capturing password-protected sites (ex: paywalls) and services encounter IP rate limits on some domains. Once archived, users can’t make minor changes or updates, pages cannot be hosted at the original URL, nor can pages be readily ported elsewhere. The archived versions on these services are static copies of the original pages – like a snapshot in time. When creating a portable website that can move between platforms, it becomes important to have an archive with integrity – that is, one that can be verified, with certainty, to contain the original content and provide assurance that data is not misrepresented. To solve this for content creators, we explored customizable solutions that also integrated information about the provenance and integrity of a portfolio.
How We Got Here
The World Wide Web has no single owner, maintainer, nor even a single entity that governs it. What is on – and remains on – the web depends on those who create, serve, and choose to maintain it. Unfortunately, much of what is published on the web eventually disappears – succumbing to a phenomenon known as “Link Rot.”
The pervasiveness of the problem of link rot has been illustrated by studies over the years:
- A 2023 study by Pew Research found 38% of web pages that existed in 2013 had disappeared within a decade. A quarter of web pages that were online from 2013 to 2023 are gone.
- From 1996 to 2021, an analysis of roughly 2 million links in New York Times articles found that 25% of deep links no longer worked. Researchers noted the rot gets worse with age, observing that a staggering 72% of links from 1998 were dead.
- From 1996 to 2021, an analysis of roughly 2 million links in New York Times articles found that 25% of deep links no longer worked. Researchers noted the rot gets worse with age, observing that a staggering 72% of links from 1998 were dead.
Jonathan Zittrain, a Harvard professor who authored several of these studies, wrote in The Atlantic in 2021 about the implications for society: “They represent a comprehensive breakdown in the chain of custody for facts. Libraries exist, and they still have books in them, but they aren’t stewarding a huge percentage of the information that people are linking to, including within formal, legal documents. No one is.”
Contents
Context
Fellowship
In this collaboration, Brandon Tauszik teamed up with the Starling Lab for Data Integrity to understand how decentralized tools, alternative publishing options, and the Starling Framework of “Capture, Store, Verify” could be used to develop a workflow to future-proof his portfolio from link rot. Collaborating with the Sutty development team, his sites were converted to a portable version – with integrity – to make them more resistant to link rot and easier for Tauszik to maintain.
Tauszik’s past projects live on media rich websites. Each website is on a different platform and has a separate set of dependencies and assets to maintain. Currently, if Tauszik wants to preserve all the works in his portfolio, he must pay for and maintain a number of platforms. The goal was to keep his works public and available long term, ideally forever. As hosting costs increase along with the volume of projects in his portfolio, it is becoming unsustainable to maintain all his online work.
Furthermore, the older these projects become, the greater their historical significance and usefulness. Currently, if and when Tauszik is no longer around to maintain his online portfolios, all of his hosting and domain solutions will terminate once payment methods cease to be available (ex: expiration of credit cards). This is of great concern, as the passing of an artist should not cause the death of that artist’s work.
Syria Street Takedown
When one of his projects went offline, Tauszik became aware of the fragility of a portfolio that linked to content published across the web. Without notifying the communications department or Tauszik, the International Committee for the Red Cross IT department terminated Syria Street during a broad sweep of their mini-sites. Tauszik realized that ultimately, digitization is not preservation. Awarded a fellowship with Starling Lab in 2023, Tauszik sought to find the longest term, lowest cost, and safest way to host his work.
To be a successful independent journalist, practitioners like Tauszik need to be able to take control of their content, away from centralized and brittle platforms. While especially pertinent for freelancers, this is applicable to all forms of digitally published media and especially in politically unstable times.
Contents
Framework
This case demonstrates how Starling’s Capture, Store, Verify framework can protect a freelancer’s portfolio against link rot: by capturing original site states and commit fingerprints; storing redundant copies on decentralized networks; and verifying distribution with content addressing and public registrations.
The result is portability with provenance—sites that can move between platforms while maintaining provable integrity over time.
The Challenge
Link rot is a pervasive problem that threatens the preservation and accessibility of work on the Internet. How might Tauszik’s portfolio avoid the same fate?
First, access to Tauszik’s website had to be optimized for current web systems. This means availability for the longest period of time possible, with minimal maintenance and cost. One of his projects, Facing Life, was self-hosted using Flywheel and WordPress, but the hosting costs were higher than necessary for a relatively static site. Another, Syria Street, was commissioned by the ICRC and hosted on HostGator. Using these platforms for hosting largely unchanging websites without user-generated content was unnecessary and expensive.
Second, Tauszik’s work had to be prepared for future-facing hosting solutions. These include approaches that can be more secure and longer lasting. Using decentralized systems for preservation would avoid control by large tech companies, mitigating risks of vendor lock-in, extensive maintenance, and sites that are not easily portable to other platforms. The Lab also wanted to maintain the integrity of his work. In this context, that means that if the content from the website had to be recovered from archives there would be a way to prove that the content is the exact, original version preserved as a part of this project (i.e.,not edited, censored, or otherwise modified).
Contents
The Prototype
The solution for preservation and availability consisted of a few simple parts. The Starling Framework (Capture, Store, Verify) provided a clear roadmap to address the important phases of the content’s lifecycle.
Capture
The team converted Facing Life (which was hosted on WordPress) to a static site using Wget mirror options. The Syria Street website was modified to create static code (a set of HTML, CSS, and assets such as images) that can easily be hosted anywhere. This code was published and managed on GitHub.
In addition, authenticity records were created on three different blockchains. The process is akin to making a fingerprint registry to identify a human, but done for digital content. This was accomplished by taking a cryptographically signed hash (effectively, a digital fingerprint of the site), and registering that data with a blockchain transaction. Blockchains are ledgers that cannot be modified after information is added. This process establishes a record of exactly what existed, and when. The blockchain registration is public, allowing anyone to verify what code and assets existed at the time of registration, and can prove when it existed by pointing to the time of registration recorded on the network of blockchain nodes. The registration records also include signatures from Starling Lab attesting to the authenticity of this information.
Store
Once authenticity records of the site assets were recorded on publicly maintained ledgers, the team needed to preserve the assets themselves, and in a way that is not prone to removal in the way records owned by a single central entity are. To achieve this, we created ‘cold storage’ archives on Filecoin. This distributed storage network facilitates the preservation of the content across many servers called “nodes,” a resilient approach intended to withstand everything from censorship to economic decay. This continued archival storage is backed by an economically incentivized system including collateral put up by the network of storage providers.
Verify
Cold storage archives on their own are not that useful for readers. They are not easily accessed by anyone but the archiver or site asset owner. In order for a user to verify that someone has the original versions, they need to have a copy of the currently published version to compare against.
To distribute the content on peer-to-peer systems, the team turned to Distributed Press to publish copies of these on IPFS and Hypercore. The IPFS network uses unique Content Identifiers (CIDs) that make it possible to retrieve copies of the website from any one of the decentralized network’s servers that has a copy of the content. This approach, known as “content addressing,” means users only need to know the CID to look up the site. It contrasts with today’s “location addressing,” where a user must know a precise and still functioning path to the server the content is hosted on (commonly a URL starting with “https://”). Using CIDs to name and access content brings the confidence that you are getting the correct version of the content, regardless of where it is retrieved from.
Tauzik’s websites were republished using a free web publishing service called GitHub Pages, which was a simple configuration once the static code repositories were on GitHub.
Contents
Technology
The Lab applied familiar Web2 and emerging Web3 patterns, using technologies where users not only create their content with Web2 hosted service providers, but applied technology that allows users to have full custody of their content, with high agency over data and infrastructure in line with Web3 philosophies to address the challenges of link rot.
A first step to preserve the content of this project’s websites was to minimize dependencies on paid and centralized systems and software. The websites were recreated in a way to be easily – and completely – cloned and hosted in multiple places. This method of producing a “static” website means detaching it from more dependency-heavy content management systems (such as WordPress). It can be applied to many websites, significantly reducing the complexity and cost of hosting.
Once the website is in an easily replicable format, we applied Web3 patterns of decentralized storage and distribution so the website can be made available through many independently-operated servers across the world. Alongside decentralized hosting, the Lab helped to register integrity records of the content to immutable ledgers so the decentrally stored copies can be verified as genuine using these public records.
Capture
Static Websites
In order to move Tausik’s site from a platform intended to host dynamic (i.e., regularly updated) content to a static site, the Starling team worked with the Sutty development team to convert each website into a static set of code. A static set of code doesn’t rely on other software to render the web page, and no changes need to be made in order to view it directly in a web browser. Static sites can be viewed and ported over to any website hosting platform with minimal effort.
Making a website static allows it to be easily replicated and requires little maintenance. A static set of code makes it easy to archive or republish the site fully in many different places. An archiver only needs to archive the static website files, and not worry about replicating the infrastructure (e.g. the version of WordPress and the specific database system) that a dynamic website relies on to operate.
The team chose to convert the websites to static because dynamic websites (such as WordPress and Drupal) need to keep plugins, packages, and code libraries constantly up to date. This renders them vulnerable to failure without active maintenance. To keep these sites up, the owner has to check in regularly and make updates in order to avoid security vulnerabilities and downtime. This turns into labor and costs for the site owner, and is not sustainable long term.
Replicating a Static Site
Facing Life was converted from WordPress into a static website using Wget mirror options. This involves downloading the whole existing website and converting resource references (references to things like images, in the code for the site) so the website can be hosted anywhere, independently of the domain name or subpaths in the URL.
Syria Street was already a static website, so it didn’t need to be converted. The source code was recovered and used to stand up a new static site. After this, hyperlink was used to find any URL pointing to an unreachable resource on each website. This made it possible to identify and then manually fix any conversion missed by Wget mirroring. The generated archive for the website and its changes are tracked in a GitHub repository for each of the Facing Life and Syria Street sites, so there’s a history of modifications and who performed them.
Immutable Records
Once the GitHub repositories were finalized, a zip version of the GitHub repositories for each site (and assets) was dropped into the Starling Integrity Pipeline. This pipeline takes the data, signs it with a Starling Certificate (for proof of who created the archive), and processes and packages it for blockchain registration.
Cryptographic hashes (previously compared to “fingerprints”) were generated from the zipped content. These hashes were recorded on blockchains (a type of distributed ledgers) to establish a verifiable snapshot of the ‘original’ versions.
The projects were registered using Numbers Protocol on Avalanche, Numbers blockchains, and ISCN on LikeCoin. The zip files themselves were published, and therefore retrievable by content address on IPFS. Anyone can inspect the integrity of these archives by taking the txHash from the registration records and searching in the explorer (linked above) for each blockchain. You can see the Resources section at the end of this case study to explore the different registrations.
Store
The content itself also needed to be preserved in many places. No matter where these archives are retrieved from in the future, there must be a way to verify that they are not tampered with during storage. Importantly, no single provider should be able to arbitrarily delete all copies of the archive, as was the concern when ICRC’s IT department terminated the hosting for Syria Street. To make these projects available online, Tauszik published using free options to store and host the public websites.
Storage and Site Publishing
GitHub is a web-based platform that uses the open-source Git distributed version control system. This was used to both store, and collaborate on, the sets of code for the static versions of the two websites that were modified and preserved for this project. The team chose to use GitHub’s free service called GitHub Pages that allows publishing of a simple static site. GitHub Pages, however, has a repository limit of 1GB, and has a soft bandwidth limit of 100 GB per month. That means that the amount of media such as images and videos published from your repo is limited, and only so many people can ‘retrieve’ these to view a site per month. Any service offering free website hosting will have similar limits, as data storage and serving is a cost to the provider.
Since the amount of data for some of the media in this site was rather large, Git Large File Storage (LFS) was used to preserve the images. Git LFS allows tracking and publishing of large files, like the images in Tauszik’s site, on GitHub Pages, while storing these files in a separate system from the GitHub repository.
The video files published on Facing Life’s original website were embedded from Vimeo, so video files remained there. Vimeo offers free storage for these large files, which is an added benefit given GitHub Pages’ limitations.
Cold Storage Archives
Filecoin is a network of storage nodes that can archive content, or put it in ‘cold storage’ for a period of time. Users can store multiple copies (or portions of copies) across a variety of nodes, which prevents a single storage provider or IT department from pulling the plug on an archive since redundancy of storage is backed by independently operated storage providers. Filecoin uses a collateral-based cryptographic proving system to ensure that the nodes providing storage do in fact have the data securely stored. If storage providers are found to not have the data they should, they lose not only the rewards they get for providing storage, but also the collateral they’re required to put forth in the initial storage deal. Because of this cryptographic proving system, confidence that the record will be preserved is high, as any storage provider who loses the data before the term specified for this archive deal will lose their financial collateral. This is known as a “proof of space-time” (PoST), emphasizing the importance to users that their content is safe in both location and duration.
To see the storage deals and the identities of the nodes we stored this content on, look at the information on filecoin.tools.
Verify
Filecoin archives are optimized for preservation, but not fast retrieval. In order to serve the websites to readers day-to-day, we need other technologies. Having the website archives available to readers is the first step for verification. Users can download copies of the code from IPFS and inspect the sites for themselves.
Web3 Data Sharing
The websites are available on the public data sharing protocols IPFS and Hypercore, where any node on the network is able to save and serve the content (known as ‘pinning’). These systems feature:
- Distributed Hosting – No single entity has to be the exclusive source of files. Many individuals or entities can make the content available for anyone. This eliminates the possibility of intentional take down by one entity.
- Content-addressability – The CID is immutable and not location-based (location example: “https://domaim-name/filename”). If searching by the CID (ex: bafybeifple7zvk4jy2vghfuyace5l6w6zyjopygxveaffbkgd27x536hjy) it’s impossible to get a changed or modified version of the file, since the CID is generated based on all the specific 1s & 0s that make up the original content.
- Portability & Interoperability – The file isn’t locked into one system’s rules and limitations. Within seconds, it can be transferred to another node on the network as long as the systems share the same open protocol. Since the file is content-addressed, users get the exact digital asset requested (not a modified version) no matter where it originates from.
There are many options available for accessing content on these protocols, such as IPFS Gateways and IPFS-compatible web browsers. Options to access Hypercore-published content include the Agregore browser and the hypershell CLI.
Though there isn’t a guarantee for the length of time that the data will be pinned in these systems (which is the same for Web2 systems), it is more likely to be preserved and possible to quickly republish and serve content through any node in the network. These systems are more resistant to loss due to hardware failure, media obsolescence, human error, malicious attacks, natural disasters, or economic collapse since they are verifiable, peer-to-peer systems that are hosted by many parties.
Website Publishing
Distributed Press was used to publish versions of these websites on distributed protocols,. This platform makes it possible to publish static content on Web3 networks called IPFS and Hypercore, pinning copies of a site on their servers to make it available across these networks.
GitHub Pages is a feature offered by GitHub that allows users to host static websites in a traditional Web2 format directly from their GitHub repositories. This was particularly useful for the project as it was already using GitHub for version control and managing the project, as well as adding new links and information onto the page.
Domain Names and DNS Registration
Current popular web browsers remain dependent on location addressing (URLs) for users to access sites. Tauszik’s websites are linked in his portfolio at https://brandontauszik.com/, so one of the most important parts of protecting against link rot is still protecting the link (URL) itself.
When the domains were registered for Syria Street (hosted on a subdomain of Tauszik’s website as syriastreet.brandontauzik.com) and Facing Life (facing.life), the maximum amount of time the domain could be purchased from GoDaddy was 9 years.
In the current implementation, DNS is used to point to Web2 copies on GitHub Pages and Web3 copies on IPFS and Hypercore. The URLs are in the Resources section below. The files served through these URLs can be verified against the archives that are registered on blockchains.
Contents
Learnings
The motivation for this project was twofold. One, Tauszik wanted to make sure his work was available online. He wanted to have a low-maintenance website, with low to no (recurring) cost so his web portfolio is available for as long as possible. Secondly, Starling Lab’s goal was to create a website that is preserved, with integrity, for the long term, with data that is resistant to deletion or censorship. This would enable Tauszik to create a version that could be easily recovered, and a record of what the original version was (a manifest about the authenticity of this content), and when it existed. This makes a site, regardless of the platform it exists on, recoverable, in a way that can be proven, for the long term.
Site Availability and Long-Term Preservation
Data availability means being able to deliver the website to the end user at the moment it’s needed, while long-term preservation is concerned with the longevity of the data. In this project, it was easy to conflate one with the other.
For this project, long-term preservation was addressed using systems that support easy replication and high redundancy, namely IPFS, Hypercore, and Filecoin. To address site availability, originally the website was to be hosted from Web3 systems, however, as most people have browsers that do not natively support downloading from Web3 networks, they needed to access the site through centralized gateways.
Today, these gateways aren’t the best solution to be relied on for hosting a site, even in the Web2 ecosystem. They often get overwhelmed and are less reliable than sophisticated and well-managed systems by large institutions. Hosting on Web3 systems is possible, however, it wasn’t practical to host on these systems alone. This led to parallel publishing on the well-supported and free GitHub Pages platform to make the sites available online. For Web3 solutions to succeed, better Web3 infrastructure, such as gateways or applications for interaction with the protocol require further investment. Another option is to build support, in-browser, for these peer-to-peer protocols, so that infrastructure like gateways isn’t a potential point of failure. The ability to access and search data in Web3 systems from applications like web browsers will enable a jump forward in the adoption of Web3 technologies.
No Such Thing as Unlimited Free Storage or Zero Maintenance
The one thing that was underestimated at the outset of this project was the ability to ‘set it and forget it.’ In other words, this project strove to find a way to set up and pay for all the systems for a long period of time, and be secure in knowing that no one would have to make recurring payments, or worry about an account being archived or taken down. In addition, a goal was to eliminate the need to go in and maintain configurations to keep the site online.
The sites’ domain names had to be registered for as long as possible on the Domain Name System (DNS), which limits purchasing the rights to a domain to 10 years. According to ICANN (the organization responsible for managing the global domain name system), this is a limit set by their Advisory Committees for all domain name purchases.
There are several free services, including GitHub, that offer a free tier of static storage. However, there are risks involved with any free hosting service, creating a reliance on them to make these files available indefinitely. Any system that maintains the computing infrastructure necessary to make sites retrievable online is subject to changing their terms (ex: charging for a service, or taking free services down), or to the organization dissolving. There is no guarantee that any organization will be around decades from now, which is why this project preserves data in several systems, packaged as a static site that can be easily replicated.
GitHub Pages allows users to create and manage a free account with up to 1GB of free storage. As the amount of media Tauszik had in video format (including 360 VR video) greatly exceeded the amount, media storage was done outside of GitHub (Vimeo and Git LFS). It is advisable to also back up and archive these kinds of media files, as they make up a significant portion of the website.
Ultimately, publication and preservation can never be completely free of risks of disappearance. No organization, even governments, are guaranteed to be around forever. Looking toward the future, decentralized storage appears the most resilient way to preserve data for the long term. In addition, any type of preservation is going to require some maintenance. Decentralized systems and static sites require minimal maintenance, can self-repair, put data in the hands of many instead of the few, preserve integrity, and are resistant to tampering and deletion.
Static Website Optimizations
Although static websites are generally faster to access because they require no database interaction, modern Web2 sites hosted on WordPress come with a lot of plugins for optimization and distribution that make the delivery fast to end users.
After converting Facing Life and Syria Street to static websites, the site loaded slowly. The issues were identified using the Google Lighthouse tool for measuring page load speeds. To fix this issue, the Sutty team helped Tauszik with optimizations like changing the size of images on the site, adding lazy loading, and doing interlacing to improve the image load speed. After these updates, the site achieved high performance scores meaning this site would be quick to load for many years to come.
Communicating Limitations of Centralized Web Hosting
Though there is a lot of trust built up in current providers, the reality is that there are major problems with the centralized systems that our data and internet relies on today. Many of those not in the tech industry may not understand the complexities of how things are hosted online, or have an awareness that most of what is stored and served online is in the hands of a powerful few. Communicating these risks was a major part of the process in this case study. Some of the examples of the frailty and flows of centralized systems are:
- Vendor Lock in – If a vendor wanted, they can charge for free services (or make dramatic price hikes) and even charge for data access, deletion, and recovery. This could be customer services like website hosting, or the data and infrastructure such as AWS services the businesses rely on.
- Take Down or Failure – If a vendor goes under or gets acquired, they may no longer maintain or pay for site hosting.
- SSL Certification Expiry: Although less common with improved tooling and best practices, this has happened recently even for Spotify, Microsoft, and 81% of all companies in a 2-year span.
- Publication Take Down: Due to economic failure or censorship, many notable media publishers have seen their content disappear.. Examples include The Messenger, BuzzFeed News, MTV News, a variety of TV shows, and more.
- Policy Change – If users aren’t signing into a service, a host may discontinue or take down content (example: Gmail and Google Drive)
- Plagiarism & Misattribution – Without content addressed systems and a blockchain registration of a digital portfolio, it’s easy for others to claim ownership of digital media
- AI Plagiarism – People creating AI versions of a creator’s work, or using it work to train AI models and create similar content, can be an issue if there isn’t a standard for digital media provenance.
All in all, though the speed and ease of which users can access data has improved, the systems society has built to do this are less resilient and more centralized. For the moment, this isn’t immediately clear when most of what we want to access online often seems readily available. However, without physical copies in the hands of those who create it, the data we rely on – and the truth it contains – is in a perilous position, unless we start to design systems with preservation in mind.
Contents
Archive
Original GitHub Repositories
Initial work was done at link-rot-project/facing.life and link-rot-project/syriastreet.com but due to GitHub’s resource limits for free repositories, it was moved to these other locations. Issues are hosted in these archived repositories for historical purposes. The final repository that the site is published on is linked below.
Git Repository Archives
These archives can be validated against what was registered on a number of blockchains to establish what content existed as of the registration date. Each of these copies were taken from the ‘main’ and ‘nov-16’ branches of the original GitHub repositories for Syria Street and Facing Life. Each of these is a snapshot at a certain time of the repository, registered to prove authenticity
Facing Life Registration Records
Syria Street Registration Records
After the archives were created, the site and GitHub repositories were updated to include links to these archives. Copies of these were also put on IPFS so that this version could be easily ported over to a different domain and hosted as a static site. These zip files of the GitHub remain there so manual inspection can be done (by anyone) to verify what changes were made after archiving.
Validating Registration Records
Take a look at the registration records above. In there you should see a field labeled “archive“ with a sub-field of “cid”. This is the Content Identifier (CID) of that particular record that you can download from IPFS. You can fetch that record, using the identifier from IPFS using the URL `https://` + <CID> + `.ipfs.w3s.link/` This will trigger a download of that record, and you know you have the same copy as the one registered on-chain, as content identifiers are immutable. If the content were to change, the CID on IPFS would be different.
From the registration record, you can take the CID from the “archive” under “cid” and fetch it from IPFS.
Unzip the file and zip directories contained within, inspect the contents, and even serve it locally on your machine using something like http-serve for building static sites.
- facing-life-main.zip (https://bafybeifwquipmitq3yrubzhe3fmyfhjzpvl4xq3kl4ascnaucuufxk6xii.ipfs.w3s.link/)
- facing-life-nov-16.zip (https://bafybeifnd52fj6a7zy6s4be5gdzwvrfroava6h5tse3plargwfzzewvq64.ipfs.w3s.link/)
- syria-street-main.zip (https://bafybeier37nnnfqwrdyrkih6tqr7gdxxknrdrhjvbcngv67nwub45nvyce.ipfs.w3s.link/)
- syria-street-nov-16.zip (https://bafybeiholteg4em6maf4k4s3lpkqys3jyhzrwr56zxenzhljtucs2y66wu.ipfs.w3s.link)
These archives were created so anyone can inspect the two snapshots of each site (labeled ‘main’ and ‘nov-16’), validate the registrations, and download, serve locally, and look at these versions of the website, and compare the registered repositories and the ‘final’ repository to determine that only permissible edits (links to registrations) have been made since the original.
Copies of the ‘Final Published Versions of GitHub Repos
The ‘Final’ version of the sites are the versions we created after we registered the two snapshots onchain. After we registered these, we modified the site slightly – to link to GitHub repo with records of the registrations.
Syria Street
Facing Life
Website Copies Published in Distributed, Peer-to-Peer Data Sharing Systems
Since copies of this website were put on many different systems, there are several options to access them:
- Visit the URLs at https://syriastreet.brandontauszik.com/ and https://facing.life/
- Access Web3 systems using a gateway in any web browser at https://<project-name>.ipfs.hypha.coop/ or at https://<project-name>.hyper.hypha.coop/
- Syria Street
- https://syriastreet-brandontauszik-com.ipns.ipfs.hypha.coop/ (IPFS gateway operated by Hypha)
- https://syriastreet-brandontauszik-com.hyper.hypha.coop/ (Hypercore gateway operated by Hypha)
- Facing Life
- https://facing-life.ipns.ipfs.hypha.coop (IPFS gateway operated by Hypha)
- https://facing-life.hyper.hypha.coop/ (Hypercore gateway operated by Hypha)
- Syria Street
- On IPFS in a Chrome browser using the IPFS Companion browser extension or using Brave browser using the address ipns://<project name>
- Syria Street: ipns://syriastreet.brandontauszik.com
- Facing Life: ipns://facing.life/
- On the Hyper network using Agregore Browser at hyper://<project-name>
- Syria Street: hyper://syriastreet.brandontauszik.com
- Facing Life: hyper://facing.life/
- On IPFS in a Chrome browser using the IPFS Companion browser extension or using Brave browser using the address ipns://<project name>
Authorship & Acknowledgements
Journalism Fellow: Brandon Tauszik (concept, source material, portfolio selection, project goals).
Starling Lab: Collaboration on architecture and implementation of the Capture → Store → Verify workflow; authorship of technical detail and integrity processes.
Technical Partners: Sutty (static site conversion, optimization), Distributed Press/Hypha (publishing on IPFS/Hypercore), GitHub Pages/Git LFS (Web2 hosting), Numbers Protocol (registrations), Filecoin/IPFS (preservation).
Outcome: A co-authored workflow enabling portable, integrity-preserved static sites that can be served across Web2/Web3 while retaining verifiable provenance.
