Dripline

Pollen & Nectar

2026-04-16T00:00:00+00:00

Last month, Hypha member Udit and I attended Atmosphere Conf. We had a great time! Hanging out with people in person confirmed what we had been seeing across our feed for months: the Atmosphere is a vibrant and growing ecosystem we’re excited to be a part of.

We made our first foray into the protocol in February with spores.garden, our digital garden game, learning how to write lexicons and engage with the community. Emboldened by how easy it is to build on AT Protocol, we decided to explore a new direction for the conference.

We ended up doing a lightning talk where we demoed our new projects Nectar, an API for image search and Pollen, an image annotation browser extension. With Pollen, you can make claims about an image in a post (“this is my photo”, “this is AI”, etc.) and those claims will be shown to the user when that image is reposted, even with slight modifications.

Motivations

Before we get into the technical details, let’s take a step back: why are we doing this project? The idea came out of our long-time collaboration with Starling Lab, an academic research lab that establishes trust in digital records. In the past we’ve written about our metadata storage system, Authenticated Attributes, which allows journalists to make secure claims about their media files. Having our own custom, cryptographically-secured database to store metadata is a system that worked, but it had issues.

One major issue was identity. We had keypairs for each journalist or organization using our system, which was already tricky. But even when we managed the keys, we still had to provably link the public key to the person to establish trust; for example, by posting the key on the journalist’s website or social media. This made for a manual and error-prone identity system, especially since we didn’t have a specification to follow.

Another challenge was content matching. Our database was oriented around cryptographic hashes of media, so every piece of metadata would be in the form “person X says Y about file Z”. This is good for data integrity, to ensure that files are never modified. But it made applying Authenticated Attributes to social media impossible, because platforms compress images and remove metadata, and users screenshot and edit. The hashes never matched, and so the metadata we stored was not useful outside of our archival context.

As AT Protocol gained popularity, we realized it has a lot to offer from a digital trust standpoint: a standardized system that people already use, which handles identity, signatures, distribution, and storage. Furthermore, it has a large social network using it (Bluesky), so referencing social media images is a lot easier. The final piece of the puzzle is perceptual hashing, which we covered recently. This technique allows us to refer to image content itself, even if the underlying bytes are modified.

Putting metadata on AT Protocol—while useful—is pretty straightforward, amounting to simply storing JSON in a PDS. For our talk we wanted to take things a step further, and showcase what’s possible once perceptual hashes are applied: matching metadata across images!

Nectar

To make this possible, we created Nectar: an API to search for similar images across AT Protocol. It indexes records that contain image blobs, and calculates the perceptual hash of each blob, discarding the image itself. It also indexes records that contain perceptual hashes themselves (in our PFP format, a DASL spec), and extracts the hash value.

Having a database full of these hashes allows for queries like “given this image, show me all the Bluesky posts that have similar images”. The API hashes the given image, and then queries the database for all the indexed records in the app.bsky.feed.post collection that have image blobs that are similar enough to the given image. Similarity is calculated using Hamming distance between perceptual hashes, and is accelerated through database indexing.

We think having an API like this enables a lot of interesting use cases. With Pollen, we explored one specific use inspired by our work at Starling Lab: fighting misinformation by adding context to images.

Pollen

Pollen is our flagship demo of what Nectar makes possible, created in collaboration with Starling Lab. It’s a browser extension that alters the Bluesky web interface, adding a small “Claim” button to images in a user’s feed. This allows the user to make claims about images, entering them into a text box.

Adding a claim to an image in the Bluesky web app with Pollen.

That claim gets added to the user’s repository, via the credentials we already have since the user is logged in to bsky.app. Here’s an example of a real claim record:

{
  "cid": {
    "$link": "bafkreibyapnszif4do2hmruy7nsmrfdhc75np3qypox75c46tpi2pe2lme"
  },
  "pfp": {
    "__pfp": "paeqeix3fx5nnv27yngyfeucikjug2qw6jtwdmtgnlgzglnmwfmzgvsq"
  },
  "$type": "coop.hypha.pollen.claim",
  "content": {
    "text": "Test",
    "$type": "coop.hypha.pollen.embed.text"
  },
  "subject": {
    "cid": "bafyreibpuy564ul7hp7thr5ajis3eqaikelqa26m2zvtpqqtv2ixnuvysi",
    "uri": "at://did:plc:m6rd3glyjmmmsvzcvomsvwsp/app.bsky.feed.post/3mgpq4mmjtk2d"
  },
  "createdAt": "2026-03-25T20:46:30.368Z"
}

This record lexicon (the schema) was carefully designed to hold some key information:

The CID of the original image, for data integrity and provenance
The PFP (perceptual fingerprint – the perceptual hash) of the image, to match across image files
An open union for claim content, just a simple text field in this case
- This could be extended to support structured data like geolocation
Subject: a “strong ref” to the original post the claim was made on, for provenance
- This is optional, since not all claims will be made in reference to other records
- For example an archive might want to publish metadata about the objects they have, before anyone posts them on Bluesky
A creation timestamp – this is forgeable, but useful in most cases anyway

Compared to our previous work with Authenticated Attributes, this provides not just data integrity, but also a record of the visual content in the image, for matching later. We don’t have a trusted timestamp anymore, but this could be added in the future.

The final step in using Pollen is displaying that claim, even on different (but visually similar) images. This is where the Nectar API comes in. For every image the user sees while scrolling through their feed, that post is submitted to the Nectar API, and the hashes are returned. The extension then queries the API for any coop.hypha.pollen.claim records that have similar hashes. If there are any, they get displayed by the extension inline with the post. If the claim was originally made on a different post, extra information is displayed, like how visually similar the image is (according to the PDQ algorithm) and a link to the original post.

A user’s post is contradicted by a Pollen claim from a news organization (example).

Overview of the Pollen service architecture.

Pollen is an experiment, but you can try it out today on Firefox or Chrome.

Nectar in other contexts

Pollen is one use case, but other kinds of projects could be enabled by image search: social research, moderation, rights management, community notes, information integrity, and more.

Being able to connect similar images means you can track reposts across the network, and see how often certain images are being posted over time. This can be used for social research, to track the spread of misinformation, or for Trust and Safety, to moderate unwanted images.

Pollen allows for image claims in bsky.app, but there are several other ATmosphere applications that already support annotations on things like webpages. Nectar could allow these app users to annotate images directly, and see the annotations other users have made.

Finally, we see Nectar as a necessary component for integrating a Community Notes-style feature into Bluesky, allowing notes to go beyond individual posts. Pollen is a demo, but true Community Notes would be really powerful for a social network of 40 million users.

If you’d like to use Nectar in your project or explore what’s possible with Pollen, please reach out!

Navigating Media Publishing in an Agentic World

2026-04-07T00:00:00+00:00

Let’s say you wanna watch a movie in theatres. A good movie please, an artsy flick with limited distribution, ideally subtitled, in a space with no teenagers and a lobby cocktail bar. You ask your AI assistant: “where can I watch an artsy film in an indie theatre in Toronto this weekend?” Your assistant does a couple of web searches and comes back with some suggestions. One of them appeals to you, so you go directly to the theatre’s website and buy tickets. Congratulations: you are destroying the publishing industry.

Here’s the problem: to get you those results, your AI agent had to read a number of different websites, including, in this case, torontoguardian.com, todocanada.ca, moviefone.com, cinemaclock.com, as well as sites like ticketmaster.ca, hotdocs.ca or tiff.net. These two groups of results are quite distinct: the latter set of websites exists exclusively for you to have a place to go to to buy tickets. The website is a storefront for a product, namely movie tickets. The former group, though, is selling you the content of the website itself.

This made sense in a world where you were the one doing the searching. If you landed on cinemaclock.com you’d see their banner ad. Landing on thestar.com would show you their paywall and invite you to subscribe to read the article. Social media complicated this picture: Twitter users would screenshot content and serve as informal mediators for content. AI has only made that mediation steeper. Now your agent is landing on those websites, often skipping their paywall, and synthesizing the results to present them to you. The AI agent relies on these sites to get you your results, but the people who do the work of maintaining and populating them are not being compensated at all.

Fortunately, circumventing AI-driven content mediation is actively being addressed in the publishing industry. Multiple solutions are emerging to address different aspects of this fundamental problem; some of these solutions are open, some are proprietary. Some are interoperable, while some lock publishers into specific vendors. This piece will attempt an overview of the current landscape. As such, some of the specific solutions identified will likely be outdated by the end of the year, but the different layers and their specific requirements will probably stay the same.

Layer 1: Visibility

Let’s say you run a website that is, you suspect, being crawled by agents. The first step in solving any problem is to quantify it: you need a way to identify which agents are crawling your website and how often. This turns out to be the hardest single problem to solve. There is an open standard, RFC 9309 that says robots should identify themselves via the “User-agent” header–a piece of information carried by every request to your site that declares “I am entity X”. Another draft open standard, web bot auth builds on RFC 9421 to provide a richer, cryptographically-signed claim that allows an agent to declare not just which agent they are, but which company is actually hosting the agent. This is increasingly important in a world of open-weight agents that can be whitelabeled and served by different entities.

Both of these, however, are a voluntary self-declaration, and there is no enforcement to make agents self-disclose at all, or to self-disclose in honest ways (you’ll find this is a leitmotif in this piece). Agents in the wild have been found to misrepresent themselves as humans running web browsers. Even when they don’t pretend to be humans, agents often self-report in problematic ways. Google’s AI agent, for example, is indistinguishable from Google’s regular crawler, so it’s impossible to distinguish between “agent-mediated user traffic” and “Google indexing our page to make it search-discoverable.”

The best solution in this space seems to come from Cloudflare, whose AI Crawl Control product uses machine learning heuristics to identify traffic patterns as originating from AI agents. This can be enabled by any Cloudflare-fronted website for free today, which is great news if you’re already in Cloudflare, and locks you into a new vendor if you’re not.

Layer 2: Rights Expression

So you’ve either enabled crawl control or created a visibility layer to surface whatever honest user-agent data you’re able to get. And it turns out agents love to read your content; now you want to get paid when they access that content. The “how do I get paid” question decomposes into several layers, the first being simply “How do I state that I’d like to get paid?”

Fortunately, there is an open standard named Really Simple Licensing (RSL) that allows content providers to state, in machine-readable form, exactly what licensing terms apply to their content. This enables you to declare terms like “Pay me 5 cents per crawl via settlement protocol x402”, or “If you’re agent X, you may access through a separate licensing agreement with vendor Y,” or even “Please negotiate terms of access with my publishing collective at xyz.org.”

The IETF has also put eyes on this layer, establishing an AI Preferences Working Group that aims to produce an open standard by August 2026, building on HTTP headers and the robots exclusion protocol in RFC 9309 to create a standardized internet-native vocabulary to allow content rights holders to express terms of use for their content by robots. If ratified and widely adopted, this new standard could converge with RSL to produce one unified rights expression layer.

As you may surmise, it’s vital that this layer operate through an open protocol precisely because it’s able to express settlement terms that operate through proprietary protocols. Vendor lock-in at this layer would forever lock content providers to specific licensing agreements or settlement layers.

Layer 3: Settlement

You can think of RSL as a way to hand over a bill that says “You owe X dollars, we accept Visa, Mastercard, and cash.” The settlement layer is the credit card terminal that actually allows others to pay that bill. There are many solutions at this layer, and new ones seem to emerge every day. It’s impossible to provide a full accounting of everything that’s available at this layer, but we can draw some broad trends.

Firstly, there’s the open protocol x402. This allows agents to natively settle transactions in stablecoin, or fiat, with no middleman (other than the payment protocol itself) taking a cut. You provision a wallet for your agent, give it a budget, and the agent draws funds whenever it accesses content. This is the most technically open solution, which is inevitably why it has the highest barrier to adoption: current implementations require everyone to be on blockchain, and traditional settlement protocols would need to implement new primitives to enable x402 through fiat.

This is where settlement layers like lobster.cash come in. Lobster cash is integrated with Visa’s proprietary Intelligent Commerce tech to provide an API that allows agents to create virtual Visa credit cards (with spending limits) that they then draw from to pay for content on crawl (or, indeed, to pay for anything). This enables content providers to receive credit card payments directly. The agent credit cards can be paid off via conventional banking methods. If your website is on Cloudflare, their upcoming pay-per-crawl solution works similarly.

What the above solutions have in common is that they essentially present agents with a spot-price to pay for your content, and then provide a settlement mechanism per crawl. They’re basically microtransaction engines. This is challenging to implement: why would the agent pay instead of bouncing to the next search result? Solutions like TollBit work differently, by acting as an intermediary between content creators and AI agents, negotiating rates with the latter, metering access, and passing on a portion of revenue to the former. When an AI provider has an agreement with TollBit, their agent is allowed to crawl TollBit-licensed content without having to pay at the point of consumption. This creates a mediated relationship, similar to how platforms like Spotify work, between listener and content producer, with the result that content providers have access to bargaining power they wouldn’t have on their own, at the cost of vendor lock-in and a portion of proceeds.

