The Interledger Community 🌱: Hop Sauna

Hop Sauna social marketplace framework — ILF Ambassador Final Report

Gavin Chait — Sat, 24 Jan 2026 08:45:25 +0000

Hop Sauna is a core technical stack aimed at developers to support implementing a federated, community-moderated web shop offering custom digital objects.

Project Update

Those who wish to lead change have a responsibility to demonstrate and build trust with the communities and individuals we hope will support us.

Our online activity is fraught with dark patterns, described by Caroline Sinders in her Ambassador Report. For open payments to reach greater acceptance by regulators, buyers and sellers, we have to demonstrate greater ethical responsibility than the alternatives. More than that; we have to be easier to use, easier to understand, and safer for everyone.

Supporting African creators

The community I most wish to bring online are African authors on the continent who struggle with financial exclusion.

Even if you are a well-published, famous African author in the diaspora - a Suyi Davies, Nnedi Okorafor, or Tade Thompson - that doesn't mean you can reach African readers. And, if you're an African living on the continent, you can give your work away on any of the major platforms - as Dilman Dila does on YouTube - but you struggle to charge for it.

And then there are the horror stories. Anyone who has ever self-published on Amazon knows how hard it is to sell even one book. A few years ago Chovwe Ekpeki, a Nigerian author, edited an anthology of African scifi which he modestly called The Year's Best African Speculative Fiction. Listed on Amazon's US site, he managed to sell $2,000 of books. Just before he was due to be paid out, Amazon notified him that Nigerians weren't eligible to sell, and they closed his account, and took his - and his contributors - money. This was eventually sorted out, but it left us all with a sense of how tenuous is our relationship with these platforms.

And so we come to our challenges: we are not able to gain access to readers, we can't get paid by the places we publish, and our readers can't always use the ways they are used to paying - like mobile money - online.

Hop Sauna release

I'm struck by just how fundamentally weird the contemporary internet has become. It's got the diversity, curiosity and innovation of a small agricultural town in middle America, or even somewhere in the Northern Cape. In many parts of the world, Facebook is the whole of the internet, just like Amazon is the place you shop. Discovery and purchase happens exclusively in properties controlled by such a small number of companies.

You can judge how far into the barren wastes of the web you are by how often the site you're visiting pressures you into subscribing to their newsletters and build an account there. They're desperately worried they're about to lose you forever.

When I started developing Hop Sauna, I wanted to break these walls open to the wild early internet. I want software that encourages connection, is moderated by the creators who sell their work on that site, has some friction to launching new products so that it feels more intentional, and I want payments to be low-cost, and direct between buyer and seller.

Some of this leans into the growing community of ActivityPub social websites, like Mastodon, but a lot depends on Interledger's success with open payments.

Consolidating everything I've learned this year is still a work in progress, and this report is a continuation of my interim report.

Progress on Objectives, Key Activities

If you know your Clausewitz, no plan survives contact with reality, or your Tyson, where everyone has a plan till they get punched in the face, these are my original goals, and how they evolved.

Goal 1: deliver a template developer stack ready for custom creation of creator community-moderated Open Payments-enabled web shop

Hop Sauna is available as an initial release. There is a great deal of documentation for developers, and much more to be done.

This went more or less as expected, although the steepness of the learning curve, and the challenges of working with relatively immature software, did cause delays as I grappled with getting everything into my head.

Goal 2: develop marketplace tools for facilitating buyer and seller exchanges, including for webhooks for responding to successful purchases, disputes and refunds

Here I was limited by the provisional state of the Python Open Payments Developer Kit. Over the course of my project, I refactored and redeveloped the kit, with the following updates:

Model refactoring and fixes: generated code resulted in models that don't return data, or duplications and deeply-nested RootModels much of which could be deleted and simplified.
New convenience functions: testing the API effectively requires building a full purchase workflow, but such a workflow is also useful to developers using the SDK. The README in the process folder details the main objectives and roadmap, and this update implements the simplest possible payments workflow for purchase and sale.
Updated tests: all the tests should be refactored, especially as private endpoints have been committed to the repo. Tests for the convenience functions run through a complete workflow, and use the new environment variables to safely do a real-world test on the Rafiki test server.

There is currently a pull request awaiting review.

Further development on the open payments aspect of Hop Sauna awaits on approval of this pull request.

