Trading on the Fediverse

Move your thoughts đź’­ Ideas
, ,
#1

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.

1 Like
#2
#3
#4

Epicyon is not a bad platform to consider. Several issues would need to be addressed with any fork however, such as the current marketplace only interoperating between instances that must each opt-in - currently, the marketplace does not federate with anything but other Epicyon servers without those whitelisting steps being taken on both/so sides, without which, the marketplace is merely a lovely walled garden on a local server instance that by design can only accommodate a very small handful of user accounts.

  • Integration of payment gateways is pretty much a requirement for the initiative to succeed, IMO.

  • Constructs can consist of things like BTCPay with Monero (XMR) support, Stripe integration, etc.

  • Without a way for the consumer to actually engage in the act of commerce and the exchange of funds in the transaction, through a method the vendor has enabled, I see little point.

  • Mitra is an excellent example of how this works cross-platform in the Fediverse with it’s subscription model - a remote user wants to subscribe to an author’s syndicated publications, they sign up for the subscription including their Fediverse address in the form @JoeUser@hostname.SLD.TLD and they receive their invoice via DM to their Fediverse inbox.

  • Integrating say, Stripe, for the users who decide to become vendors vendors allows even non-Fediverse users to purchase the vendors goods and services. You can borrow logic and cutter for this from numerous sources including many existing WHMCS modules, or Stripe itself.

  • I believe Soapbox/Rebased is working on federated marketplace deployment at this time (it’s already deployed event management that fully federates with Mobilizon), but that’s not Python, and neither is Mitra (Rust), but they can provide excellent examples for potential models you can use.

  • Being able to make a post about your product or service that can be seen over the Fediverse is critical to the success of the vendor themself, if no one is aware that they have something to offer then no one will purchase it. Once users come to visit the user profile and are provided the location of their marketplace store it can be browsed, and anyone can buy their business products and services.

  • Other modules for payment gateways or methods should also be considered and developed as options for the vendors that they can activate as plugins - much like Friendica and Hubzilla offer the instance (or hub, respectively) admins globally, or simply independently by each individual user - one click and the module could be activated for their store.

  • Aside from Epicyon, you might also consider forking TakahÄ“ for this project of yours - it’s Django, so you’re in familiar ground there with Python, and there are many commerce solutions available already for Django projects and it would be relatively simple for you to build some from scratch as well, relatively speaking.

I think your idea is a valuable asset very much needed in the Fediverse and Privacy Respecting ecommerce solutions are severely lacking in this horizontally scaling, non-silo predicated, ActivityPub powered network we call the Fediverse :slightly_smiling_face:

On another note, you shouldn’t need to depend upon a grant and wait until there’s an award to move forward with s guys idea that’s will obviously reward you itself with paid compensation itself if you build it. I’m just thinking out loud there, but it’s kinda stating the obvious.

Just my 2¢

:sailboat:

.

#5

Thanks for you comment, especially the references to existing projects is very helpful. Could you give me a link to the Takahe and Mitra projects?

Integrating Payment Providers

On the topic of integrating payment providers, I’m concerned that the integrating any set of payment providers will reduce the accessibility of the entire software.

Integrating a crypto payment system is controversial in-and-of itself and I’m also doubting whether the effort required here would be worth the development time needed to implement it.

And other payment processors, such as Stripe, PayPal, Klarna, Direkt all have the problems of accessibility and privacy. Most of these systems are only available on certain markets or for certain currencies or for people with a bank account, credit card etc. And while it is completely legitimate for a single offer to restrict buyers to use a specific payment provider, doing so at a software level is very restrictive if not patronizing. If I only implement a subset of all existing payment providers (e.g. Stripe and not AliPay), I’m telling people from those places that my software is not for them.

Instead my idea is to allow for offers and invoices to include “payment details” as opposed to using a payment provider - such as an IBAN, PayPal username, address to send money to, etc. There are quite a few privacy-focused services that already use this approach, for example ProtonMail and Nitrokey. This would also allow people to use an instance of this software without ever running non-free software on their own devices, as for example authorizing a bank transfer can be done without using online banking.

It certainly will not be part of the grant to implement support for any of these payment processors. If this project grows, I’ll be considering the possibility to add payment provider options.

#6

Yes indeed!

Here’s a complete write-up on Takahē that I recently published:

Also, you can find Mitra at:

Good luck with your project and I really think you’re on to something here :slightly_smiling_face:

#tallship

:sailboat:

.

2 Likes
#7

I’m just looking through the code of Takahe and must say that I like the code very much. I think I will use that as the basis for this project. Either as a soft-fork or by merging the changes into Takahe itself (less likely).

2 Likes