“Wait,” I hear you say, “isn’t Spotify awful for artists?” Oh yes! Surrendering your bargaining power to a middleman really only shifts the problem down: who negotiates with the negotiator? What happens as the portion of revenue that they pass on to you, the content provider, shrinks and shrinks? One solution for this problem is provided, again, by the music industry: collective management organizations (CMOs) are a long-established way for content providers to come together to bargain with organizations that want to consume their content. Publishing CMOs have already started to strike deals with AI companies. The open alternative is something like the RSL collective: an open collective of publishing platforms and online publishers that enables its members to collectively bargain for deals with AI providers.

Ultimately, the settlement layer is the most complex and important of all because, well, someone’s gotta move the money, and whoever does will take a cut. This layer will likely continue to see rapid development in the next few years, with a multitude of ad-hoc solutions emerging.

Layer 4: Enforcement

So you have a way to hand agents a bill; they have a way to settle the bill. But can you stop them from leaving your content restaurant with a full belly without paying the bill? This is the enforcement layer, and it subdivides into two distinct problems.

The first question is simple: how do you block access when payment hasn’t been settled? This is, broadly, as easy as setting up a paywall, with a couple of caveats. Most publishing organizations today use client-side paywalls that serve the whole content upfront then use frontend code to hide it until users pay. This does nothing to deter agents–they can simply refuse to execute the paywall code. Migrating to server-side paywalls is the easy intervention here. Next, the paywall needs to be legible to agents as something they can interpret. To this end, server-side paywalls need to be served with the 402: Payment Required HTTP status code. There are also simple ways to associate a paywall response to an RSL license, allowing agents to quickly navigate the licensing gate. Integrated solutions like Cloudflare or TollBit’s do all of these things end-to-end for their users.

The next question is trickier. Once an agent has settled payment, how do you ensure it’s using the licensed content in the ways the license provides for? Agents could choose to, for instance, request data as though they were crawling it for a user response, then use it for training. Malicious agents could go as far as to pay a licensing fee, crawl the content, then rehost it on BitTorrent or IPFS. Again, Cloudflare has a solution here: they explicitly verify bots, and disallow any access to unverified bots. If you misbehave, your bot gets delisted and you can’t access content anymore.

Open solutions are also emerging in this space, including ERC-8004 which seeks to establish an open reputation system. When a bot hits your site, you can verify its public reputation based on interactions it’s had with other sites to decide how to proceed. These reputation systems will most certainly expand. For instance, we will likely soon need reputation systems not just for bots themselves but also for the prompts they’re running. When anyone can deploy an open-weight model like Qwen3.5 on commodity hardware, it becomes much harder to tell who the mediator is: is it the Qwen model itself? The Qwen code harness the model is running inside of? The company hosting the harness? The set of skills the harness has access to? The question “can we trust this agent” becomes more about being able to determine if the intersection of all these things–model, harness, skills, organization, user–is trustworthy. Of course, as long as the cost to list a new bot is low, this can lend itself to a game of whack-a-mole where new malicious bots are spun up to replace the banned ones.

This is why the ultimate enforcement layer is law enforcement. It’s already illegal to program a robot to crawl licensed content and rehost it on BitTorrent. The way this has conventionally been enforced has been through lawsuits, and there’s no reason to think any technical solution will ever supplant a well-functioning judiciary. Legislative action will be needed to ensure a level-playing field. Canada has taken some steps in this direction with bill C-18, showing the federal government is aware of the need to protect the Canadian media landscape. Perhaps the determining factor here is the balance of power between plaintiffs and defendants. Lawsuits where multiple plaintiffs come together to sue big tech companies are much likelier to succeed than lawsuits where those plaintiffs stand alone.

Conclusion

Media publishing revenues have been on the decline for over two decades. Competition from amateur content on social media, the general willingness to trade personal data for free content, and the ease of implementing technical solutions that hop firewalls have all contributed to a sense of urgency media publishing. The emergence of AI agents can be another milestone en route to a world of exponential mediation for content creators, or it can be a pivot point. Agents simplify discoverability of published content, make it possible to process and make sense of large amounts of written language quickly, and potentially automate licensing negotiations and payment settlement. The building blocks are there to create a more equitable future for media publishers. Radical changes are alarming, but if media publishing is to survive, the future will belong to visionary organizations who can leverage this technological disruption to turn crisis into opportunity.

Introducing Rook: Sovereign Intelligence for the Solidarity Economy and Beyond

2026-03-13T00:00:00+00:00

Projects move at varying speeds: some shift rapidly from ideation to product while others take a slower and more thoughtful approach. For Rook, Hypha’s new agentic knowledge management tool, we’ve been deliberately considered about how and why we move into the AI space. This is not only because the market is a little saturated with LLM-esque tools, but also because we wanted to offer something that could be useful to organizations working within and serving the solidarity economy, as well as arts and cultural institutions, and organizations who value digital sovereignty and data privacy. Emphasizing care and consideration might be anathema to the typical AI product release cycle, but these values, along with quality, are what make Rook different.

Rook is powered by your organization’s data. You give it access to the files and folders you want it to query, and it then returns responses based on that data. Nothing is ever trained on your data, and the infrastructure is configured to be privacy-preserving. Our demo, which you can see here, gives you an idea of how Rook could work with your organization’s knowledge base.

At Hypha, we’ve been using this AI knowledge management tool internally for over a year, building it out under the open source project known as RooLLM (named after our digital office pet). And while much of this work will remain open source, for organizations lacking an internal IT department, we wanted to make the tools accessible as a product that Hypha can customize and deploy for interested organizations.

In keeping with our thoughtful approach, today’s announcement is more of a soft launch, as we’re looking for partners to help us make Rook the first choice tool for privacy-conscious social enterprises, cooperatives, cultural organizations and progressive thinktanks. Hypha is pleased to announce that we are already collaborating with jason wiener | p.c., the preeminent law firm for mission-driven companies, social impact, and environmental enterprise. Based in Boulder, Colorado, Jason and his team have already provided valuable feedback on Rook’s response quality, and on data privacy considerations.

We are actively seeking organizations interested in supporting Rook as a key piece of the solidarity stack. Get in touch if this resonates with you.

Fixing the ‘dumb opinions’ problem: Addison, Johnson, Walpole

2026-02-25T00:00:00+00:00

“Are things really gettin’ better, like the newspaper said?
What else is new my friend, besides what I read?
Can’t find no work, can’t find no job, my friend
Money is tighter than it’s ever been
Say man, I just don’t understand
What’s going on across this land”

– Marvin Gaye, “What’s Happening Brother”

On March 12, 1711, Joseph Addison (1672-1719) and Richard Steele’s (1671-1729) seminal publication, The Spectator, published its 10th issue.¹ Celebrating the “becoming Seriousness and Attention” with which his Morning Lectures were received by the public, Addison took advantage of the occasion to explain the project: “to enliven Morality with Wit, and to temper Wit with Morality [… to bring] Philosophy out of Closets and Libraries, Schools and Colleges, to dwell in Clubs and Assemblies, at Tea-tables, and in Coffee-houses.” Two hundred and fifty years later, the German social theorist Jürgen Habermas would come to see this moment as a milestone in the formation of “the public sphere,” that arena of social life in which “private people come together as a public,”² to comment on the issues of their day.

The Spectator was far from the first serial publication to reach a broad audience of readers in England. Indeed,³ the oldest surviving news publication in English dates to 1513, a simple dispatch announcing the English victory at the battle of Flodden. Such dispatches were printed sporadically throughout the 16th and early 17th centuries, particularly in times of conflict, when the public was anxious for news from their armies abroad. By the second half of the 17th century, these ad-hoc dispatches had been supplanted by an intricate network of handwritten newsletters–some of them state-sponsored, some of them informal–that were read by individual correspondents to keep in touch with events abroad. These correspondents would then read the newsletters to their coffeehouse friends, or use them as sources for printed periodicals. The vicissitudes of the English Civil War, the Restoration, the Popish Plot, and the Glorious Revolution meant that censorship was intermittent throughout this period. Newsletters were routed through the Dutch Republic, where authorities were generally more permissive, while printed newspapers were spun up and shuttered according to the changing whims of princes.

1695 saw the lapsing of the last censorship bill in the United Kingdom, and the publishing landscape was transformed. Elizabeth Mallet is generally credited with launching the first English language daily newspaper, The Daily Courant, on the 11th of March, 1702. The very first issue⁴ reproduces news from the Amsterdam Courant, the Harlem Courant, and the Paris Gazette, along with a promise not to “impose any Additions of feign’d Circumstances to an Action, but give [the] Extracts fairly and Impartially.” The modern newspaper had been born; imitators followed.

This was the world that gave birth to Steele’s short lived Tattler, then to the wildly successful Spectator, a world peopled by those whom Addison calls “the Blanks of Society, […] altogether unfurnish’d with Ideas, till the Business and Conversation of the Day has supplied them[, …] needy Persons [who] do not know what to talk of, till about twelve a Clock in the Morning; for by that Time they are pretty good Judges of the Weather, know which Way the Wind sits, and whether the Dutch Mail be come in.”¹ You’ve met this guy, right? Wants to opine but has no real opinions? Parrots what others are saying, sometimes with superlative praise, sometimes with contrarian spite? Notice Addison’s pointed reference to “the Dutch Mail,” the network of foreign correspondents and handwritten newsletters. Addison asks his readers to consider: “Is it not much better to be let into the Knowledge of ones-self, than to hear what passes in Muscovy or Poland; and to amuse our selves with such Writings as tend to the wearing out of Ignorance, Passion, and Prejudice, than such as naturally conduce to inflame Hatreds, and make Enmities irreconcilable.” Every other daily prints news; The Spectator prints discourse, and only discourse can fix the guy with bad takes, not by supplying better ones, but by supplying tools for the refinement of opinions.

This distinction, between the bare reporting of verifiable facts, and the hermeneutic framework their audience fits them into, is critical. The words “Russia invades Ukraine,” “Donald Trump elected US president,” or “Gavin Newsom thinks it’s unfair for trans women to compete in women’s sports,” mean radically different things to different people. Your interpretation of these sentences relies, yes, on your ability to access relevant facts, but also on your general interpretation of our world and times. What you make of those statements is inextricably linked with your takes on political economy, family and social life, religion, ontology, aesthetic and moral philosophy, history, psychology, anthropology. It is to these broader realms that Addison and company addressed themselves, inventing various characters that allowed them to lampoon the attitudes of the day.

The Spectator ran for a total of 635 issues–from March of 1711 to December of 1712, with a brief revival in 1714–by turns celebrating the Royal Exchange as a locus of cosmopolitanism⁵ and lamenting how the gossip it spins can destroy careers,⁶ condemning religious zealotry,⁷ finding the centre of morality in intention,⁸ and railing against women who delay getting married.⁹ By the time The Spectator ended in 1714, it had established an enduring reputation as a literary classic, and its collected volumes continued to be read throughout the 18th and 19th centuries.

Over the next several decades, The Spectator would inspire dozens of imitators, each with their own spin on the formula. Jonathan Swift and Thomas Sheridan’s Intelligencer (1728-29) focused on Irish affairs; Henry Fielding (of Shamela and Tom Jones fame) cut his teeth launching The Champion (1737-44) and critiquing Prime Minister Robert Walpole; Alexander Pope wrote pseudonymously for the satirical Grub Street Journal (1730-38); and Eliza Haywood’s anonymous Female Spectator (1744-46) addressed a female audience from a female perspective. Perhaps the most interesting of these projects, however, was Edward Cave’s Gentleman’s Magazine, which ran uninterrupted until 1907. Cave–who coined the term “magazine”–sought to produce a monthly digest of all that could be called discourse, and enlisted a wide array of contributors to this end.

This era was, for Habermas, the public sphere at its most potent. By enabling the adult male citizenry to participate in debates about the political direction of the country, it separated private (commercial, societal, intimate) interests from public interests and the pursuit of the greater good. Suddenly you could go sit at a coffeehouse, read The Gentleman’s Magazine, argue over its political prescriptions, and have a space from which to mount a counter-attack. The shared space of the coffeehouse–where you don’t choose who the other patrons are–pushed you to turn your private feelings into a publicly coherent argument. Arguments like “we should not pass this tax, for it would be bad for my business” stopped holding water: prove that the tax is bad for society as a whole or no cigar. But this model was predicated on a careful balance of power between Addison and his readers: yes, they all had to be reading the same Spectator, but their opinions could not be blithely sourced from Addison. They had to come from debate, and this debate had to reach Addison so he could address himself to it. As the reading public expanded, this balance toppled, and “the public sphere in the world of letters was gradually replaced by the pseudo-public or sham-private world of culture consumption”¹⁰. National newspapers, mass media, and the advertising industry came together to create a world where coffeehouse debate saw itself supplanted by the passive consumption of information, so that Habermas could write in 1962 that “The world fashioned by the mass media is a public sphere in appearance only”¹¹. Social media only makes this worse: returning to the topic in 2022, Habermas writes about a “blurring [of] the perception of [the] boundary between the private and public spheres of life,”¹² the creation of a world of “semi-private, semi-public” echo-chamber spheres, inimical to the separation between private and public affairs that he identified as critical to the formation of a democratic polity. When The Gentleman’s Magazine is The Gentleman’s Subreddit, and everyone’s posting from the toilet, are you sure that those you read have set their private interests aside?