Goal 3: kick-start cooperative creator marketplaces through engaging with stakeholders to align the template stack with their needs, and to develop a supportive environment for project sustainability

Early in 2025, I convened a group of African SFF authors from around the world to discuss how best to serve their needs. The group includes:

Cheryl Ntumy: Ghana-based SFF author and founding member of Petlo Literary Arts, a non-profit that develops and promotes creative writing from Botswana. She is also a founding member of the Sauútiverse Collective, an African speculative fiction collaborative worldbuilding project.
Dilman Dila: Ugandan writer, film maker and a social activist. His books include Where Rivers Go To Die, which was shortlisted for the PKD Awards (2024), his films include, “What Happened in Room 13”, has been watched more than 8 million times online. He is currently working on his third feature film, about decentralized governance.
Ivor Hartmann: Zimbabwean writer, editor, publisher, and visual artist. Awarded The Golden Baobab Prize (2009), finalist for the Yvonne Vera Award (2011), selected for The 20 in Twenty: The Best Short Stories of South Africa’s Democracy (2014), awarded third in the Jalada Prize for Literature (2015), and Nommo Awards nomination (2017). He also runs the StoryTime micro-press, publisher of the African Roar and AfroSF series of anthologies, and most recently ZamaShort.
Ayodele Arigbabu: is a writer, architect and creative technologist with close to two decades of experience in delivering projects at the intersection of architecture, design, film, digital media, publishing, event production and curation, as well as in the development of digital and interactive arts and applications. His short story "You Live to Die Once" won the 2001 Liberty Bank Short Stories Prize; his poem "Livelihood" got an honourable mention at the 2003 Muson Poetry competition. His stage play Moremi: The Legend Retold was staged in December 2003 at the University of Lagos Main Auditorium to an appreciative audience, and went on to be performed in Oklahoma and at the National Theatre of Nigeria.
Suyi Davies Okungbowa: award-winning author of fantasy, science fiction and general speculative fiction. He has published various novels for adults, the latest of which is Son of the Storm (Orbit, 2021, first in the epic fantasy trilogy), The Nameless Republic (the second book in the series, Warrior of the Wind, 2023). His debut novel, David Mogo, Godhunter (Abaddon, 2019) won the 2020 Nommo Award for Best Speculative Novel.
Jude Umeh: published author and thought leader on the intersection of emerging technology and Intellectual Property on Digital Content and Rights, Umeh currently works as a Director of AI Business Strategy with Salesforce Professional Services.

Much of what follows is influenced by the guidance of this group. Many of them expressed reservations that they could understand or contribute to the tech, but I pointed out that it's not their job to understand the tech. It's my job to understand their needs and then reflect that back to them using the tech.

What impact does the project have on your perception of digital financial inclusion?

I feel more encouraged after this past year than I was at its outset. I have entered my Ambassadorship with a "show, don't tell" strategy, preferring to build and demonstrate what I'm doing than to simply talk about it. The more I engage, listen and learn, the more viable my approach for federated, collaborative social marketplaces feels.

Certainly, there is a long way to go, but the solutions offered need to be better than what exists, not be perfect on the first attempt.

A lot rests on the success of the open-payments enabled payments providers and wallets, and these are still in a very early stage. However, if we don't also have the ability to rapidly implement webshops using open payments, then that time and investment will remain unfulfilled.

Until then, the best hope for the future is to keep building.

Project Impact & Target Audience(s)

There is something in innovation I call the Milk Problem.

Everyone knows what milk is. If I bring you a new type of milk, I don't need to explain what it is, just tell you how it is different from other milk and why you should buy it.

Push your innovation further out, and you end up in a place where no-one knows what it is you're offering them. You first have to explain everything about that thing before you can get around to the product itself and why people should buy it.

Hop Sauna is not "milk". It is a framework for a new type of federated social commerce which doesn't exist formally as generally-available software. Sure, it builds on social publishing and leans on existing commercial models, but it is complex to explain quickly. People don't necessarily have a mental model for it.

My author's group discussed ways in which they want to be paid and I then structured this into a set of archetypes:

One-off: a payment - usually of purchase and sale - between a buyer and seller which happens once.
Recurring: a payment - usually a subscription, or structured fee - between a buyer and seller.
Conditional: a payment which is conditional on some additional factor - e.g. the seller is required to perform some task, or a threshold of purchases are required - before funds are transferred.

