Last week, I shared an overview of the challenges and goals of Retribute as a project.

I purposefully avoided diving into more technical aspects to keep the writing accessible, and because it wasn’t actually required in the post.

However, Retribute will involve some technical solutions we need to discuss and build. This is the goal of today’s blog post.

Meet the square

Retribute is designed around four entities:

  • Creators, such as musicians, writers, photographs, or simply people posting on social media who produce content
  • Content platforms, where this content is published by creators, e.g Twitter, YouTube, Mastodon, Funkwhale, a personal website or blog, a book, etc.
  • Contributors, who consume the creator’s content on the content platform and retribute the creator on a contribution platform
  • Contribution Platforms, who gather contributions from contributors, and forward those to creators, e.g PayPal, Patreon, Liberapay, the creator’s bank, a Bitcoin wallet, etc.

Their relationships are outlined in the schema below:

graphviz-937f72b5b1df5874ad1a2549c5ab2468 digraph square { node[width=2 height=1 ] Creator[width=2 height=1 shape="diamond"] Contributor[width=2 height=1 shape="diamond"] Creator->"Content Platform"[ label="Publication" len=2]; Contributor->"Content Platform"[ label="Consumption" ]; Contributor->"Contribution Platform"[ label="Contribution" ]; "Contribution Platform"->"Creator"[ label="Contribution" ]; {rank=same; "Content Platform" Contributor ;} {rank=same; Creator "Contribution Platform" ;} } square Creator Creator Content Platform Content Platform Creator->Content Platform Publication Contributor Contributor Contributor->Content Platform Consumption Contribution Platform Contribution Platform Contributor->Contribution Platform Contribution Contribution Platform->Creator Contribution

In order to automate contributions, Retribute must answer these questions:

  1. Who? Who are the creators a given contributor should retribute?
  2. What? What is a suitable contribution for each creator?
  3. Where? On what contribution platform should the contributor send the contributions?

And it must answer those questions with minimal or no user interaction.

To do so, Retribute assumes contributors use a dedicated app, also known as a Retribute Client, to abstract the complexity of answering those questions from the user.

A Retribute Client can be a web application, such as app.retribute.me, a mobile app, a desktop app or any other piece of software that leverage Retribute standards and protocols.

In the next part, I will describe the behaviour of a typical Retribute client and how it answers to the questions outlined above.

Who to compensate?

To answer this question, a Retribute client leverages the consumption history of a given contributor on a content platform.

This consumption history could be the viewing history on YouTube and PeerTube, the likes on Facebook, Twitter and Mastodon, the listening history on Funkwhale, SoundCloud and Spotify, etc.

By aggregating the consumption history of a contributor over a period of time, the client can obtain a list of creators whose content was deemed interesting or relevant by this potential contributor.

The client needs access to this consumption history to provide meaningful suggestions. This history is usually stored in one form on another by content platforms, who typically use this data to power their own recommendation algorithms, or other features.

Yet, each and every platform use different data models and APIs, so it’s not realistic to implement compatibility for all platforms out here.

Because of that, one part of the Retribute project involves building a small standard for content platforms to expose this data. With such a standard, Retribute clients wouldn’t need to implement support for each content platform.

What is an adequate contribution?

Once the client has this list of creators, the next step is to determine the ideal contribution for each creator.

One way to do that is to compute a weight for each creator, based on the volume of content consumed, and suggest a contribution amount based on this weight.

Let’s take a concrete exemple, based on the consumption history of Alice:

  1. Alice bookmarked a post published by Julia on her blog
  2. Alice favorited a post published by Bob on Twitter
  3. Alice liked a video published by Romain on YouTube
  4. Alice watched a video published by Julia on PeerTube
  5. Alice liked a post published by Bob on Facebook
  6. Alice liked a video published by Julia on PeerTube

The most simple approach is to take each creator, and simply increment its weight whenever a row associated with this creator appears in Alice’s history: ;p

  • 2 entries are related to Bob, so Bob’s weight is 2
  • 3 entries are related to Julia, so Julia’s weight is 3
  • 1 entry are related to Romain, so Romain’s weight is 1

The cumulated weight of all creators is 6.

Now, assuming Alice’s budget is 12€, the client split this amount into shares, using this formula:

single_share_amount = budget / total_weight

With a budget of 12€ and a total weight of 6, the amount of a single share is 12 / 6, so 2€.

The last remaining bit to obtain each creator’s share is to multiply the amount of a single share by the weight of the creator:

Creator Weight Share
Bob 2 4€
Julia 3 6€
Romain 1 2€

The client can use those amounts as contribution suggestions for Alice.