The Gentleman’s Magazine, by the way, proved important for another reason: it allowed that colossus of 18th century English letters, Samuel Johnson (1709-1784), to get his start as a periodical writer. In 1750, Johnson launched his own periodical, The Rambler, which ran until 1752. Nobody read it. In his final essay, number 208,¹³ he reflected on having “never been much a favourite of the publick,” and explained his own project, in a deliberate contrast with The Spectator’s: “[I] have never complied with temporary curiosity, nor enabled my readers to discuss the topick of the day; I have rarely exemplified my assertions by living characters; in my papers, no man could look for censures of his enemies, or praises of himself; and they only were expected to peruse them, whose passions left them leisure for abstracted truth, and whom virtue could please by its naked dignity.” (emphasis mine)

By the time Johnson returned to the periodical form with 1758’s Idler, his Dictionary had made him a literary celebrity, and he had developed a full-throated critique of Addison’s model of public discourse. In his programmatic essay, Idler 3,¹⁴ he explained that his project was addressed to “the innumerable multitudes that, having no motive of desire, or determination of will, lie freezing in perpetual inactivity, till some external impulse puts them in motion; who awake in the morning, vacant of thought, with minds gaping for the intellectual food, which some kind essayist has been accustomed to supply.” Contrast this “Blank of Society” with Addison’s: Johnson moves the locus of societal hermeneutics away from conversation, towards individual reflection. The problem of bad takes isn’t that people don’t converse–it’s that people don’t think.

After all, conversation, Johnson tells us, is like punch.¹⁵. It’s made of “spirit, volatile and fiery, [which] is the proper emblem of vivacity and wit; the acidity of the lemon will very aptly figure pungency of raillery, and acrimony of censure; sugar is the natural representative of luscious adulation and gentle complaisance; and water is the proper hieroglyphick of easy prattle, innocent and tasteless.” The success of a bowl of punch lies in the balance: too much spirit overpowers, “every one shrinks from the force of its oppression”; too much lemon “distort[s] the face and torture[s] the palate”; too much sugar will “soon pall and nauseate.” But water? You can just chug that stuff. You can drink as much water as you like. You can make the most anodyne, watery, punch, fill your talk with “inoffensive copiousness, and unenvied insipidity,” and no good-mannered party guest will be so impiously acidic as to call you out.

The danger of conversation as the locus of reflection is that people’s desire for social credit outstrips their desire for genuine reflection. For Johnson, the way to produce authentic reflection is to have a set of writers who produce content for a set of individual readers who read and examine it in private idleness. Addison’s model is centripetal: it relies on topics being brought to specific locations (coffeehouses, dinner parties, clubs) to be conversed upon. Johnson’s model is atomizing: everyone is responsible for curating their own sources and making their own mind up.

Horace Walpole (1717-1797) inherited, like Johnson, the Addisonian model of discourse, found similar faults with it, and reached a radically different solution. In a letter¹⁶ to the antiquarian Henry Zouch, May 14, 1759, Walpole wrote “I am sick of the character of author, I am sick of the consequences of it, I am weary of seeing my own name in the newspapers; I am tired with reading foolish criticisms on me, and as foolish defences of me.” Walpole, unlike Johnson, had a public profile that reached beyond his literary activity. The son of Henry Fielding’s bete noire, the Prime Minister Robert Walpole, he served in Parliament for over two decades, enough to grow exhausted at public discourse. Rejecting periodical-writing and coffeehouse chatter, he chose instead to express himself over the course of a voluminous private correspondence, collected in a Yale edition¹⁷ spanning 48 volumes.

In a letter to his friend, the scandalous divorcee Anne FitzPatrick, Countess of Upper Ossory, Walpole explained¹⁸ his epistolary (anti-)method: “since neither Aristotle nor Bossu have laid down rules for letters, and consequently have left them to their native wildness, I shall persist in saying whatever comes uppermost, and the less I am understood by anybody but the person I write to, so much the better. St Paul is my model for letter-writing, who being a man of fashion and very unaffected, never studies for what he shall say, but in one paragraph takes care of Timothy’s soul, and in the next of his own cloak.” The references to Aristotle and Bossu (an influential neo-classical critic) show that he was consciously thinking of the distinction between published and private statements: for Walpole, the power of letter writing relies on being able to converse without pressure, to tailor his message and style to his interlocutor, to be amongst friends.

And boy, did Horace Walpole converse with friends. The Yale edition collects over 2000 of his letters, and finds him discussing Parliamentary debates¹⁹ with the illustrator Richard Bentley, talking heraldry²⁰ (are lions leopards?) with the archivist Andrew Coltee Ducarel, or reviewing²¹ the newly opened Ranelagh Gardens, along with a few operas, for the diplomat Horace Mann.

Walpole’s correspondence and behaviour give us a sense of the discursive model he was implicitly operating within. In contrast to Addison’s centripetal or Johnson’s atomizing models, Walpole’s is rhizomatic. Discourse bounces through a multitude of (primarily) dyadic connections. Walpole talks to people in London, shares his intelligence with Mann, receives complementary reports from Florence, and spreads them in London. Meanwhile, everyone he talks to is writing letters to other recipients. Because all of these conversations are inherently informal, they organically span not just events themselves, but also the very cultural and philosophical topics that The Spectator wanted to bring to the coffeehouse. These properties may be a result of letter-writing being a private, rather than public, endeavour, but Walpole was also very aware of the porosity between a private and a public letter. In 1748, he began requesting that his friend Horace Mann send his letters back. These he transcribed, erasing any details he didn’t want remembered, in preparation for a posthumous publication. He even affixed an introductory advertisement²² to the manuscript transcriptions. He doesn’t seem to have circulated these letters in life, but his friends weren’t always as scrupulous, and his final letter to Lady Ossory, towards the end of his life, finds him chastising²³ her for showing letters of his to her friends.

Horace Walpole’s world was, after all, that of Les Liaisons Dangereuses, a world of letters forwarded by recipients unbeknownst to their authors, letters discovered in teenagers’ desks following tips from disloyal friends, letters held as evidence for use in blackmail. I cited Walpole’s letter of May 14, 1759 to Henry Zouch earlier: he is, in fact, replying to Zouch’s inquiry about his position on a parliamentary debate, a debate Zouch himself had a financial interest in. Again, porosity. The debate is public, it’s being discussed in public circles that Zouch and Walpole have access to, but the truly impactful discourse isn’t exclusive to those public circles: it bleeds over into private correspondence.

This is where Habermas’ 2022 paper goes wrong. The superposition of public and private spheres, the creation of semi-public, semi-private, spheres is not new. Our discursive conditions are not, fundamentally, new. They are, rather, an ill-understood mishmash of the 18th century models I’ve presented. The 19th and 20th centuries–the eras of media centralization that Habermas 2022 yearns for as much as Habermas 1962 critiqued–were not the norm for democratic societies, they were the anomaly. We’re now back where we started, with the exception that, unlike in the 18th century, we don’t just have one public sphere, one set of papers, Parliamentarians, and coffeehouses, but multiple overlapping public spheres, whose behaviour can only be modeled in reference to their distinct aims, functions, and audiences.

Enumerate the platforms where you talk: I use Discord, Whatsapp, and Bluesky. Okay: individual Whatsapp conversations are clearly Walpolian correspondence, rhizomatic networks that stretch beyond my immediate circle. My friend is in my messages, sharing intelligence from Chilean immigrants to Toronto who in turn are in contact with their families in Chile, hence I can try to come to grips with José Antonio Kast’s electoral victory. Discord servers are Addisonian: I go on my poetry server and talk poetry with poet friends. It’s our coffeehouse. My friend receives her ARC Poetry subscription, photographs a poem, and dumps it in the chat for us to talk about, hence replicating the coffeehouse sharing that allowed Addison to boast that every Spectator sold reached at least twenty readers. What about Bluesky?

You might be tempted to say, “obviously Bluesky is an enormous coffeehouse” but are you sure? For a coffeehouse to be a public space, we must all be gathered under the same auspices, and there must be a sense of a discursive level playing field. A post on a Discord chat reaches all participants at the same time. A shout of “BAD TAKE, BAD OPINION!” is heard equally by all persons inside a coffeehouse. A post on Bluesky reaches my followers first, then potentially their followers. It might make rounds, but replies to quote posts are separate from replies to the original post. Speaking of replies, they’re hidden by default. For such a public app, it’s surprising how easy it is to get into a quasi-private conversation in the replies to a high-visibility post. “So Bluesky’s rhizomatic,” you say, “it’s Walpolian”: ah, but it’s public. In fact, I think Bluesky exists on a gradient from Walpolian–when a post is made in a dense network with few outside followers–to pre-Addisonian: dispatches, lists of events, lists of facts. This is the model for most mass social media apps, including Instagram, Reddit, or Tumblr.

Meanwhile, meta-discourse–discourse about discourse–seems to have caught itself in a Johnsonian epistemic loop. We are asked, over and over again, by both left and right, to dig up our own evidence, to form our own opinions. When we see someone with what we think is The Bad Take, we shout at them to collect different evidence, damn it, form different opinions! In the cacophony of multi-modal instantaneous mass communication, we’ve given up on collective sense-making. Every epistemic conflict is redirected to an atomizing model that tells us “if only you had the right facts you’d see it my way.” This hasn’t worked for decades. There’s no amount of fact checkers, no judicious use of community notes, no incentive alignment that’s going to make this model work. Samuel Johnson was only able to develop his Idler model in the context of an Addisonian society. In a world where everyone is engaging in high-context conversations on an equal footing, sure, it makes sense to encourage moments of solitary reflection, to ask people “do you really believe this, or are you parrotting popular takes?” This makes no sense when we can’t decide on what a “popular take” is. Should trans women compete in women’s sports? Be careful: your answer will be lauded in this room, decried in the next. Is inflation real or is it vibes? Would you be able to tell me, with enough methodological rigour that everyone accepts your answer, what percentage of the adult population believes that inflation is real and what percentage thinks it’s merely vibes? Can you even define “real” inflation versus “it feels like inflation?” You can collect all the evidence you like–your opponents will claim it supports their thesis.

At the root of Habermas’ 2022 critique of public discourse in the age of social media is the sense that Addison’s centripetal model has disintegrated. This is the model, recall, that Habermas identified with an inclusive, egalitarian, rationally-ordered public sphere. If you’ll excuse my pedantry though, Habermas himself wrote, in his 1962 book, of the death of that model. The difference between Addison and Steele’s 1710 Spectator, and the ongoing 1828 magazine The Spectator is that the latter is so centripetal as to not need the coffeehouse as a locus of discourse at all. 19th and 20th century publications are not made for public reading so much as they are made for private Johnsonian consumption. From this perspective, a Discord server is far more Addisonian than any extant newspaper. The chief difference between Discord servers and Addisonian coffeehouses is the degree to which the latter lend themselves to a kind of constructive centralization: every political actor in 18th century London knew which coffeehouses to frequent, whereas Discord servers are a dime a dozen. A Discord server behaves more like a kind of hub in a rhizomatic network than a true discursive centre. You might call it a pseudo-Addisonian space: it collects discourse but has no centralizing function. News is carried out of hubs by individual correspondents, who can either translate them for other individuals in a Walpolian manner, or translate them for a decontextualized Johnsonian subject, yeeting them into the pre-Addisonian world of the Bluesky firehose. The former results in high-fidelity high-latency translation: if I’m in the poetry scene and you’re not, I can talk you through the latest developments because I know where you’re coming from, but I can’t do the same for 200 people. The latter is low-fidelity low-latency: I can explain poetry drama to 200 people, but only if I assume they know literally nothing about literature beyond high-school English.

We cannot reconstruct the original coffeehouse; fragmented special-interest ecosystems equal specialization, and specialization is advantageous. What we need is to empower pseudo-Addisonian spaces to make valuable contributions rather than turn into echo chambers. It’s clear that some pseudo-Addisonian spaces are doing this quite well on their own–the Adam Clery football channel, the Discordia review, and the work of Thalia Bhatt are just some loci of valuable, intelligent discourse. To drown out the noise, we need these high-quality loci to be amplified, for which we need high-fidelity low-latency translation that allows any reader to hop from their end of the rhizome to any faraway corner and understand what’s happening as well as they would at home.