This covers everything from an Amazon purchase, to Spotify streaming subscriptions, to Kickstarter campaigns or even an Uber taxi trip.

There are a myriad of these types of requirements. Each of them needed to be documented, understood, mapped to methods in Open Payments or ActivityPub, and then represented in ways that can be understood by developers, and potential buyers and sellers using that software.

The challenge is many developers have little experience of the challenges of the financially excluded, and the financially excluded don't often get a voice in the technical solutions developed on their behalf.

Hop Sauna needs to integrate this dynamic by default without causing anyone to realise they have no idea what milk is.

I think I'm getting there.

Communications and Marketing

2025 Interledger Summit Mexico City

I presented the first release of Hop Sauna at the 2025 Interledger Summit in Mexico City, as well as charting out where we are, and the sorts of apps I'd like to see arising from my work:

As examples, consider cooperative versions of Uber, where groups of drivers regulate and manage themselves, and have a direct relationship with their passengers:

Or a Booking.com alternative, where guesthouses and hotels don't have to pay intermediaries to handle their bookings for them:

2025 Interledger Hackathon Mexico City

I was a mentor at the hackathon, during which teams attempted to build new applications for open payments. This gave me first-hand experience of the types of challenges developers face when using open payment development kits, and also to gauge interest in more enhanced features for the toolkits.

I also had the rare pleasure of having two teams adopt Hop Sauna during the event and deliver completed submissions using it.

Podcast

Cheryl, Dilman, Jeremiah Lee from the Foundation, and I collaborated on a podcast, published in December last year.

This covers much of the ground we considered during my Ambassadorship, ranging from the cascade of transactions necessary to get money from publishers in the US into the hands of authors, to platform exclusion, to the multiple ways we need to borrow identities from others with more privilege just to get things done.

I have also begun engaging with some of the key developers and infrastructure designers of the fediverse to ensure that Hop Sauna plays well with others.

What's Next?

Hop Sauna extension

There is an initial set of moderation hooks, and I will be focusing on extending this in Q1 2026.

My working plan so far is to implement the following:

Site level:
- Universal block lists
- Geotargeting - fairly blunt, but using IP addresses to isolate "bad places"
Actor level:
- Individual blocks/mutes at site and actor level
- No reply except for direct messages, and limit direct messages by default to followers only (they can open this, if they wish)
- Detachable reposts for the inevitable shark-baiting. Given many stacks aren't yet implementing this. I figure it works more like a mute.
- Geotargeting of individual actors with options to block, show different information, or offer a different price. This works on multiple levels from the way I was originally thinking of it (offering books for sale only in certain countries) to the limitation of products which may be illegal outside of certain jurisdictions.

This mostly reduces clutter and problems on the commercial server, but a repost on another server probably supports replies there. Again, a functional mute on main.

The more specific commercial limits will be:

Dunbar's limit of 150 creators (any number of supporters, depending on the type of service - on my Kindle-alt, readers have accounts to store and read their books).
All Actor Services (products) can only be made public by an approved editor with those rights.
Messages are all generated, meaning you can only send a message to your followers when a specific type of action occurs (publishing a book, offering a period-limited discount, that sort of thing).

None of that stops individuals reposting their product announcements on their other socials, but there they would be limited by the rules of those communities.

The Dunbar's limit includes an extension - the stack name cannot be a creator server. As example, the Kindle-alt will be called Qwyre (rebuilding my existing https://qwyre.com which stopped working commercially when Coil was closed, but still works perfectly well as my main ereader). Qwyre itself will be closer to something like JoinMastodon, and eventually become a federated search engine for books from all the different imprints (servers).

I think it's critical to ensure distribution and discovery to prevent agglomeration effects that overwhelm safe communities.

Qwyre for self-publishing

I have a new novel. My intention is to dust off the old Qwyre and build a new Kindle-alternative where I can collaboratively publish my work.

Community Support

I would appreciate the following:

Code review
Feature development
Internationalisation
UX / UI
Unicorn Hunters

This latter is aimed at developers who want to build on Hop Sauna with apps targeting existing monopoly commercial tech, like Amazon, Kickstarter, Uber, etc.

Oh, and funding. I'm always looking for funding to support continued development.

I wish to thank Interledger for their support, and look forward to everyone's thoughts on progress to date.

Hop Sauna — ILF Ambassador Progress Report

