Howdy Web Monetization Friends,
We're back with a fresh update. TL;DR: we're gonna go on a (figurative) summer engineering road trip to take our project outcomes on a little detour. Less Thelma and Louise going off a cliff and more Blues Brothers jumping the bridge.
A quick refresher – the goals of our project were to:
- Design a workflow that builds on the Web Monetization protocol
- Upgrade the Permanent API to support that workflow
- Build a simple demonstration application that uses the protocol to store content
- Document everything
- Improve understanding of ecosystem gaps
While we have made significant progress on these goals in the allotted grant period (so far), our investigations and prototypes revealed an opportunity to significantly extend the impact of our work.
However, doing so will require us to first take a little roadmap detour in our core product at Permanent.org. That will require more time to get it done right.
In a fortuitous twist of fate, we chose to build an Etherpad extension as our demonstration application. I've written about the logic behind that choice in past posts.
We believed that building on Etherpad was a solid win-win opportunity for the Permanent.org feature set as well as to the open source ecosystem.
However, the real win-win was that we could get away with using Coil even though it's not designed for a file storage use case like ours. We didn't quite realize that about Coil at the start of this journey, so it was a nice coincidence.
Why will Coil work for Etherpad? That's because Etherpad files are vanishingly small. Even though Coil payments are proportional to the time spent on site and not proportional to the total data transferred in a given session, the small Coil payments cover the small costs of typical Etherpad files.
So, since Coil can sufficiently cover the cost of pad storage, the simple Etherpad plugin concept we cooked up has real potential to be a fully viable web monetized feature in the Permanent.org app as well as an extension that could be used with any Etherpad instance in existence. Yay!
However, there’s a catch.
If we only wanted to web monetize an Etherpad instance hosted on a Permanent.org server, we'd be done. However, the beauty of Etherpad (vs. walled garden, privacy vacuum products from the internet giants) is that there are instances hosted all over the web.
Don't trust Permanent.org? No sweat, use the riseup.net Etherpad instance instead (which we have been doing for over a year ourselves actually).
However, in order for an Etherpad instance hosted on a server that is not in the Permanent.org stack to make a successful data transfer to Permanent.org for storage, we have to make some critical improvements to our authorization and authentication infrastructure.
These improvements go well above and beyond the anticipated API improvements scoped out for this project and would change how our own microservices communicate with each other as well.
We want to do this work and we need to do this work. It's good for Permanent. We also want to do it under the banner of Grant for the Web and stick around in this great community.
Therefore we will be working under a no-cost extension to give us ample time to upgrade our auth and publish a fully supported, web monetization extension to Etherpad.
We'll keep you posted while we make these important improvements.