That’s why I built a new type of newspaper! How’s that for a smooth call to action? The New Intelligencer reads your whole Bluesky feed for the last 24h (over 10000 posts for me this morning!) and uses Claude Code to produce an HTML newspaper that consolidates similar posts (without hiding the originals), and fits them into categories you define.

Here’s an example workflow: I want to understand ATProto. I could spend an hour a day on Bluesky, gradually building a follow list, monitoring for interesting developments, probably still missing half of what goes on. But I’m debonaire, cultured, urbane, I have a million things on my plate. So instead I set the robot to deep research mode (via Claude’s web ui) and asked “who do I follow on bsky to learn ATProto?”

The robot gives me a dozen key accounts plus five starter packs:

Then I turn to the New Intelligencer and added a few categories to my newspaper.json:

Now I get high-signal reports of goings on in the ecosystem:

Claude is functioning as a Walpolian correspondent embedded in pseudo- and pre-Addisonian spaces. Now I can build a follow list for niche interests and come, over the course of a couple of days of reading my Morning Papers, to understand the state of their discourse. The hope is that this will help me form concrete opinions on increasingly remote topics–not just understand what’s happening, but what sets of values are driving events. Look at the screenshot above: “opinion: SociaIFi platforms pivot as ATProto gains momentum,” is a headline that’s, yes, based on events, but that also encodes an interpretation of those events and their causes and likely effects. By expanding the tile I can read the interpretation and gain a sense for how the ATProto community thinks about finance.

As you might guess, there are limits to this model. For one thing, Horace Walpole was a real guy with a calendar. When he wasn’t writing letters to his friends, he was out and about doing things, and his activities informed what he wrote about. Claude comes in from the cold every single time, denuded of the broader context for what’s happening in my feed. This leads to interesting artifacts: when federal agents killed Alex Pretti, Claude generated a headline like “Federal agents kill American nurse, resulting in nationwide protests” for several days in a row. Surely a human correspondent would’ve seen fit to add some new information each time.

And there are, naturally, other problems, beyond curation and context collapse, with our public spheres, problems that have always lurked but have only been accentuated by the rise of online mass media. My correspondent could, for instance, be fooled by a fake story. My feed could be biased. Perhaps the greatest danger of all remains the social credit problem identified by Johnson. How do I know that the things I read, indeed, the things I write are sincere? It takes a lot of sobriety to withstand the cocktail of perverse incentives and clout-lust. There is no single fix for the problem of bad takes. This piece attempts to address it from the perspective of discursive modeling, but I could’ve also talked about data provenance and incentive re-alignment as components of the fix. Ideally, we can patch together enough of a solution that theorists in 300 years get to sit around in coffeehouses and debate what exactly the silver bullet was.

Bibliography

Addison, Joseph, and Steele, Richard. The Spectator. London, 1711–1714.

Habermas, Jürgen. The Structural Transformation of the Public Sphere. Translated by Thomas Burger and Frederick Lawrence. Cambridge: MIT Press, (1962) 1991.

Habermas, Jürgen. “Reflections and Hypotheses on a Further Structural Transformation of the Political Public Sphere.” Theory, Culture & Society 39, no. 4 (2022): 145–171.

Johnson, Samuel. The Idler. London, 1758–1760.

Johnson, Samuel. The Rambler. London, 1750–1752.

Lewis, W.S., ed. The Yale Edition of Horace Walpole’s Correspondence. 48 vols. New Haven: Yale University Press, 1937–1983.

Notes

Joseph Addison, The Spectator, No. 10 (March 12, 1711). ↩ ↩²
Jürgen Habermas, The Structural Transformation of the Public Sphere, trans. Thomas Burger & Frederick Lawrence, (Cambridge: MIT Press, (1962) 1991), p. 27. ↩
Henry L. Snyder, “Newsletters and Newspapers: The Circulation of News in Britain in the 17th and 18th Centuries,” paper presented at the 63rd IFLA General Conference, Copenhagen, August 31–September 5, 1997. ↩
Elizabeth Mallet, The Daily Courant, No. 1 (March 11, 1702). ↩
Joseph Addison, The Spectator, No. 69 (May 19, 1711). ↩
Joseph Addison, The Spectator, No. 218 (November 9, 1711). ↩
Joseph Addison, The Spectator, No. 185 (October 2, 1711). ↩
Joseph Addison, The Spectator, No. 213 (November 3, 1711). ↩
Joseph Addison, The Spectator, No. 89 (June 12, 1711). ↩
Habermas, (1962) 1991, p. 160. ↩
Habermas, (1962) 1991, p. 171. ↩
Jürgen Habermas, “Reflections and Hypotheses on a Further Structural Transformation of the Political Public Sphere,” Theory, Culture & Society, Volume 39, Issue 4, (2022), pp. 145–171. ↩
Samuel Johnson, The Rambler, No. 208 (March 14, 1752). ↩
Samuel Johnson, The Idler, No. 3 (April 29, 1758). ↩
Samuel Johnson, The Idler, No. 34 (December 9, 1758). ↩
Horace Walpole to Henry Zouch, May 14, 1759, in W.S. Lewis, ed., The Yale Edition of Horace Walpole’s Correspondence, (New Haven: Yale University Press, 1937–1983), vol. 16. ↩
W.S. Lewis, ed., The Yale Edition of Horace Walpole’s Correspondence, 48 vols. (New Haven: Yale University Press, 1937–1983). ↩
Horace Walpole to Anne FitzPatrick, Countess of Upper Ossory, October 8, 1777 in Lewis, Walpole’s Correspondence, vol. 32. ↩
Horace Walpole to Richard Bentley, December 17, 1755, in Lewis, Walpole’s Correspondence, vol. 35. ↩
Horace Walpole to Andrew Coltee Ducarel, February 24, 1762, in Lewis, Walpole’s Correspondence, vol. 40. ↩
Horace Walpole to Horace Mann, May 26, 1742, in Lewis, Walpole’s Correspondence, vol. 17. ↩
Horace Walpole, “Advertisement” to the Mann correspondence, in Lewis, Walpole’s Correspondence, vol. 17. ↩
Horace Walpole to Anne FitzPatrick, Countess of Upper Ossory, January 15, 1797, in Lewis, Walpole’s Correspondence, vol. 34. ↩

Similarity at scale

2026-02-19T00:00:00+00:00

Recent Dripline posts have covered what can be built on top of cryptographic hash functions: important concepts like data integrity and content provenance. Having the ability to uniquely refer to and verify an exact piece of data is crucial to building reliable digital content systems. But this can only take us so far. How can we keep track of an image when it’s been converted to a different file format? Or compressed? How can we match a song played in a noisy room to its original studio recording? Perceptual hashing answers these questions, and allows provenance information to travel far beyond the exact bits it was originally attached to.

Perceptual hash functions are designed differently than cryptographic hash functions, with algorithms that extract features from content and reduce them, outputting similar hashes for similar inputs. This means the compressed version of an image will have a hash that’s nearly the same as the original uncompressed image. These hashes can then be stored and compared to find matching images. This concept allows for powerful tools, from Shazam to Google’s reverse image search. At Hypha we want to take these tools further, to keep track of provenance even when media is altered.

Comparing basic, cryptographic, and perceptual hash functions

Let’s quickly revisit some of the basics. A hash function takes input data of any size (like someone’s name) and returns a fixed size output (like a number from 0-100). Reducing the size and type of the data can make referring to it easier. You can learn more about hash functions in this excellent interactive article by Sam Rose.

A cryptographic hash function adds certain constraints, for example that the function can’t be reversed easily and that collisions are difficult to find. This is what makes them so useful – all these properties mean the 32 bytes of output of a cryptographic hash function like SHA-256 can uniquely represent the input data, even if that data is terabytes in size.

One key property of cryptographic hash functions is that their output is randomly distributed, with no identifiable patterns or mapping. This results in the “avalanche effect.” Even a very small change in the input will cause a large change in the output. Similar inputs do not result in similar outputs. This is a desirable property for most scenarios, because it prevents attackers from being able to learn anything about the input data.

Wikipedia article or Commons page
David Göthberg (public domain)

Perceptual hashing has the opposite goal: similar inputs should result in similar hash outputs. This property is the entire utility of perceptual hash functions. A good perceptual hash function will return similar outputs for an original image, as well as the compressed version of that image, for example – because both these input images look very similar.

Similar images have very similar hashes (PDQ hash algorithm)
pdqhash (Apache 2.0)

While cryptographic hash functions operate on raw bytes, perceptual hash functions are specific to a type of media. There are different perceptual hash functions for images, video, audio, and other mediums. This is because a perceptual hash “is a fingerprint of a multimedia file derived from various features from its content” (phash.org), and the kinds of features available in an image vs video are different. If you’ve heard the term “audio fingerprint” before, that’s referring to an audio perceptual hash algorithm.

All these hash functions exist on a spectrum from shallow analysis to deep analysis. Cryptographic hash functions only compare exact bits, perceptual hash functions roughly compare media content (pixels, musical notes, etc.), and at the most intensive end of the scale, machine learning algorithms compare concepts like “a forest”. This article focuses on perceptual hashes because they nicely balance utility and efficiency: they can match content without being too computationally expensive to create or calculate.

Facebook, hashing.pdf page 5 (BSD)

How perceptual hash functions work

The final output of a perceptual hash function will be binary data of some length, such as 32 bytes or 256 KiB. The challenge of designing the algorithm is extracting the important parts from the media file and reducing those “features” down to just the small output size. For example Chromaprint–a perceptual hash algorithm aimed at music identification–extracts which 12 notes are being played in a provided song over time, filters that data to reduce it further, and then stores it as a set of integers that can be easily compared to find similar songs.

For image hashing, there are a variety of methods, but they all boil down to repeated reductions of the image data. First resize the image to some very small size, then convert to grayscale. Process the grayscale pixels in some relevant way, such as averaging the colours available, or applying the discrete cosine transform. Binarize the output from that process, and then take those bits as your hash output.

Visualization of the PDQ image perceptual hashing algorithm
pdqhash (Apache 2.0)

As you can see, each perceptual hash function is quite different, especially across different input mediums. Understanding or creating the algorithm will often require some specialized knowledge in the domain (such as digital audio), as well as knowledge of signal processing and even machine learning.

Use cases for a perceptual hash function

Perceptual hashing is useful for any scenario that involves automatically finding similar media, especially at scale. An example is the Shazam app, which works by comparing a perceptual hash generated by your phone recording against their massive database of perceptual hashes for songs. Using a perceptual hash means songs can be found even in noisy environments–the underlying musical features can still be detected and matched.

This database lookup pattern is repeated in other domains, such as images. Social media companies often use perceptual hashing to check user-uploaded images against a database of banned content. That way reposts can be instantly detected and removed. Using a perceptual hash means that even if the user uploads a slightly altered image, it will still be flagged. Due to the massive volume of harmful content uploaded online, having an automated and accurate way to flag images or videos is very valuable. Facebook talks about this further in their 2019 article announcing their open source image perceptual hash, PDQ.

At Hypha, we’re interested in the content provenance use cases of perceptual hashing. For example, with our partner Starling Lab we store important image metadata in our database, all tied to the cryptographic hash of the original image. We’d like to use perceptual hashes so that metadata can still be matched to images that have been published or altered in different places, like on social media or news websites. It’s also helpful when our original image can’t be shared publicly, as it might include private metadata like a geotag.

Even at a small scale, integrating perceptual hashes into content provenance workflows is useful. We believe it’s more important than ever to publish and retrieve these hashes, as part of a digital trust system. These kinds of systems can help combat the rise of AI-generated media and the decline of faith in traditional institutions.

Any usage of perceptual hashes must take into account their fallibility. Unlike cryptographic hashes, they cannot be relied on as a guarantee. Sometimes dissimilar images will have similar hashes; sometimes similar images will have dissimilar hashes. A good algorithm will reduce these scenarios, but can never eliminate them. A well-designed system (such as one for moderation) will use perceptual hashes as a guide rather than an absolute indicator.

Hypha has been experimenting with open source perceptual hash algorithms, so stay tuned for our next blog post on this topic!

We built you a garden 🌼

2026-02-18T00:00:00+00:00

In fact, we built digital gardens for everyone on ATProto! Yours already exists—it’s just waiting for you to plant something. Check out your corner of the internet here.

Digital gardening is about curating and contextualizing ideas on your own personal site. There are already ATProto apps for posting short-form thoughts, for writing longer pieces, for posting photos and videos, for streaming and for sharing events; in your garden, you can post new content and also repost the best of what you’ve published elsewhere.