Gavin Chait — Wed, 16 Jul 2025 17:35:54 +0000

Hop Sauna is a core technical stack aimed at developers to support implementing a federated, community-moderated web shop offering custom digital objects.

Project Update

Any system permitting commercial exchange exists at the intersection of what is technically possible, ethically responsible, and permissible under the patchwork of international regulatory compliance.

Building a commercial website is relatively straightforward. Frameworks - like Django or Drupal - exist. You can integrate Stripe or PayPal quite quickly. But, once you're done, such a site offers little advantage over listing your products on Amazon or eBay, with the huge downside of being functionally invisible to the larger world. If you're already famous, moving to your own infrastructure may have advantages, but if you're less known, or just starting out?

But, what happens if you live in a part of the world not supported by these platforms, or are just tired of the ethical and business practices of the platforms?

A functional, community-oriented commercial platform would have the following characteristics:

A community of peers, selling similar or compatible works, where membership is a function of acceptance by that community,
Review of business behaviour (or moderation of activity) is by the community, ensuring that members are held to agreed norms,
Costs are kept to the minimum with members paying for shared infrastructure, but otherwise keeping their own revenue, or contributing in some agreed way to their community.

Each community would also interoperate with other communities which offer similar works and where their community standards are compatible. This interoperability ensures collective discovery, much like the webrings of the early internet when search was still in its infancy. Discovering one link in the network provides access to a wider world.

A single website can be structured however the developer chooses, but the moment information needs to be exchanged between sites - federated - interoperability standards become critical. It would also be helpful if that standard already supported interactions between millions of people.

Or, to summarise, it would be nice to go where the tea is already being made.

And these then are the objectives of my project.

Building a website based on intrinsic interoperability means that one is never building in isolation. Federation requires a set of standardised methods for services sharing the same protocol to query and interpret data from each other. ActivityPub and ActivityStreams provide the protocols we need, but these exist side-by-side with the ordinary protocols of the site itself.

To contextualise this, think of email. Where email fails is that there is no way to moderate who gets to email you. So you get spam. ActivityPub enforces authenticated fetch, meaning people have to prove who they are before they can send you a message. That process of being able to send authenticated messages between authenticated actors (people) can be used for anything, and the first use-case is social media (think Mastodon).

The main challenge for anyone building from scratch is that, while the protocols themselves are well-documented, you need test servers to send messages to so that you can see if your software is capable of two-way communication. Fortunately, ActivityPub.Academy by Sebastian Jambor exists. But a lot of stuff isn't clear, and ActivityPub itself is like a Matryoshka doll of nested metadata which needs to be tested before it can be used.

An image can be listed as a URI reference, or as a data structure where the link can be named "url" or "href". And then there's the undocumented best-practices, like how exactly should you implement authenticated fetch safely?

Say you have a person on your website who has chosen to be unlisted and protect their privacy. You get a request from an external website to interact with this person. Authenticated fetch requires a named "actor" to send back a query to the sending website, allowing each website to authenticate the other. Site Albert sends a message from Bradley to your website Clarice to the person Dominique. Which identity should respond to Bradley? If this is a wild spam message designed to check if such an identity exists prior to attempting some scam, sending a message back from Clarice would confirm that their identity exists without yet confirming who Bradley is, or if they are who they say they are, or whether Dominique even wants to talk to them.

In Amazon or Facebook, if you want to send a message to another person on the same site, you both have to be logged in. It's a relatively straightforward problem.

With ActivityPub, an undocumented solution is to create a universal site actor which acts as an agent for all identities on this initial approach. Once Bradley is verified, and you can then test if Dominique is open to contact from Bradley, only then do you permit Dominique's identity to be exposed to this external identity.

And so it goes.

Each interaction requires solving two sets of problems:

How do you get this code to do what it is supposed to do? Not a trivial problem.
How do I design this so that my community members are kept safe, and are able to keep themselves safe? Even more challenging in the absence of mature systems.

I have also implemented multi-language support - both statically in the app, and dynamically in text provided by creators and admins (i.e. you could directly serve different translations via the same posts) - from the beginning.

This is very slow going.

However, when you get it right, you suddenly get a whole bunch of things working at once.

This image displays my Wandering.shop profile on the Hop Sauna build. To get what may seem intrinsically simple running requires everything else - authenticated fetch, appropriate webfinger endpoints - to be working.