Please note this is only one way to split a budget, and described for illustration purposes. Retribute doesn’t enforce this in any way, and different mechanisms could be implemented by Retribute clients.

Where to send the contributions?

To complete the cycle, Alice needs to send her contributions to the creators. Finding out the preferred contribution platforms of each creator is usually a manual and error prone job, because content platforms don’t expose this data in a structured, standard and consistent way.

Without a Retribute client, Alice would have to browse manually each creator profile, looking for links to contribution platforms such as PayPal or Liberapay.

Doing this manually doesn’t scale beyond a handful of creators though, so one of the job of Retribute clients is to collect and display links to contribution platforms without user intervention.

As said earlier, there is not standard way to do that. However, we can still extract automatically a lot of information from creator profiles: a lot of contribution platforms are available on the web and creators include links to those pages into their profiles.

Thus, clients can crawl creator profiles and extract links to known contribution platforms, or delegate this work to a server (app.retribute.me is doing the latter).

But not every contribution platform info can be extracted this way. While we can easily write regular expressions to extract link to Patreon or Liberapay profiles, supporting IBAN, cryptocurrencies, or any other decentralized contribution platform, such as Transpay isn’t easily doable and likely to yield invalid resuls, or miss valid ones.

In complement of crawling and data extraction from creator profiles, which can already be achieved without coordinated effort, part of the Retribute project will involve building a small standard to expose contribution platforms information in a structured and meaningful way.

Summary of the Retribute client workflow

To summarize, a typical Retribute client will perform the following operations:

graphviz-944da8d3a1a70fef4e6bf5c5f1b4603b digraph client { PeerTube[shape="diamond"] Twitter[shape="diamond"] Mastodon[shape="diamond"] Funkwhale[shape="diamond"] PeerTube->"Retrieve consumption history" Twitter->"Retrieve consumption history" Mastodon->"Retrieve consumption history" Funkwhale->"Retrieve consumption history" "Retrieve consumption history"->"List of creators" "List of creators"->"Weighing" "Weighing"->"Contributions suggestions" "Contributions suggestions"->"Retrieval of contribution platforms" "Retrieval of contribution platforms"->"Redirection to contributions platforms" } client PeerTube PeerTube Retrieve consumption history Retrieve consumption history PeerTube->Retrieve consumption history Twitter Twitter Twitter->Retrieve consumption history Mastodon Mastodon Mastodon->Retrieve consumption history Funkwhale Funkwhale Funkwhale->Retrieve consumption history List of creators List of creators Retrieve consumption history->List of creators Weighing Weighing List of creators->Weighing Contributions suggestions Contributions suggestions Weighing->Contributions suggestions Retrieval of contribution platforms Retrieval of contribution platforms Contributions suggestions->Retrieval of contribution platforms Redirection to contributions platforms Redirection to contributions platforms Retrieval of contribution platforms->Redirection to contributions platforms

In theory, a Retribute client could even go further and automate the act of payment for supported platforms. Because payment, and especially automated payments are hard to implement, this is not part of the initial effort.

What’s next?

If you read until here, you noticed I mentioned two small standards we need to design as part of Retribute, to:

  1. Retrieve consumption history data from content platforms.
  2. Retrieve contribution platforms from creators profiles

We can already extract meaningful contribution platform data without #2, so #1 remains the top priority.

About app.retribute.me

In parallel, developing a working Retribute client that will implement the workflow described above to assist end-users and offer them meaningful suggestions is also needed.

This client will act as a reference implementation, a sandbox to try out those new standards and a showcase of the progress we’re making. It will integrate the latest available versions of the standard to discover potential limitations and issues as early as possible.

app.retribute.me will also focus on offering a privacy-respecting experience to the user, by not involving a server at all, except to retrieve contribution platforms data from creators profiles.

As of today, all credentials are stored in the user’s browser, and the source code can be audited here.

The app contacts https://api.retribute.me, which, given a list of creator profiles URL, will query, extract and return contribution data to the client. The source code for this API is available here. This work is done server-side to increase performance and cachability of data, and reduce client-side complexity.

Both the front-end and the API are free sotfware that can be deployed elsewhere.

Conclusion

I hope you now have a better overview of the technical problems Retribute aims to solve, and their corresponding solutions.

I am looking for individuals willing to help with the standardization process: I’ve never written a standard myself, and although I’m willing to coordinate the work if needed, I can’t be the only person working on this.

If you are interested, please contact me on Matrix, by email at contact@eliotberriot.com or on the Fediverse, as eliotberriot@mastodon.eliotberriot.com.

Credits

Thanks to emsenn and everyone else who discussed, proofread and improved this document!