The vision of spores.garden is a lightly social network of personal websites which let people express themselves as individuals. Thoughts in these gardens are planted, curated, and admired by a network of fellow humans, not by an algorithm.

The more we dug into this project, the more respect we gained for ATProto; it gave us a lot more to think about than a traditional web project. It was easy enough to build a site generator, but we got to take advantage of some of ATProto’s unique properties to add some really fun features to spores.garden: a unique visual identity for each garden, the ability to pull in data from other apps, and semi-social experiences like linking to other gardens or following a trail of breadcrumbs to see what other users are looking at.

Discover your unique garden

We didn’t want to build Wordpress-on-ATproto. Every instance of spores.garden will have a unique colour palette, flower identicon, and isoline background generated specifically for you.

You can change your handle on Bluesky, you can’t change your flower or theme on spores.garden.

If you signed up using Bluesky’s default settings, your internet handle ends in .bsky.social, but you might see other people whose handles are something else (like me—I’m lexa.fyi and I’m a member of hypha.coop)! Those handles are names the user chooses, but your real identity on ATProto is hiding underneath that human-readable handle, as a “decentralized identifier” or “DID” which was generated when you first joined the protocol.

To generate your theme, we send that underlying DID through a hashing algorithm that deterministically generates your colour palette, flower, and isoline background. No two themes will be the same, and a given DID will always generate the same theme.

Every instance of spores.garden has a unique colour palette, flower identicon, and isoline background generated from your DID.

Plant your seeds by hand

Aside from generating the visual identity for a site, gardens are distinctly not algorithmic. Digital gardening is supposed to be manual, because selecting and curating meaningful content is a way of reclaiming your humanity on the web.

Everything you see in this network of personal sites was planted there by a human, with intention.

You can write new stuff on a garden, but you can also repost the best things you’ve posted elsewhere in the Atmosphere, like on Bluesky or Leaflet. Instead of each application having a database with all of its app-specific data, each ATProto user has a personal data repository hosted on a personal data server (PDS). That repository is a collection of all the data they own in the Atmosphere. Your personal repository is, obviously, personal. You and the applications you authorize are the only ones who can add or edit data records to the repository on your PDS, but anyone can view the contents.

That property makes it very easy to set up a new application because there is so much underlying data from each user already available—there’s no “cold start” issue where users are unmotivated to join because they’ll need to build up a presence from scratch again. As soon as you claim your garden, you’re immediately able to pull in your own data and explore other gardens via the most recently updated gardens on the homepage.

Follow the flowers

The homepage is, however, the most boring way to find new gardens. Instead of an endless scroll of hyperlinks, we chose to use people’s unique flowers across the entire application as signposts leading you back to a garden.

When you visit someone’s garden, you can collect their flower and have it show up on your site as a way of affiliating yourself with that person. Early blogs sometimes used a similar webring concept to let viewers easily navigate throughout a network of similar websites.

You can also plant your own flower in someone else’s garden as a sign that you have been there. These planted flowers act like a digital guestbook, with new visitors able to see who has been there before and follow the links back to those other gardens.

These properties are both enabled by a service called Constellation, provided by a fellow Toronto-based ATProto nerd, Phil. Constellation takes advantage of ATProto records being publicly accessible and creates user-specific “backlinks” from the available information.

Imagine that Aspen follows Birch on Twitter/X. A ‘follow’ can be represented as a directional relationship between the Aspen entity and the Birch entity. Displaying a list of Birch’s followers is as simple as querying for all directional connections between Birch and any other entity. They’re probably stored in a single table in a single database.

Now imagine that Aspen follows Birch on Bluesky, where data is stored in one database for each person. There is no table to query for a list of Birch’s followers because that information is scattered across all his followers’ PDSs.

Instead, a ‘follow’ creates a record in Aspen’s PDS saying “Aspen follows Birch”. Birch’s follower list can be shown to him via Constellation (or a similar indexer) scanning the ‘firehose’ (a stream of all data being created, edited, or deleted in ATProto) and keeping track of every follow record that mentions Birch. Those records are not saved in Birch’s PDS, but they’re formatted and presented as relevant information to him.

Having backlinks available solves what would otherwise be a really challenging problem—how do we accommodate social behaviour when everyone’s data is completely siloed? Publicly accessible repositories indexed by a service like Constellation makes ATProto into something inherently social even when used for something ostensibly individual, like a personal website.

Anytime you see a flower, it’s leading you back to someone’s garden via Constellation backlinks.

Search for spores hiding in plain sight

Collecting and planting flowers lead to a very social and intentional way of navigating a network of gardens. By collecting a flower, you’re showcasing a link to someone else’s work; by planting your own flower, you’re saying “hey—come check out my stuff too!”

There is one additional way to explore in spores.garden, which is by finding, following, and stealing a special spore. Using the same deterministic algorithm that generates a theme from a user’s DID, we also encoded the chance to receive a data record called a special spore. Like the unique flower, a given DID will always either generate or not generate a special spore—you can’t manually create or delete one for yourself any more than you could modify the way your flower looks. Whether or not you generate a special spore is an inherent property of your DID when put through our hashing algorithm.

If Aspen generates a spore, her PDS contains the original special spore record and the spore is initially displayed in her garden. That spore is always “Aspen’s spore” because it was generated by her DID. Roughly 1 out of every 10 DIDs will generate a spore.

When Birch visits Aspen’s garden, he can steal it and add a record to his PDS that says “I stole Aspen’s spore on February 10 at 10 AM”. Later, if Cedar sees the spore on Birch’s garden, they can steal it and add a record to their own PDS that says “I stole Aspen’s spore on February 11 at 10 AM”.

Anyone who looks at the spore in Cedar’s garden can see where the spore has been because Cedar’s record contains a reference to Aspen’s DID, which then uses backlinks to produce a timestamp-ordered list of all other users who have interacted with Aspen’s spore.

The game of stealing the spore is a fun, semi-entropic way to discover new gardens: holding a spore doesn’t imply that you’re affiliated with the original owner, nor anyone else who has previously held the spore. But honestly, we built it because it’s cool.

It’s both a social game that imitates a piece of data travelling through a network, and a record whose existence you can’t spoof even though ATProto doesn’t have a centralized authority or a decentralized network of peers validating what’s happening in the network. The more competitive readers may be already theorizing that it’s possible to write a script to constantly steal all of the spores in existence and you’re not wrong; it’s not a bullet-proof system. But…it’s kind of like emptying out a Little Free Library in your neighbourhood without ever intending to read the books. Spores are meant to travel!

Let the garden grow!

In a world increasingly run by algorithms and monolithic media companies, we wanted to recreate the feeling of the web being made up of small, personal, interconnected things rather than massive platforms. Spores is our way of bringing that into that world.

We chose to build it on ATProto because its features made it a great choice for the experience we wanted to create—playful, curated, human. From being able to use someone’s DID as the basis for a fun visual identity to the creative social affordances of backlinks enabled by Constellation; it’s a rich ecosystem with a lot of potential that we’re excited to keep exploring. We’ve even added some documentation for fellow experienced gardeners to add support for their own ATproto projects.

We can’t wait to see what you grow! Claim your flower here.

The Other AI

2026-02-04T00:00:00+00:00

Photo by Marko Stojanovic via Stocksy

Over the holiday break, I headed to Vancouver Island where I was born and raised to spend the holidays with my extended family. And while I didn’t bring my laptop, I did take a copy of Empire of AI so that I could finish it while eating Christmas cookies and relaxing. Despite not being your usual vacation read, it’s a great book and recommended for anyone curious about the current arc of AI and how decisions, especially technical decisions, by OpenAI have shaped our current trajectory. (It’s also got some good gossipy bits about the OpenAI leadership, if you enjoy that sort of thing.)

While the book delves into frontier models, at Hypha we’ve been exploring the world of open source AI and thinking through the state of cooperative AI (as in, AI that’s developed by or for cooperatives). While I appreciate there is a significant amount of ideological handwringing in the cooperative sector over the replacement and deskilling of workers, this all the more reason for people with varied motivations to build and offer products that focus on more than just profit. It seems unlikely that AI is going to disappear from our workplaces, or disentangle from the code running the platforms and tools we use in our personal lives. So short of a fulsome rejection of digital technologies, which may be an option for some people but not all, I’m advocating for thoughtful approaches to AI in worker-owned organizations. Weaving responsibly-built AI into cooperative workflows need not replace workers, and there is potential for time savings for administrative and operational tasks. While I’m generally wary of ‘efficiencies and effectiveness’ rhetoric, within the cooperative context in which members can exercise control over the outcomes of doing work faster, the possibilities are more interesting. Cooperatives could decide to move to a four-day work week, for example. Or refocus their work, emphasizing solidarity or care. Each use case would be context specific, and would require thoughtful experimentation. The point is to be creative about how we use technology, not doctrinaire.

Late last year, my fellow Hypha member Vincent and I travelled to the Platform Cooperative Consortium’s annual conference, with a mission to find more examples of cooperative AI projects. Held in Istanbul under the simple title of Cooperative AI, the conference was a great gathering–big enough that there was a breadth of opinions and presentations, but small enough that you could meet most attendees and connect with them in a meaningful way (i.e. not just the usual inane small talk). Co-organizer Trebor Scholz posted a good recap of the event here, and Miles Hadfield wrote a very comprehensive article here. My biggest takeaway from the conference was the need to see more cooperative AI use-cases out in the wild. While I was impressed by the diverse perspectives of the participants, I came away wanting more experiments, more in-the-code examples of what cooperative AI might look like, not as an academic discussion but as many attempts – large, small, successful and not – and visions of what artificial intelligence could be. Imagine housing co-ops deploying automated tools for predictive maintenance and repair, or platform-based personal support worker co-ops integrating scheduling optimization that respects worker preferences and accounts for client needs.

“resisting Big Tech’s extractive dominance means connecting the already-emerging pieces of a Solidarity Stack—cooperative data centers, AI cooperatives, federated infrastructures, tech cooperatives, and small LLMs—so that these efforts remain locally anchored while building on shared, federated digital infrastructure linking communities globally.” –Trebor Scholz

Fellow conference attendee Melissa Torres, a member of READ Coop, which stewards the AI transcription Transkribus project, noted that she wasn’t aware of any other co-operatively governed AI initiatives. Torres assumes that start-up funding is a major reason for this (Transkribus was bootstrapped with a large grant from the European Commission), but also because Transkribus’ domain, handwriting recognition for cultural heritage, hits a sweet spot of being both widely useful and focused, with a ready community of librarians, archivists, volunteers willing to contribute their labour over many years. I know of other cooperatives that have an AI- focus, but Transkribus is unique in that it has developed its own LLM; in other words, it’s operating at multiple points at the technical stack. Riffing on Scholz’s idea of the solidarity stack, what is the potential for other interventions to counter current AI trends?

Image created using Nano Banana with a prompt from me.

While there are possibilities inherent throughout the stack, I’m going to focus here on the application, data and infrastructure layers as points of cooperative intervention; partially because I’m the most familiar with these layers technically but also because I can see the cooperative potentially most clearly. Stats on global tech cooperatives are hard to find, but we know they are out there (Hypha being a case in point). If just a fraction of these organizations began to explore the potential of local or on-premise AI, and iterated to offer services and products based on open weight or even open source models, that would be an excellent start. Our RooLLM project is Hypha’s overture in this direction, fueled by questions about data privacy and security, and the use of Big AI chat clients like ChatGPT and Claude. For our friends in the global south, advances in on-device AI should be particularly interesting (and perhaps particularly concerning, given the state of the Apple versus Google mobile phone duopoly).

Apart from tech cooperatives developing applications for automation and similar uses, I can also see how the sector as a whole could benefit. A lack of awareness and educational materials–especially in the context of business schools–is a well-known problem amongst cooperative developers and sector leaders. Developing AI applications to demystify how one starts a cooperative and to answer commonly asked questions would be one starting point. Last year, we prototyped a bylaw generator; essentially just a prompting tool for co-op founders. (Drop us a note if you’re curious about how it works and want to test it out!)

Moving from the application to the data layer, and a number of potential interventions come to mind. Data cooperatives, which are member-owned organizations that pool personal data to control its use and share in any benefits, have gotten a fair amount of airtime in recent years (e.g. this Project Liberty report, which Hypha members contributed to!) but the real-world examples are sparse. This is a huge topic, but briefly, the main challenges to actualizing a data cooperative is lack of initial capital, regulatory compliance issues regarding PII or people-related data in general, and a host of technical interoperability and governance challenges. It’s also a question of incentives; when all you need to do is click a button to trade data surveillance for the ‘free’ use of email, social networking tools etc., why complicate things?