Hopefully this demonstrates the value of these protocols to a community-based webshop - you can know your customer, moderate who gets to be a customer, and maintain relationships with your customers.

And so, my update is that progress is happening, but in bursts. Along the way I have also kept an eye on the Python Open Payments SDK which I will need as I head deeper into implementing web monetization and payments. Now, payments themselves are a complex set of products. Simple purchases are complemented with subscriptions, milestone-based fundraising, and other variations. Some are artifacts of the way credit cards work and aren't directly transferable to open payments.

I have convened a small group of African authors to discuss the requirements they have from a federated platform, and many of the initial suggestions raise additional questions. Take implementing a Kickstarter-style fundraiser. Credit cards allow for deferred payments, a mechanism largely developed because the high cost of transactions means that reversing a charge creates such a cascade of fees that it makes the whole thing impossible. Instead, a vendor can put a "hold" on a promise to pay, and then keep that until some criteria are met (or not) then either release the hold, or execute the transaction.

Open payments has no such method, because it doesn't need it. But, without a hold, how do you run a criteria-based fundraiser? Well, you need an escrow service. Some third-party which will hold the funds until such time as the criteria are met, or not, and then release or return the funds. And now we've crossed from a technical software problem to a regulatory one.

An affordance is a set of possible actions which arise from the design of a thing. You may wish people to use the thing you made in specific ways, but if your design also permits other ways of acting then you can be sure those ways will be tested. And, unfortunately, affordances that permit bad behaviours impose an external cost on our communities. These externalities - like spam from email, or racist autonomous language models - arise naturally because of design decisions that, while technically clever, didn't take into account ethical and regulatory responsibilities.

Which is a longish way of saying that the creator group is raising requirements that require an ethical and technical assessment, and why Kickstarter-style fundraising will not be supported in the first software release until such time as there are mature escrow services to support the function.

Progress on Objectives, Key Activities

The key goals are time-sequenced.

Goal 1: deliver a template developer stack ready for custom creation of creator community-moderated Open Payments-enabled web shops.
Goal 2: develop marketplace tools for facilitating buyer and seller exchanges, including for webhooks for responding to successful purchases, disputes and refunds.
Goal 3: kick-start cooperative creator marketplaces through engaging with stakeholders to align the template stack with their needs, and to develop a supportive environment for project sustainability.

Goal 1 is about 80% complete. This has taken quite a lot longer than I initially hoped largely owing to limited documentation. I spent a lot of time reading through other people's implementations in programming languages that are quite foreign to me (or - given coding is deeply personal - using approaches in languages I'm familiar with that are as foreign). GoToSocial is a tremendous project, written in Go, that I have trawled through for database structure and various solutions. The Bovine project is also key to my work, with a lot of undocumented features necessitating constant review of the code.

Along the way, I had to "solve" quite a few seemingly non-standardised decisions. Take hashtags, now in common use for theme discovery. Very few implementations support UTF8, meaning that Japanese or Arabic hashtags aren't universally supported. I support this, but I balked at supporting emoji-based hashtags.

What remains to be done is moderation. However, everything in ActivityPub is a message which then gets acted upon depending on the type of message it is. Moderation requests and responses are types of messages that have an impact on how the targeted identity gets to behave (banned, muted, time-outs), and deciding on what is appropriate, and what flexibility of action to permit site administrators, is itself a set of affordances with its own considerations of externalities.

There is also a newly-proposed fedidiscovery standard which is intended to support general search and discovery across federated websites. I will need to explore this with a view to ensuring support. The current standard envisages centralised "hubs" which act to harvest data from sites which opt in, and against which other services can then run queries in an optimised way. This would require an additional "hop sauna search" instance and is currently out of scope.

I am due to begin Goal 2 development this month, and have been talking through the availability of APIs and methods for implementation with the kind help of Uchi Uchibeke at Chimoney. There are currently only a small number of financial services supporting open payments, although more will be joining as Interledger-supported projects launch. As I get deeper into this objective, I'll build a list and try assess their level of maturity to include in the developer documentation.

Goal 3 is to keep the deliverable "honest". I have invited a small group of African speculative fiction authors to discuss what a self-publishing "imprint" would require to support creators. It's far too easy to deliver software which solves problems but in ways that are impenetrable for non-technical people to use. When the software can be easily understood and used by this group, then I will know it can do the job. However, their requirements also raise areas where - even with the best of intentions - open payments financial accessibility will fall short. This has surfaced a needed output for the project where I map existing types of creator financial services (auctions, markets, conditional fundraisers, etc) into open payments equivalents, highlighting where services may not yet support implementation. This group will continue discussions till the end of the project with a potential workshop still to be organised at the end.

