I have registered the domain paeony.org and pointed it at an empty github site as a tiny baby step in investigating a question of interest to me - what would it take to make it falling off a log easy to create an open ecosystem web of interconnected, monitizable, services that run on user’s devices?
I previously talked about updating the web for modern assumptions. I’d like to take those ideas a step further which is where Paeony comes in. Paeony’s first goal is to identify the pieces needed to build the modern web. The next goal is to find as much existing open standard/open source technologies that provide those pieces. And then, if and only if some key pieces are missing, Paeony will try to fill those gaps.
To start with lets talk a bit about requirements.
Money
I want people to make money. As I also talked about recently, I think the current Ad based/Feudal model has not been a healthy one for an open web. I’m not completely sure what is supposed to replace it but I’m pretty sure it involves paying people to produce software. In other words, users have to be customers, not the product. So whatever stack the modern web is built on, it has to allow people to charge for software.
We also need an easy, low cost, simple, robust way for people to charge money to their users. There are a variety of mechanisms out there but they all have issues, we need to see what we can do to make it as easy as possible to collect money. There is a ton of work going on here, but I don’t know if any of it has reached a point where it’s robustly usable.
I am not super happy with listing money first but I am trying to be honest with myself. If you can’t make money you don’t get to live so money has to be front and center.
Identity
I want a web damn it. A collection of lots and lots of services on lots and lots of devices written by lots and lots of different folks. I don’t know how to do this for all but the most trivial scenarios without an identity ecosystem. All those services on all of those devices need to decide who gets to do what and those authorization decisions are first and foremost driven by identity. Furthermore we need an identity system that users can bring with them. If I have to recreate all my relationships and identities for each and every service I run I won’t run many services. We therefore need a standard on the devices for how all devices can hook into the same identity infrastructure and for how these identities are shared between services/devices. How are identities discovered? How are they synchronized between a user’s machines? How are they revoked? How are they recovered? How can this be done and uphold a user’s basic rights?
Data
If we are going to build this modern web of services then there has to be some natural way to keep data straight. If a user is running one microblogging app on their tablet, another on their phone and a third on their PC how do all of these apps agree with each other as to what the user has posted and in what order? In some cases application protocols can handle the coordination but I strongly suspect that in many cases having a standard for how to synchronize semi-structured data between devices could enable a lot of interesting applications. This implies both standards at the network layer for how to handle both eventually consistent and highly consistent data as well as standards within devices for how apps on the same device can easily share data with each other. And then of course we have to figure out how to scale this up so that arbitrary user’s services on multiple devices can coordinate data with each other. Lots of interesting work here.
Browsers
The sine qua non of the web is the browser so if this ’modern web’ is going to exist then it has to run in the browser. What APIs, permissions, extensions, management interfaces, etc. do we need to enable folks to write services that are downloaded and managed directly in the browser? If we can have HTML apps we sure as heck can have HTML services.
Conclusion
There is a ton of work to do. We need network layer protocol standards, device layer API standards, reference implementations, etc. Paeony is about trying to identify as much existing work as possible that can handle these tasks and then filling in any gaps that are left. I have absolutely no clue if all of this leads anywhere but I intend to find out.
2 thoughts on “Welcome to Paeony”