The following is an excerpt from a funding request I have submitted to the NLnet foundation under their Open Call, which relates to an idea that was inspired by the discussions taking place here. And which I would like to debate, improve and refine in this forum.
Abstract
My goal is to create a federated online shop. For this purpose I will implement an ActivityPub-compatible Python Server or fork an existing server and extend it.
Users will be able to offer products for sale at a set price. Others (either from the same or another server) can then accept these offers to indicate they wish to buy it.
Delivery is the responsibility of the seller. The seller creates an invoice object containing all relevant information (delivery date, payment details, name, tax, etc.) and sends it to the buyer via an ActivityPub Create activity.
Users will be able to interact with the Server through a Web interface, implemented with the ActivityPub C2S protocol.
As part of this funding I will set up and operate a first instance for a year and a staging server for testing new developments.
Payment processing is not a part of this software. Servers may fund themselves by charging a fixed monthly amount from shop owners, but no fee as a percentage of a shop’s revenue will be implemented by myself or merged into the codebase when implemented by others.
Comparison to earlier efforts
The Fediverse (the collection of federated servers and people using them) has for the most part not been focused on trading activity. The closest service on the Fediverse I could find was epicyon, which contains support for bartering and gift giving. But I have not found any effort yet to use ActivityPub or another federated protocol, for trading activity.
Major Challenges to the development
This project has two major challenges.
I need to extend an ActivityPub server and document these extensions. I may use the schema.org definitions of Product, Offer and Service, but an extension of the ActivityPub actor fields is unavoidable in my consideration.
As the potential for harm on a shopping site varies and sometimes exceeds the potential harm done through a social network, I must develop additional moderation techniques to those deployed on the Fediverse today. Every instance must provide information about it’s operator, their name, jurisdiction and address, so that this information can be used to make a moderation decision and potentially sue an operator.
I will also implement an option for moderators, to require manual verification for every new instance that wants to federate with them. I hope they use this option to research the claims of an instance operator with regards to their name, jurisdiction, etc. and not federated with dishonest instances.
Ecosystem
The first instance should serve as a Proof of Concept to the operators of existing Fediverse services (e.g. Mastodon, Pleroma, Pixelfed) and inspire them to setup their own instances.
As the goal of this system is to give control of a market back to it’s participants, I can also imagine sellers- or buyers-cooperatives setting up their own instances. But this will only take place when a few instances have proven the viability of the system.
I will create a Fediverse Enhancement Proposal with the changes I implement during this project.
See: socialcoding