What impact does the project have on your perception of digital financial inclusion?

Hop Sauna is not intended to reveal or explore problems of financial inclusion, but to build a developer toolkit to support inclusion. With that caveat, exploring implementation does reveal what is still lacking. At this stage, open payments can handle the core transactional requirements of a webshop - one-off payments and subscriptions - but will require intermediaries to support criteria-based fundraising.

There are also interoperability requirements that can limit cross-border payments (or, increase the costs) even with open payments. The Pan-African Payment and Settlement System (PAPSS) is a pan-African initiative which appears equivalent to the EU open-banking approach that has massively reduced costs and complexity for doing banking across Europe. But ... it is fairly new and a long way from full implementation.

Hop Sauna will be released into what is still an immature implementation environment. While mindful of extending inclusion, I also need to ensure that it supports what absolutely will work right now, rather than what might be available in future.

Plus, there are the affordances of open payments which remain as-yet unexplored. Once you can make microscopic, rapid peer-to-peer payments, what types of services or opportunities may yet emerge? Something for our creator group to consider...

Project Impact & Target Audience(s)

There's an awesome patisserie near where I live. They serve incredibly creative confectionaries; each a flavour journey. And it's all vegan.

This isn't something you'd know unless you went looking to find out. The objective of the people behind this delight is show not tell. I'm the exact type of person they're targeting ... someone who would never consider vegan by default, but am perfectly happy to be educated if it comes in an accessible way.

Until there is widespread adoption of open payments in commercial interactions, the opportunity to impact financially-excluded communities will remain notional. Or, until the tea is made where excluded communities are we're not succeeding. Hop Sauna is not a destination along that path, but a key enabler to ensure it is easier for developers to create accessible products which happens to support using open payments by default. My objective isn't to tell developers that open payments makes markets more accessible, but to build a compelling suite of tools that speeds up their development process and supports widespread adoption without open payments being experienced as anything other than a straightforward payments implementation.

Importantly, this is a moving target. PixelFed, the federated photo-sharing app, has announced an intention to develop micropayments support using Web Monetization. This is likely to be the first major, and mainstream, implementation that will hit the fediverse. That massively raises the exposure of open payments, while also surfacing any potential community concerns which I can account for (or try to mitigate) as I develop.

The impact of what Hop Sauna does, and what I achieve through this ambassadorship, will take time and I expect to be held to these objectives over the long-term.

Communications and Marketing

So far, I've kept this very quiet. Sausage-making is not an attractive process, and technical development is not much of a spectator sport. I have written on some initial development considerations and - once I release the first Hop Sauna ActivityPub build - I'll start writing more frequently on what I'm doing.

This will initially be with developers and then, as I get deeper into developing commercial products, with creators and creator communities.

What's Next?

From this month, Goal 2 takes priority till the end of the project, with implementation of open payments and the various mechanisms to create products and methods for payments. A creator should be able to create a product, then associate regional / currency and price data to their product. The software needs to handle refunds, complaints and time-bound price discounts.

I will also - once the demo version is near completion - facilitate a workshop with the authors collaborating with me on the needs assessment.

Community Support

I would appreciate technical code reviews on the template stack (Python/FastAPI and TypeScript/NuxtJS), as well as help with the Open Payments SDK. Also, non-technical, looking for members of cooperatives or creative communities working collaboratively on creative commercial activities, discussing their needs so I can ensure that the template has them covered.

Also, if anyone reading specialises in developing user interfaces at the intersection of commerce and social media and has ideas, as well as experience with Nuxt/Tailwind, please get in contact. I may have some budget to pay for your time to help sort out the frontend interface.

The battle between the Commute and the Community, or the strangeness of online monopolies

Gavin Chait — Sat, 24 May 2025 09:46:23 +0000

If the town where you live was more like the internet, there would be one large department store where hundreds of vendors, all selling more-or-less the same things, would all be yelling at once while waving long lists of customer ratings to persuade you to buy from them. When you go through to pay, the department store - whose employees you never see - would extract anywhere between 30% to 70% of the price as their cut before passing the rest onto the vendor.

