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.
Top comments (0)