But we (might) be entering an era where private enterprise data becomes increasingly valuable; Epoch AI suggests that we’re only a few years away from LLMs consuming all available public data. If this is indeed the case, then cooperatives, especially large producer or agricultural cooperatives, might want to consider commoditizing their data and selling it to AI companies (in fact, some are already entering into AI-related partnerships). And by using a data cooperative framework to do this, they could generate income for their membership as well. In this future scenario, cooperatives’ values of democratic oversight, accountability, and collective governance map well to managing members’ data and ideally, distributing the financial upside considerably more evenly.

We estimate the stock of human-generated public text at around 300 trillion tokens. If trends continue, language models will fully utilize this stock between 2026 and 2032, or even earlier if intensely overtrained. –Epoch AI

Lastly, on the subject of data: how might workers who perform reinforcement learning from human feedback (RLHF) used to train LLMs agitate for a cooperative approach to their work? Many of these people labour under horrendous conditions and while unionization is clearly a much-needed step, a cooperative model might also return some equity to these important and largely overlooked workers.

Turning now to the layer of infrastructure and compute. AI, like all digital technologies, consumes resources to make the digital ‘magic’ happen. While there is a significant amount of disagreement about AI energy and water consumption– a situation owing largely to the unwillingness of Big Tech to release meaningful data about said consumption–what is known and (is fairly uncontroversial) is that data centres are built in rural areas or in the global south, with benefits flowing to multinational corporations rather than local populations (see also Chapter 9 in Empire of AI). Monopolies and geographic inequity are the hallmarks of current global AI infrastructure, and here cooperatives offer two potential remedies. Firstly, forming cooperatively-run data centres would ensure that more of the economic value stays within the community, with profits flowing back to residents rather than out of the country to foreign owners. Secondly, there is an interesting case to be made for deciding how compute capacity would be allocated e.g. prioritizing local businesses and education initiatives, and then offering the surplus to other customers. This could help foster an ecosystem of local start-ups or support existing businesses that could use these services. Funding an initiative such as Servers.coop, which is focused primarily on software, and wrapping in a responsible AI thread might be a place to start. (On the subject of data centres, I have to give a shout out to this amazing Datascapes project!)

Data centres built with community in mind, where developers go beyond token engagement, seems like a far-fetched idea in our current economic paradigm. But rural electricity cooperatives in the US show us that infrastructure and cooperatives can be intertwined. In case you’re not familiar with these, the tl;dr is that in the 1930s, for-profit electrical companies were not incentivized to provide electrical infrastructure to rural areas (lots of infra for little return). To fill this gap, the federal government under FDR created the Rural Electrification Act of 1936, which helped communities build their own electric grids. As of 2023, there were “831 electric distribution cooperatives serv[ing] 42 million people across the United States.” While there are numerous issues with the electric co-ops, not the least of which being their heavy reliance on coal powered plants, they do offer an interesting template to work from when considering how cooperatives might meaningfully enter the AI infrastructure space. In fact, some of these existing cooperatives could be a starting point; moving from electricity to providing other utilities isn’t too abstract as proved by the New Hampshire Electric Coop, which currently offers broadband service to its members. Bundling digital services and community benefits alongside the development of a data centre–such as mandating local fibre deployment or technical training programs–would also meet a cooperative’s goals of enriching their local communities.

Cooperatively-run infrastructure ties to two related points: digital sovereignty (which we’ve been thinking about a lot at Hypha and will go into in future posts), and the idea of Public AI. There are a couple of complementary but differing conceptions of public AI to consider; the Public AI Network and the Mozilla Foundation’s Public AI are two of the best known. Both offer a vision of AI conceived as a public good, with broad accountability, and public access. ‘Public’ here means some form of government funding, but rather than adding another arms length agency (similar to the IndiaAI model) why not provide funding to member-owned, community-based AI infrastructure? It’s an idea worth exploring given the high stakes, both environmental and societal. I’d love to see the cooperative sector engage with the idea of Public AI and consider how the inherent democracy of co-ops can flavour public goods and enhance accountability–especially where data is concerned.

It’s 2026 and we are living in strange and uncertain times. The current technological paradigm is not working for many people, and while it’s unclear if cooperatively developed, responsible AI can positively bend the arc, we owe it to ourselves to try.

Who took this photo?

2026-02-03T00:00:00+00:00

“Content provenance” is an emerging set of techniques that Hypha has been working with, often in the context of mis/disinformation. Instead of asking “Is this content fake?” content provenance systems ask a narrow, more technically precise question: “Where did this come from, and what happened to it?” By cryptographically binding media to devices, creators, and workflows, provenance turns content into an auditable object.

Origins of provenance

In the period after World War II, there was an explosion of published writing, particularly in science and engineering. People were worried that there would be so much information that we would be too overwhelmed to make sense of it. (Perhaps similar to our fears surrounding the deluge of AI driven content)

In 1953, Hans Peter Luhn, a printer and textile expert, hired at IBM as an “inventor”, proposed a technique that we now understand as one of the first practical hash functions. He was trying to solve the specific problem of quickly looking up a phone number in a large phone book. Instead of searching through the list of phone numbers sequentially, item by item, number by number, he wondered if there was a calculation you could perform to know where the item would be instantly.

Luhn suggested putting the phone numbers into “buckets.” Given a phone number, the computer would perform a quick calculation to determine which bucket it belonged in, then search only that bucket. This was a very early hash function: a mathematical process that transforms data (in Luhn’s case, a phone number) into a unique fingerprint (the bucket).

Run the same data through a hash function, you always get the same result. Change even one bit, and you get a completely different result. Today’s content provenance systems use this same property of hashing to uniquely identify content and detect tampering. If a file’s hash changes, the file must have been changed. We can ensure the integrity of the file.

Hash functions can help prove that a file’s contents haven’t changed, but how do we prove who created the file in the first place? This is the problem of authentication, and it’s solved using digital signatures, an application of public key cryptography.

Public key cryptography is a set up with two keys. A creator uses a “private key” (think of it as a secret stamp) to sign a file. Anyone can then use a “public key” to verify that the stamp is authentic. The principle is straightforward: create something that’s computationally expensive to forge but cheap to verify.

We’ve always relied on forgery cost as the barrier to authentication. The Ottoman Sultans used the Tughra, an intricate calligraphic monogram, to authenticate imperial decrees. It worked because forging it required specialized craftsmanship, years of training, and access to specific materials. The cost of creating a convincing fake was cost prohibitive. Today, we use digital signatures to do the same thing, just with cryptography instead of calligraphy. You could use a powerful computer to forge a digital signature, but that computer would need to be tremendously more powerful than any computer humans have ever built.

The Tughra: from calligraphy to cryptography

So: hashes prove content integrity. Digital signatures prove authorship. Content provenance combines these to prove chain of custody, authenticating every entity that touched the content and ensuring its integrity across the chain.

Provenance in practice

Hypha members at Starling Lab, worked with Reuters and the camera manufacturing company, Canon, to demonstrate the provenance workflow in the field. This end-to-end system was field-tested by Reuters photojournalist Violeta Santos Moura in Ukraine during March and April of 2023.

Reuters and Canon field-tested the C2PA provenance workflow in Ukraine

The most prominent framework trying to standardize the provenance process is called C2PA (the Coalition for Content Provenance and Authenticity). As of 2026, we’re seeing real adoption, with cameras (Sony, Canon, Leica), software (Photoshop, Premiere), platforms (Google, Meta, Microsoft, OpenAI), and news organizations (BBC, Bloomberg), engaging with the standard.

That matters, because provenance only works if it survives across tools, workflows, and platforms. Without shared standards, provenance data would be stripped, ignored, or inconsistently applied. With them, it has a chance to become infrastructure rather than a niche feature.

A key feature of C2PA is that it allows for provenance information to travel with the content itself in the form of signed metadata. It doesn’t require another database to store information about the provenance, rather the content comes bundled with the provenance information. This is particularly valuable when publishers do not have a priori knowledge of how or where their content will be viewed.

Limitations

Content provenance raises the cost of certain deceptions. It makes it harder to claim videos are AI-generated when they’re not. It creates audit trails journalists can follow. However, it does not mean that the content is accurate or truthful. We think of it purely as infrastructure.

And the infrastructure itself could have vulnerabilities. Who decides which public keys are trustworthy? We rely on Certificate Authorities (like DigiCert or Let’s Encrypt) that vouch for identity. If compromised or coerced, the entire chain collapses. In 2011, hackers breached DigiNotar and obtained fraudulent certificates to impersonate Google, enabling surveillance of Iranian citizens.

Then there’s the privacy paradox. If you’re a journalist in Belarus documenting protests and your phone signs every photo, that signature becomes evidence against you. There are techniques (like Zero Knowledge proofs) for proving “this photo is authentic” without disclosing “I took this at these coordinates”, but implementing this is complex and many tools don’t support it yet.

Our greatest concern around provenance is that we could move from a world of “fake content” to a world of “signed (mis)information”. The technical authenticity of media can be a shield for dishonest narratives.

Here are some scenarios to consider:

A politician gives a speech. It’s recorded with a signed camera, full C2PA credentials. In context, they’re presenting an opponent’s argument before refuting it. But a verified account shares a 15-second clip (cryptographically authentic, completely signed) that only includes the inflammatory quote. The provenance is perfect. The story is a lie.

Or: a protest organizer gets photographed by a professional camera with full Content Credentials. That genuine image then gets shared with a caption claiming the person is a paid agitator. The photo is real. The accusation is false.

Perhaps the most insidious form of misinformation is reality stripped of context or paired with false narratives. Technology can solve the problem of revealing provenance. It doesn’t solve the interpretation problem, the context problem, or the intent problem.

This is not to say that provenance technology is useless. It is, like any other technology, limited in scope.

Who is provenance for?

At Hypha, we believe that our informational landscape is going through a period of massive change, leading to an epistemic crisis. There are a host of intersecting factors here: the relationship between reader and publisher being severed, increasingly mediated by big tech platforms (first social media and now big AI); user generated content providing faster information and surfacing underreported views from the margins; outmoded media business models, kept alive by private benefactors or through state intervention; and now generative AI exacerbating the liar’s dividend, where the mere existence of deepfakes allows dishonest actors to dismiss genuine, damaging evidence as “AI-generated.”

This problem space is complex and requires social and political interventions, but also needs a rearchitecture in our technical systems. At Hypha, we’re researching using open web protocols to rebuild connection with users, thoughtful and values-oriented ways of using AI for knowledge management and synthesis, and content provenance, the topic we’re covering here. We’ll be writing more on the former in future posts in our digital trust series.

Here’s how different actors should think about content provenance today:

Publishers

Your content isn’t being surfaced just on your channel anymore. It’s being pulled up by LLMs, summarized by AI systems, shared and remixed across platforms. Laying down provenance infrastructure now means you can trace where your content goes. This could enable attribution and potentially monetization as the business models around AI-era content licensing develop.
Your authentic content is being misused right now. Photos taken out of context, videos clipped to misrepresent events, genuine footage dismissed as AI-generated. Provenance gives you technical proof: capture device, timestamp, chain of custody. This can be useful evidence in court and for takedown requests when others misuse your content.
Content provenance technology is still nascent. Currently most content on the web is unsigned. Early adopters can start “showing their work” to rebuild trust with their audiences and differentiate through their accountability.

Platforms

Provenance gives you another signal for trust and safety work. Coordinated inauthentic behavior often involves rapid content creation and distribution. Signed content with verifiable chains of custody is harder to generate at scale.
Provenance creates a rich space for product innovation: new ways of monetization and novel social interactions. Look at current trends around remixing (TikTok duets, quote tweets, response videos, meme templates): provenance allows you to trace the evolution of content.

Web users

Use provenance to verify information. Content provenance shifts epistemic authority from “what looks real” to “who controls the keys.” It changes the terms of the debate, because those who control the keys are the ones that should be held to account. When you see content and you’re asking yourself “is this real,” you know who to ask for evidence.

Digital Trust Glossary

2026-02-02T00:00:00+00:00

Here at Hypha, we talk about cryptography and digital trust a lot. We keep running into all these different terms in articles online, in your Bluesky posts, in our group chats. What’s the difference between integrity and authenticity? Privacy and security? We keep misusing them, and you do too. So we thought it’s time to iron out some definitions for all of us.

Each of these terms refer to how data (a photo, a DM, a webpage) gets processed, transformed, or handled by computer systems – all with the intent of making the source material or its delivery more trustworthy. We’ve written these definitions for programmers who have some cryptographic background, or people who already know what a hash and MAC are. If you don’t, hit up Wikipedia for the short version or Crypto 101 for the long version.

Note that a high quality trust system is going to combine all these elements together. Transport Layer Security (TLS), the ‘s’ in https://, is an example that gets used repeatedly here because it combines many of these concepts to form a system that secures the entire web.

This glossary is designed to be read like a blog post. Take a look!

Terms

Digital Security