There would be no charismatic little streets with cafes spilling onto the pavement, or the bustle of people chatting, laughing and living. Instead, what you'd have is commerce stripped to its essence, "red in tooth and claw".

The challenge for any community recovering from this centralisation is how difficult it is change behaviours when there is no - seeming - compelling reason to do so. Unless something dramatic happens.

In 2020, with COVID, many of us got to experience that change. Amidst the pain, we also experienced a liberation of community. Restaurants spilling onto pavements. Shopping close to home. Living in community. And we liked it. Since then our battle between the Commute and the Community has become polarising and heated.

Gradually, perhaps imperceptibly, this battle has also been coming to the internet through federated, interoperable social media like Mastodon, BlueSky and their ilk. Hop Sauna, my 2025 Ambassadorship, is intended to push this further into the commercial space, recovering our online economic communities.

What does a webshop need to do?

Anyone can launch a new webshop; barriers to entry are low, but barriers to success are enormous.

Any commercial stack must support two key behaviours:

Discovery is the opportunity to find the beings and doings of others.
Delivery is the opportunity to express our being through our doings, or to enjoy the beings and doings of others. To be creative or legitimately acquire the creativity of others.

You can't rely on search engines to help you. You need - in the words of Raymond Ackerman - to "go where the tea is being made". To be part of what people already do.

Engaging with people where they already have community must play well with that community - creators, buyers and sellers, makers and users, readers and writers - and ensure their safety by ensuring:

Simple and ethical rules which apply to all, ensuring diversity, equity and inclusion,
Respect for the privacy and protection of its community,
Protection of its community from force or fraud,
Clear, transparent and fair means of discovery,
Simple and low-cost means of delivery.

An accessible federated stack must also offer:

Simple ways to deploy the same stack independently,
Tools for migration between stacks without losing supporters or anything purchased,
Equal opportunity for discovery across a federated network of equivalent services, subject to adherence to a common set of ethical rules,
Moderation tools to support enforcement of ethical rules, whether the moral subject is an individual, or an entire other server.

Why is federation necessary to compete with monopolies?

Any centralised stack (be it Facebook, Amazon, eBay, Uber, AirBnB or Etsy) offers both discovery and delivery. But, they are also rent-seeking, in that they extract most of the value created by their creators, and do very little to uphold ethical values. Ethics are an expense and, in any case, controversy is good for "engagement".

They're equivalent to feudal landlords, charging their tenant farmers a significant share of what they produce and holding to themselves the right to turf any of their tenants off the land at any time, for any reason, rendering them instantaneously destitute.

Given these online spaces are entirely virtual, how did we get to a place where land is scarce, and landlords can do what they will?

The short answer is that - without ethics, standards and discipline - feudalism is inevitable. Learning why, and how it came to be, is crucial to understanding how to avoid it.

The early internet of the 1990s was a wild place. Along with blogs and early commercial sites were random interactive experiments with a tendency to explode, and lots and lots of porn.

Discovery was largely down to curated lists, webrings, web bookmarks, and search engines. Any of these could be open to spoofing, and so clicking on any link ran the risk of ending up on a porn site, or crashing your computer as some poorly configured website generated infinite new pages.

Yahoo offered curated search results. That's right, early Yahoo hand-curated every link, which scaled about as well as you can imagine it would.

Google arrived with a new algorithmic approach: weighting links by the number of inbound references. Suddenly, for a brief while, you could find things and - with discovery stabilised - delivery could really begin.

Every company started offering their own online shops. With that, they needed to ensure discovery, and the advertising market of contextual links exploded. Unfortunately, so did "search engine optimisation", referral links, and "me-too" sites.

Companies with economic heft could rise above the noise, but small startups had no way through the morass. Enter Amazon, eBay, Bookings and Facebook.

The challenge of selling online is discovery and delivery. If, though, you went inside a gated mall then - in exchange for a significant share of your income - you got protection and exposure.

Twitter and Facebook offered their sequential feed of people and services you were actually interested in by opting in to what they posted. Amazon, Booking, Uber and Etsy allowed you to buy things you could discover using a search engine that actually delivered on what you were looking for.

And again, for a while, that worked. But exploitation soon followed.

