A lot has happened in my mid-level grant project since the interim report!
Linking from Solid WebID's to Payment Pointers
In the interim report, I already described how payment pointers can be linked to Solid identities, both at the linked-data level and at the Solid OS user interface level. There are several other projects that link Solid with Web Monetization, and we set up a coordination repo for this.
We had originally proposed a linked data predicate in the paymentpointers.org namespace, but this has since gone through some revisions, so we are now proposing it in the interledger.org namespace, and will coordinate between the various Solid-related projects to all use the same predicate, so that we become compatible with one another.
Ponder Source
In the meantime the grant has helped my one-person side-project to scale up to a 2.2 FTE post-growth non-profit organisation called Ponder Source.
In May, I participated in a blockchain startup accelerator and learned about post-growth business models from Melanie Rieback (do watch her TED Talk!).
We copied most of the business model for Ponder Source from Radically Open Security although we don't donate our profits to a foundation that is external to us; instead, we "earn to give", meaning we mix profitable projects with pro-bono projects in such a way that our long-term profits will forever stay at zero.
One alternative we did seriously consider, and which I think would resonate with many teams here, is the coop model, where the workers own the value of the organisation. Although I think the coop model does make sense in many other situations, in our case we as project team members wanted to reduce ourselves to just employees of the project, and although we are proud to build up a history with the Ponder Source project together, and we will take our responsibility as stewards of Ponder Source, we will not build up any legal ownership of it.
Ponder Source is now officially registered as a foundation in the Netherlands, and the fact that we got the grant money up-front helped us bridge the first months where we set up our bank account, waited until our first paying customer paid their first invoice, and then paid our own salaries for the first time. As money comes in, we will grow organically, and bootstrap to grow the workload and the team size in parallel, without ever taking any outside investment.
The mission of Ponder Source is to develop and publish open source software that helps build the internet of value in a post-capitalist way.
Federated Bookkeeping
The Interledger network allows us to send money to our suppliers. But there is more to economic collaboration than payments, and the Interledger protocol also foresees not only sending money, but also sending data.
In the world of classic enterprise software, data sent back and forth between suppliers and consumers is (roughly) standardised into a number of business document types - the most well-known of which is the Invoice, but other business document types are for instance the Purchase Order, Delivery Note, Request for Quote, etc. In the 1980s vision of the Paperless Office, exchanging these documents was known as Electronic Data Interchange (EDI). Nowadays, it's more often called e-Invoicing.
At a higher level, given that each economic organisation has some sort of internal bookkeeping system (even if it's just an Excel sheet), we can think of these messages as connecting these bookkeeping systems together, so that they stay sovereign over their own copy of the data, but at the same time become connected, so that more real-time data can be exchanged.
By exchanging more data with your suppliers and consumers, processes can be automated more granularly, and the transparency can lead to more efficient cooperation.
In Adam Smith's classic model of economics, the economy is coordinated by the 'invisible hand' of the free market. Advertising creates the demand, and price signals push back the inefficient production paths, so that the more efficient production paths automatically prevail.
But a price signal is only a one-dimensional number, and cannot encode conditional data. For instance, in federated bookkeeping, a shop may allow a supplier to act on their live records of what is in the shelves, and which items need to be refilled.
With more real-time and machine-readable transparent data exchange between the information systems of suppliers and consumers, an automated truck routing algorithm may optimise the delivery based on live information from the shop, from the warehouse, and from the production floor, combined with live traffic data and the truck driver's availability, to optimise when to drive to a given retail shop, and which shops may still have enough stock.
Such an inter-organisational information system can collectively save petrol and effort by making smarter but less frequent deliveries, but it can only work if a robust messaging layer provides reliable real-time data.
Since information can always be copied, and read access is not always intended to be transferable to others, another aspect we will need is machine-readable non-disclosure agreements that indicate which pieces of information may be shared with whom. That way nodes in the federated bookkeeping network can feel more confident that the data they share with their direct neighbours only goes to the nodes that need to see this information, and stays contained in a small network region.
We have set up a weekly brainstorm session around this topic, where we from Ponder Source get together each week with a pretty random group of experts from Solid, from the blockchain world, and from the CRDT world.
In the coming years, we hope to research federated bookkeeping and automated service provisioning on Codius - for instance how to fully automate the hosting of web-monetised content on Codius hosts.
402s
The 402 Payment Required http response header has existed for a long time, but it is not used very often. As an experiment, and as a final work item within my mid-level grant, I implemented this header in node-solid-server, the oldest existing and most well-known implementation of a Solid server.
One question to overcome was how the content uploader can tell the server that a certain resource is for paying agents only. For this, we invented the acl:PayingAgent agent class, which can be used in Solid's access control list documents, in the same way as acl:AuthenticatedAgent predicate.
If this predicate is used, and if no other rules exist through which a non-paying client would have access to the resource, then non-paying agents see a 402 Payment Required response, accompanied by a Pay header that indicates an Interledger account and a shared secret, that is specific to that user, and to that URL.
I didn't add any Interledger code to the server itself, but it checks with an oracle server that would handle the payments, and keep track of the guest list. For each request where paying would help, node-solid-server consults with this oracle to check the guest list for that specific resource.
If the user (whose WebID is encoded in the Authorization request header) has paid for that resource, then the oracle responds with 'ok' and the resource is served as normal, with a 200 OK http response header.
Joep and I discussed this architecture, and agreed that a 'tickets' system might be nicer for some use cases, but because Solid does not (yet) support access based on verifiable credentials, I thought that this 'guest list' system was a nicely simple alternative.
Apart from implementing this functionality in node-solid-server, I added tests for it as an optional module of the independent Solid test suite, of which I'm also a contributor.
A big thank you!
Thanks so much to Mozilla, Coil, this community, and everybody else who made this possible, I really enjoyed the opportunity to do this kind of ground-breaking blue-sky exploratory research around internet and money. It really helped me bootstrap various ideas which I would otherwise not have been able to explore. Hopefully see you again in the coming years, with more exciting projects to come!
Top comments (0)