Treaty: A Data Sharing Service (Experiment)

2023-06-25

This post talks about the background behind Treaty, a data sharing service experiment I made public on Github on June 24.

I won't go into details explaining implementation behind Treaty in this post. I plan on putting most of that information into the manual in the repo at the previously mentioned link.

Background

Treaty was born out of an offhand joke when Mark Zuckerberg was forced to testify to Congress about the misuse of customer data in 2018. As a data developer I joked: "Why doesn't Facebook just give me a SQL login to their database so I can actually see what data they have about me?"

Motivation

That is the original thesis behind Treaty: can we empower application developers who want to give their application data back to their users? Of course, software developers who write applications who believe they have their users interests don't need a specialized data API to do this: they can simply just give their users their data through the application.

I assert that giving users their data is often an after thought at best for application developers. Application developers want to write applications. And for application developers who care about their users, they often will simply open source their code with some open license and call it good.

This is also to say that application developers who don't open source their work don't care about their users; it's simply just an after thought at best. For this I point to the trajectory of certain large websites in the last 20 years such as Twitter and Reddit. I don't believe that the original intent was to try and firewall user submitted content; the idea was to simply build an app that solved a problem that delighted users. It's only after a certain inertia is reached that developers have to work their way backwards from an app idea to reverse engineer a business model. And then the current phase of "enshittification" begins.

What is data anyway

To the average user I assert that data is an abstract concept. That abstractness leads to the current problems on the internet today. When I say "abstract" I mean the same kind of emotional response people have to say, math. Everyone understands math is important, but it's also very abstract: you don't see math, you can't touch or taste it.

But you can see a website, or an iPhone or whatever. Thus you're not inclined to question what you're doing with the product because the product is delighting your senses: it looks cool, it gives you the sense of feeling connected, or whatever. So data is an afterthought.

People care about data however. From what I've been able to gather online, it's obvious that people know that their privacy is important, but because data is such an abstract concept to people, it's hard to understand how to handle it. My grandma isn't going to teach herself SQL; but she understands that she wants to have authority over her information: who knows her birthday, and so on. More importantly, people are willing to allow companies to leverage their data in return for better user experiences. If companies can demonstrate that they are good stewards of their customer's information, customers will reciprocate. There is also the idea of data cooperatives, which I also support.

Of course, the problem is that once a company violates that trust, there isn't any recourse for users typically. There have been attempts to solve this, usually via legal frameworks: the CCPA and the GDPR. To be clear, I think these are good things.

Alternative timelines

I recently have spent a lot of time thinking about the internet and alternative timelines for the internet; what I have jokingly called "Web -2.0". What if companies hadn't taken forefront of internet development; but instead public foundations? In other words, what if PBS had built Twitter? Would the internet have been the same?

Of course, this was never going to happen, because in order for things like that to happen requires money, and public foundations aren't funded enough to do these kinds of things.

Treaty's goals

With all of this context out of the way, the point: Treaty is intended to provide a technical framework for application developers to empower users of their application to have their data. The target audience for Treaty is then application developers.

The problem is of course no one from the user side of the application has a firm grasp on data. No user is going to teach themselves SQL to learn how to keep their data, at least not the majority of them. Still, I hold the belief that we should start with a practice and a pattern. If there is a pattern and a practice, I assert that there will be tools built by product people to empower users to better grasp and utilize their data: we just need to give it to them first. If you build it, they will come (hopefully).

I realize that this last statement is a wish and not a plan, which is why I continually label Treaty itself as an experiment.

Ideas are infinite, but time is not

Making Treaty public last weekend was actually driven by a bit of anxiety. I had been working on Treaty for the past year (this implementation) and am in the process of trying to clean up the polish and shine of the project from a haphazard proof-of-concept into an actual product that will work for people.

That anxiety has persisted for the past year, and realistically the idea for Treaty over the past five years. This has taken a lot of my free time outside of work, and I am going to have to slow the cadence down with this in order to sustain some sanity. I have joked that developing Treaty for myself has been Anxiety Driven Development; where I am interested in manifesting the idea on the screen (via working code) first rather than sitting down and examining non-happy path situations. I am going to change that.

For the moment I am hoping to try and dedicate a few hours a week, and a full weekend (cumulative, not as a specific date) each month to trying to make this work.