As before, the problem is "noise" which includes spam, chum, fraud, and hate speech. Worse, creators are deliberately trapped. Whether by relying on centralised systems of discovery (Google, Facebook, Twitter, Instagram) or delivery (Amazon, Uber, AirBnB, Etsy), where do you go?

The noise of enshittification really took off with the acquisition of Twitter in 2022 and an opportunity arose from IndieWeb's POSSE (Publish (on your) Own Site, Syndicate Elsewhere) philosophy when Mastodon's ActivityPub implementation took off.

Federation means that interoperable websites share a common way of communicating and sharing information. You can finally discover and curate a community. More importantly, federation returned moderation decision-making to small communities.

The rejoinder from the centralised stacks is that Mastodon is tiny, so why would you bother, but that's a bit like complaining that your favourite coffee shop only seats 20 while the huge department store can accommodate millions. Is that what you want from a café?

And so that is the task before me as I continue to build out Hop Sauna. A webshop that not only uses the open payments protocols to reduce the costs of exchange, but also offers communities an opportunity to moderate themselves while not losing the opportunity to be discovered.

I would love to hear from you … what features and requirements do you have from a community-moderated and federated webshop?

Hop Sauna, a social marketplace framework - introduction and roadmap

Gavin Chait — Sun, 13 Apr 2025 13:51:58 +0000

The online new is no longer absorbed into society with the unquestioning rapture of the 1990s. Neither should it be, especially when it comes to new ways to make and receive payments.

Low-cost, low-fee transactions are not a "solved" problem in federated online communities. Every community server raises funds using PayPal, Patreon or various other "tip" portals rather than integrating payments directly into their systems, forfeiting significant fees along the way. Creators still sell on Amazon, or other centralised portals, while promoting their work via multiple social channels. And little of that is available to creators working and living in the global South.

Nothing here is connected or integrated. All of it costs more than it needs to.

The logic of open payments is that instead of every website using the extensive banking infrastructure of credit cards and an authentication process involving multiple fee-charging intermediaries, payments are instead made via interoperable digital wallets. Individuals manage cash in and out of their wallets in whatever ways their service-provider supports.

The protocol for interacting with these wallets uses the open payments architecture, and each website must then manage interaction with these APIs. That often involves a lot of duplicated boilerplate code, not just at the transaction level, but also in defining and managing products and fees, authenticating payments are received, and then acting on that authentication.

This is tedious even with mature and well-documented payment libraries, but in a new protocol can be confusing, frustrating, and a barrier to adoption. Such barriers - if the incentive is sufficient - often produce new centralised intermediaries to act as an interface to that complexity. Best to get in early with an open source alternative.

The purpose of the Interledger Foundation Ambassadorships is to support early-stage efforts at building bridges into the adoption and use of the open payments protocols. My Ambassadorship is all about enhancing accessibility to a technical protocol that most shouldn't need to know about to experience value from it.

Putting new payment systems into use is less about telling people, than putting it where they most need it as simply as possible.

My project, Hop Sauna, is an open-source template stack ready for custom development of community-moderated Open Payments-enabled web shops, including a base server and client, with documentation, to support rapidly creating new types of federated commercial social applications.

My technical deliverables are:

Open Payments web shop template stack.
Open Payments Python SDK and template components.
A dedicated documentation site for the template.

The first step along the way is a base template stack, which is already available for use, along with all the documentation required to develop and extend it.

This foundation will become Hop Sauna, which will integrate the Open Payments API, along with full digital product and purchase management. The objective is that sellers add their wallet / API keys and then the stack manages everything for them:

Digital product creation, registration, and pricing (including multiple currencies),
Purchase process between service providers (wallet services) for seller and buyer,
Payment authentication and administration for the seller,
Digital product distribution for the buyer.

The template manages an exchange, authenticates that exchange and then approves distribution. The specific nature of what is distributed, and how, is a factor for the developer to build. It is their unique "product". Developers will not have to implement any part of the product or payments process.

Effectively, it will be a foundation to many of the required coding challenges in the server and client, permitting standardised exchange of digital goods.

Towards the end of my Ambassadorship, I will begin looking to the next phase of my work, which is ensuring that the stack supports the needs of creators. I will run a small creator's workshop where collaborators will discuss their particular requirements and allow me to ensure that the stack is able to fulfil these needs.

If you want to get involved, I will need code reviewers, and - especially for the open payments SDK - technical collaborators to speed up development.

If you have any questions or suggestions, please get in contact.