This is a very broad term, meaningless without context. It could encompass any of the techniques mentioned on this page, and beyond – such as the use of strong passwords by employees. In general it means “protection against the threats we are considering”. When someone says “our system is secure”, ask: “against what?”. The proceeding entries in this glossary will show various ways to make things more secure, and the threats they protect against.

Integrity

The first and most important building block of digital trust. Also called “data integrity”. This means that the data has not been altered. It is exactly the same from creation to reception.

Cryptography

The technologies used for data integrity are cryptographic hash functions and derivative constructs like message authentication codes (MAC). Think of SHA-256 or HMAC.

Example

You receive the hash of a file over a trusted channel. Now when you receive the file over an untrusted channel, you can verify its integrity: that it’s exactly the file you want, because the hash you calculated matches the hash you received. You could also receive the file from any source, even untrusted ones, because you can verify it’s the correct file.

In practice

Data integrity is key to how torrenting works. The .torrent file or magnet link contains the hash of the file(s), so when you download from seeders across the world, you can verify you got exactly what you asked for.

It’s also part of any competent encryption system, including TLS. It prevents data from being modified in transit.

Authenticity

We know data comes from the right source if a system provides authenticity; this means it offers a way to prove you are talking to the right person, organization, or machine. Also known as “authentication”.

Cryptography

This is achieved through digital signatures and public key cryptography. At a higher level, public key infrastructure connects authenticity to real world identities, in hierarchical (web certificate authorities) or peer to peer frameworks (web of trust, GPG).

Example

You receive your friend’s public key over a trusted channel. Now when you receive messages over an untrusted channel, you can be sure which messages are actually from them, by verifying the signature attached to the message. You could use minisign, for example.

In practice

This is the part of TLS that proves you’re actually talking to “google.com” and not someone else intercepting your connection. Your browser trusts a centralized group of signers, called “certificate authorities”. They sign attestations that say “this is google.com’s public key”. Then when google.com signs its website data with that key, your browser accepts it. A malicious actor wouldn’t be able to forge those signatures.

Privacy

Also known as “confidentiality” or “secrecy”, this means the data is not available to any unintended recipients. This could simply be that the data is not accessible, but it’s often that the data has been sealed: like a box only your friend can open.

Cryptography

Privacy is often achieved through encryption. It could be symmetric-key encryption (like AES or ChaCha20), where data is encrypted with a shared secret key. Or it could be asymmetric-key encryption (like RSA), where the data is encrypted using the other party’s public key. In practice hybrid encryption is often used, where both these methods are combined.

Example

You retrieve your friend’s public key from a public place, like their website. You encrypt a file (using age, perhaps) and post it publicly, or send it through an untrusted channel. Even if others download the file, only your friend can decrypt it and read the original contents.

In practice

Privacy is the final element of what TLS provides; why banking over the web is possible, for example. This is also why chatting on Signal is “private”. Information is not revealed, even when others on the café wifi can watch your traffic.

Verification & Validation

These are ambiguous and similar terms. They are often used interchangeably. In the context of digital trust, they usually refer to the process of checking that something has been done correctly. This could include:

Hashing the data you received to check it matches the hash you expect
Checking the signature of the data matches the data and the public key you expect
Checking the timestamp is within an expected or allowed range

This is about whether the trust information provided matches expectations. If hashes, signatures, etc. are not verified, no digital trust can take place. When they are, we can move on to actually processing the content itself: showing a JPEG to the user, for example.

A more formal definition comes from RFC 4949:

Use “validate” when referring to a process intended to establish the soundness or correctness of a construct (e.g.,”certificate validation”)
Use “verify” when referring to a process intended to test or prove the truth or accuracy of a fact or value (e.g., “authenticate”)

This means a “valid signature” has the right data structure, encoding, etc., but a “verified signature” is one that is made by the correct public key for the correct message.

Trusted Timestamping

Trusted Timestamping refers to techniques for proving data existed before a certain point in time. A blog post may read “Jan 16, 2023”, but that requires you to trust the publisher, who may have forged the date. Trusted Timestamping allows you to trust a timestamp is correct without having to trust the content author.

There are two main techniques for this: having a trusted third party attest to the timestamp, or putting the data on a trustless system like a blockchain. You can read a detailed comparison in this blog post.

Cryptography

Hash functions (data integrity) and signatures (authenticity) are combined to form this system.

Example

A cryptographic hash function is used to reduce the data to a smaller number of bits. This hash is then submitted to a trusted third party, who returns a signed statement akin to “I saw this hash at this time”. This signed statement is published, and anyone can verify the hash and signature if they have the original data.

Alternatively, the hash is submitted to a blockchain, to be irrevocably included in the timestamped ledger. Anyone can verify that this hash is there.

In practice

Trusted Timestamping is widely used in industry to timestamp signatures, so they can still be validated even if the signing key is later leaked. Timestamp authority services are provided by reputable companies such as Apple or DigiCert.

If you’d like to try doing this yourself, you can use OpenTimestamps or this tool from Stanford, or the Proofmode app.

Content-addressing

The combination of hashing and storage. Instead of storing files or application data by semantic name or timestamp, content-addressed data is stored and referenced by the hash of its content. This has some advantages. Data is self-certifying, can be stored anywhere, and is automatically deduplicated. In exchange it’s harder to explore, since every filename is just a string of seemingly random characters.

AKA “content-addressable storage” (CAS).

Cryptography

Strong hash functions like SHA-256 or BLAKE3 are typically used. Specifications for hash and metadata encoding have been written, such as DASL.

Example

Content-addressing typically happens behind the scenes, since hashes aren’t user-friendly. For example, when a social media browser needs to load an image from a post, the post provides the image’s hash. The browser can query various sources for that hash, retrieve the file from any source that has it, verify it matches the hash, and display it to the user.

In practice

IPFS and Bluesky use content-addressing to store user data and large files like images or videos.

Digital Preservation

This could be as simple as a backup drive, or as complex as the Library of Congress. But a good archival system will go beyond copies and backups and instead include elements of digital trust. These might be:

Hashes to reference content and ensure it hasn’t changed
Signatures to stamp content: “we the archive sign off on this data as authentic”
Trusted Timestamping to prove content wasn’t modified since archival
Content-addressed storage to deduplicate the files in the archive

Together these can help show the history of any item in the archive. For public archives with crucial information, making their data more trustworthy is increasingly important given the rise of AI generated content.

Provenance

This term refers to the origin or source of a digital asset (like a JPEG), as well as its “chain of custody”. Provenance answers questions such as: When was this image created? How and when was it transformed? Who stored the data, and for how long? What other assets were involved in processing or creating it? It’s equally applicable to a physical object in a museum, evidence in a court of law, or financial ledgers. A similar term is “data lineage”.

Provenance doesn’t have one definition or application. There are a variety of techniques for tracking the provenance of data, and they will differ across industries. It’s especially important for archives.

Cryptography

One cryptographic tool to help with provenance is Trusted Timestamping. This may involve a third party signing a hash of the file along with a timestamp, to attest to when it existed. It could also involve publishing the hash of the file to a trustless network like a blockchain.

Another cryptographic standard for this is C2PA. It defines how to hash an image (or other media), sign a statement about how the image was edited, and then embed that signed statement into the image itself, so it travels with it on the web.

Example

You see an image on social media, or posted on a news agency’s website. Through UI elements on the image, you can see who created the image and when, as well as how it was edited in Photoshop. You can also upload the image to a third party website that verifies its authenticity.

This is mostly speculative. C2PA exists but is not yet widely used or deployed in user-facing settings.

In practice

User-facing technologies for this are still being developed. You should be able to edit a photo with Photoshop today and then upload the photo to Adobe’s inspector and see the provenance info, embedded in the image through C2PA. Another option would be to install Proofmode on your phone, which will collect provenance information for your photos.

Distributed Press: ‘Building the Road as We Travel’*

2025-12-09T00:00:00+00:00

↑ Explore the interactive version above, or read the full text below ↓

Distributed Press was born where code meets cooperatives. As Hypha’s first internally incubated product, it was designed to solve a problem that is increasingly urgent: an unhealthy reliance on centralized publishing tools. But while the technology was ready, the industry wasn’t. Between dwindling budgets and institutional inertia, the media world moves slowly. While Hypha will continue to maintain the Distributed Press architecture, our grant funding from the Filecoin Foundation for the Decentralized Web (FFDW) has concluded, marking an opportunity to reflect on the project’s rewards and challenges.

Defining the Protagonist’s Perspective

I'm now fully immersed in embodying the perspective of a
Distributed Press team member. This includes grappling
with the real-world challenges, such as funding,
open-source model tensions, and the "Protocol Paradox."
I've been refining my understanding of Distributed Press.
It's not a protocol itself, but a system leveraging IPFS,
Hypercore, and ActivityPub. I'm also now crafting a
narrative voice: three years in and reflecting on the
journey:

We just filed our Q3 progress report for the Filecoin
Foundation for the Decentralized Web.

It's a strange document. Half of it is a progress update
on Distributed Press, detailing our work on the Social
Reader and the Social Inbox. The other half is,
essentially, a justification for our existence. It's an
invoice stapled to a manifesto.

We are all-in on the idea of "protocols, not platforms."
We're choking on the digital monopolies built by the
last generation. We know the answer is to build systems
that are open, decentralized, and owned by no one.

But it's one thing to believe in that. It's another
thing to build a business on it.

When I sat down to create this post, I tried prompting an LLM for some thought-starters on how to frame the tensions inherent in a complicated multi-year open source software project. In the course of this discussion, the LLM fabricated something it calls “the integrators’ curse; this challenge (which doesn’t exist) supposed that the Distributed Press project was limited by its dependence on open source protocols, making the work to build (or integrate) a user-facing product on top of said protocols all the more challenging. It concluded, rather dramatically, that:

This document is the sound of a team being crushed by this reality.

While the integrators’ curse is bogus, it does touch on the tensions regarding the decentralization of the infrastructure, and the challenges of working with emergent technology. These issues are related, as we need to seed the network to make it viable; in this case, Hypha runs a server to make Distributed Press a thing. Creating additional server nodes - ideally located in numerous jurisdictions - was always a phase 2 goal. Relatedly, the team occasionally got bogged down in decentralization purity discussions of the sort that arise when discussing ATproto, for example. Overall though, we did well to bridge the usability gap inherent in emerging tech; the Get Started page makes it quite easy to publish your site with Distributed Press; not to mention that the Sutty CMS is literally a WYSIWYG editor for static websites.

Which compromises are you willing to make?

Maybe you add a "default" server that your company
controls, just to make onboarding easier. 
(Oops, you just centralized it).

Maybe you add a feature that users want but that breaks
the federated model. 
(Oops, you just built a moat).

Maybe you build a slick, proprietary client for your
open protocol, and it's so good no one uses any of the
other ones. 
(Oops, you're the new platform).

Technical details aside, there is a more significant issue with the project: the all important product-market fit alluded to earlier. We built a B2B product (Distributed Press) for a market (publishers, journalists, media) but despite the downward slide toward media censorship in North America, the fit is not yet there. Media organizations know that the centralization of their distribution infrastructure is a looming cliff, but as of now - December 2025 - it’s still a tomorrow problem. Is Distributed Press just ahead of its time? The reality is that when tomorrow finally comes, it’s likely that technology will have evolved and someone will put forth a simpler/faster/better solution to evading government or more likely, Big Tech Billionaire control of media infrastructure. Technologists are often accused of offering solutions to problems that don’t yet exist; in this case, the issue is real but it’s just not pressing enough for media orgs with one eye on the bottom line. It’ll be existential–just not yet. As if there were any doubt, Petr, the business development lead we hired in Summer 2024 noted in his final report: “Assumption that journalists or publishers care about their work being distributed to DWeb is false.”

SWOT from the 2025 Distributed Press Marketing Plan

But: just because the media isn’t there yet doesn’t mean they shouldn’t be. According to the 2025 Reporters Without Borders (RSF) World Press Freedom Index, “more than half of humanity lives in a country where the state of press freedom is considered ‘very serious.’” And while the political situation in the US is truly unsettling, most of these people are living in countries outside of North America.

Without a clear product market fit, thus impacting potential sales, Distributed Press is reliant on grants to meet its goals. Grant funded technology, as with anything grant-funded, is tough. At Distributed Press, we were incredibly fortunate to work with the amazing FFDW team: they are supportive, thoughtful, and really get the work we’re doing. Their reporting structures are efficient and not overly onerous; they were a solid partner throughout this long and constructive phase of the project. But grant writing is both an art and a science, and the Distributed Press team wasn’t able to attract a new funder to the project. Over the past few years at Hypha, we’ve worked on numerous grant-funded technical projects. They have been wonderful, creative and exciting projects to work on, but once the funding ends, the projects also end. They live in the purgatory of Github or GitLab and some of them (depending on subject matter) join the ranks of the Civic Tech Field Guide Graveyard. Not to say that they can’t or won’t be revived with the right funder coming on board; we’ve also resuscitated a few tech projects in our time. At the end of the day, maintaining a steady stream of funding is hard without a dedicated fundraiser on the team, and Hypha doesn’t have anyone currently wearing that hat.

They are using a grant-based funding model (which
demands short-term, reportable "progress") to build on
protocol-based infrastructure (which requires slow,
long-term, consensus-driven change). This is like trying
to farm a redwood tree in a quarterly window box.

While Distributed Press may not be poised on the edge of commercial success, the project has been undoubtedly successful in other ways. To close out this reflection on the project, I want to highlight all of our achievements.

Firstly, the team delivered on the original vision of an easy to use, decentralized publishing tool. Over 100 sites are using Distributed Press to share their content via IPFS and Hypercore. It’s a point of pride that the awesome teams over at Fight for the Future and DWeb Camp are using our technology to make their websites more resilient.

“I really like the last slide call to action: ‘Become a pioneer in the new era of content distribution. It may be the ultimate future of publishing.’ - don’t be afraid to use it often and everywhere. It may become your brand slogan eventually.” - Petr

Although the social media component of the project shifted as the project matured, the Social Inbox and Social Reader are two very interesting features of the Distributed Press stack. Running against the current dominant social media trends, the Social Inbox and Social Reader embed user control, privacy and care into the world of micro-chat.

The Social Reader is a privacy-first personal reader for subscribing to content published on federated social media; we’re fond of saying it’s for all the lurkers out there. Although it’s powered by ActivityPub, you don’t need a Mastodon account to use it. It’s local-first, running off your own computer. It works offline. (It’s what you’ll all be using when the next solar flare takes out the power grid for a day or two.)

Conversely, the Social Inbox is a tool for connecting and conversation; it works by showing interactions on federated social media platforms like Mastodon on your website. With the Social Inbox enabled, websites obtain their own account on the Fediverse, allowing it to automatically send out new posts to followers at the time of publication. When other users reply to posts, you can approve them to be published to the site as comments. The Social Inbox allows readers to directly engage with your posts where they already are, and gives publishers the ability to incorporate public dialogue into their websites. Remember the earlier points about the danger of centralized distribution? This tool is a direct response to that challenge, and this approach has been validated by other orgs such as Ghost and WordPress working to add similar ActivityPub-powered tools to their platforms.

In Working in Public, Nadia Asparouhova (formerly
Eghbal) distills the reality of open-source software
with her "roads and bridges" metaphor.

Open-source protocols are infrastructure. They are the
digital equivalents of the pipes, roads, and bridges we
all use every day. And just like physical
infrastructure, everyone uses it, but almost no one
wants to maintain it. For a long time, this was a
problem for the protocol maintainers themselves. But
we're facing a new, second-order version of this
problem.

The protocols we build on — IPFS, Hypercore,
ActivityPub — are the "roads and bridges." Our product,
Distributed Press, is the "town" we're building at the
nexus of these three great highways. Our "Social
Reader" and "Social Inbox" are the bustling public
squares and post offices for this town.

While all of the technical accomplishments are well and good, it’s the teamwork and solidarity of the Distributed Press project that stands out as genuine success. For three years, the team spanned numerous timezones, two cooperatives with different working cultures, and a fair amount of team member turnover to deliver on a vision for decentralized publishing. Despite (or perhaps because) of these circumstances, working on Distributed Press felt good. We always had a check-in at the beginning of our weekly team calls to take a beat and see how everyone was doing. The cadence of the Distributed Press project and its team were one and the same: genuine and filled with care for each other and for a vision of better technology.

Gracias to fauno, Ania and the whole Sutty team. Thank you to our technical lead Mauve, Akhilesh, Jacky and to the original Distributed Press dreamers, Benedict, Udit and Mai.

So what does "success" even mean for a project like
this? I'm pretty sure it's not a valuation. It's not an
"exit."

Maybe success is just... usefulness. Maybe it's
resilience.

The goal isn't to build a road so good that no one knows
who built it. The goal is to build a town so good that
it proves, once and for all, that you can have a
thriving, vibrant, sustainable community living on open,
public roads.

We're figuring this out in real-time. The old startup
playbook doesn't apply. The old open-source playbook
doesn't quite fit either. It's awkward, and it's
contradictory, but it's also necessary. This is the real
work.

*David Herrera

**This doesn’t actually exist

LLM text is from Gemini 3 Pro, with some light editing by me

Timeline of Distributed Press (2018-2025)

2018

DWeb Camp - The seeds are planted when Hypha collaborator Mai and Hypha founding member Benedict spend time together at DWeb Camp. Wendy Hanamura serves as a key connector. Mai, interested in the decentralized web ethos, recognizes a contradiction: writing about DWeb Camp while publishing on centralized platforms like Medium or Squarespace, both running on AWS.

2019

The Distributed Press Idea is Born - Benedict, Mai, and Udit begin developing the concept. Ben envisions a plugin to pin posts to decentralized web protocols. Mai, approaching from a writer’s perspective, wants to use it to publish their own work. The philosophy emerges: if you want to build a tool, build a magazine as proof of concept.

Through conversations with artists and activists, the team attempts to form a community around the tool. The consensus: a magazine would be the best way to demonstrate the ideas in action.

Grant for the Web - The project receives a $50,000 Creative Catalyst grant from Grant for the Web (a collaboration between Mozilla, Creative Commons, and Coil) to explore web monetization. These funds enable the creation of COMPOST issues 1 & 2 and the bare bones of Distributed Press—not yet usable for most people, but functional for those comfortable with early-stage technology.

2020

Building the Foundation - The initial funds from Grant for the Web (Coil, later Interledger) supports the team, comprised of Hypha members and two independent contractors, in creating the proof of concept: both the basic publishing technology and the magazine itself.

Call Series Begins - The team initiates conversations exploring what’s usable and promising in the decentralized web space.

January 2021

Ruby API Client is Born - sutty writes the ruby api client for the first version of DP, kickstarting conversations about integration and the common grant application :D Distributed Press v0.1 is released.

March 2021

COMPOST Issue 1: “Fertile Ground” - The first issue launches with paid writers (approximately $700 USD each). COMPOST—short for “commons post”—publishes creative works reflecting on the web as a digital commons. The editorial notes: “This publication comes out of a year and a half of scheming, discussing, and organizing. It came out of our desire to create a piece of the web that embodied our dreams. We were tired of platforms making us bitter, angry, and afraid to connect online. We were also tired of being cynical.”

September 2021

COMPOST Issue 2: “Innoculate” - From the editorial note: “As dominant platforms continue to construct an unimaginative reality of sleekness, convenience, and extraction, we wonder: How do we Inoculate networks with our consideration and attention, against the flattening, homogenizing forces of the internet?”

July 2022

Major Funding Secured - Six-figure agreement signed with Filecoin Foundation for the Decentralized Web (FFDW) with four key milestones:

Milestone 1: No-Code DWeb Publishing

COMPOST to be published on DWeb through Sutty CMS as a toggle feature
Internal DNS management, eliminating Digital Ocean dependency
White-labeled COMPOST theme

Milestone 2: Decentralized Social Messages

Web Mentions integration into the DWeb

Milestone 3: Versioned Content Discovery and Redundancy

Website version capture (similar to Wayback Machine)
Media type redundancy
Performance tuning

Milestone 4: ID Standards and Content Verification

Enable reading and interaction across preferred platforms
UX reports to be produced by Sutty (user experience and DWeb emerge as recurring themes)

August 2022

Team Expansion - Mauve joins the Hypha side of the project.

September 2022

Infrastructure Independence - The team begins hosting their own server.

Late 2022

Backend Strengthened - Jacky is hired as backend engineer to complement Mauve on the Hypha side.

February 2023

Milestone 1 Complete: No-Code DWeb Publishing - Sutty integration enables “publish to DWeb” toggle, DNS management moves in-house, white-labeled COMPOST theme added.

First Milestone Report - The team delivers the first biannual report to FFDW, reflecting on the complexity of the collaboration:

“Our project involves many moving parts – we are two worker cooperatives based in two countries with two different primary languages (English and Spanish) working on integrating three projects (Distributed Press, Sutty CMS, and COMPOST). On top of that, we are figuring out which channels and social media platforms to use to promote the various facets of the project. We have not yet come up with a decisive solution to this – and perhaps there is no clear cut path. But we realized that asking other project partners to inform our approach is necessary to be able to navigate this complexity well.”

May 2023

COMPOST Issue 3 - “Water Bodies” is published. This issue showcases sutty’s reusable COMPOST theme.

July 2023

Social Media Research Complete - Analysis of how Distributed Press interacts with centralized and decentralized social networks.

September 2023

Milestone 2 Complete: Decentralized Social Messages - Social Inbox API goes live based on ActivityPub protocol. Jekyll plugin created for static ActivityPub activities.

November 2023

COMPOST Gets Social - ActivityPub moderation features added to COMPOST blog.

March 2024

Milestone 3 Substantially Complete - ActivityPub moderation panel integrated into Sutty CMS. Social Reader launched for p2p content access. First UX workshop completed with grassroots communities. Ania hired as project manager.

April 2024

Milestone 4 Re-Evaluation - Project pivots based on community feedback, shifting focus toward static site generator integration and micropayment systems for the Fediverse. UX workshop report completed.

Patterns of online communication and organization are changing, and Distributed Press has pivoted to meet this demand. Typically, people use websites as static repositories of information while social media allows for more fluid two-way conversation. In the coming milestone, the Distributed Press team is aiming to create a space that merges the easy connections of social media with the richer content of static websites. We believe the features highlighted in this milestone will create a more vibrant community ecosystem, while also retaining the safeguards of privacy protection that are required by many of our users… While the past milestone focused on sending information outwards, Milestone 4 will improve the ability to receive and display interactions with the Fediverse. Citizen journalists using the Sutty CMS will be able to show comments and interactions on their websites, while Social Reader users will be able to see replies on posts. Mastodon users will be able to see most posts retroactively when they follow an account. (Revised Milestone 4 document, as submitted to FFDW)

Summer 2024

Business Development Consultant - As the project enters its final phase, we bring on Petr on contract to focus on sustainability and establishing new stakeholder partnerships.

Fall-Winter 2024

Sutty reworks the onboarding flow, with a new Get Started page pointing potential users to easy ways to set their website up with Distributed Press.

Spring 2025

The Final Chapter - FFDW generously provides a final injection of funds for the project, allowing the team to create an Explore page, an Index of all sites using Distributed Press. And Sutty launches a Resilience Challenge, offering funding to two social activist organizations (Desarquivo and TLGB Bolivia) to help them recover their website and host their content on the distributed web.

Distributed Press is an open source publishing tool for the World Wide Web and the Distributed Web. It automates publishing and hosting to decentralized protocols including ActivityPub, Hypercore, IPFS, and Bittorrent.

This innovative tool enhances any Content Management System (CMS) by integrating peer-to-peer (P2P) and decentralized protocols for efficient content distribution and archiving. We also offer a suite of tools (the Social Inbox and Social Reader) for interacting with the Fediverse via ActivityPub. (From the final report to FFDW)

Dripline

Pollen & Nectar

Motivations

Nectar

Pollen

Nectar in other contexts

Navigating Media Publishing in an Agentic World

Layer 1: Visibility

Layer 2: Rights Expression

Layer 3: Settlement

Layer 4: Enforcement

Conclusion

Introducing Rook: Sovereign Intelligence for the Solidarity Economy and Beyond

Fixing the ‘dumb opinions’ problem: Addison, Johnson, Walpole

Bibliography

Notes

Similarity at scale

Comparing basic, cryptographic, and perceptual hash functions

How perceptual hash functions work

Use cases for a perceptual hash function

We built you a garden 🌼

Discover your unique garden

Plant your seeds by hand

Follow the flowers

Search for spores hiding in plain sight

Let the garden grow!

The Other AI

Who took this photo?

Origins of provenance

Provenance in practice

Limitations

Who is provenance for?

Publishers

Platforms

Web users

Further reading

Digital Trust Glossary

Terms

Digital Security

Integrity

Cryptography

Example

In practice

Authenticity

Cryptography

Example

In practice

Privacy

Cryptography

Example

In practice

Verification & Validation

Trusted Timestamping

Cryptography

Example

In practice

Content-addressing

Cryptography

Example

In practice

Digital Preservation

Provenance

Cryptography

Example

In practice

Distributed Press: ‘Building the Road as We Travel’*

Defining the Protagonist’s Perspective

Timeline of Distributed Press (2018-2025)

2018

2019

2020

January 2021

March 2021

September 2021

July 2022

August 2022

September 2022

Late 2022

February 2023

May 2023