Rough Proposal: ANS-108 / DataOS

DataOS

Since the day I heard about DataOS, I have been subconciously thinking about what it means and how to get there. There's really been two things eating at my subconcious lately (when I'm not thinking about https://twitter.com/permafacts):

  1. DataOS
  2. ANS-108

I think they're meant for eachother, but there's 1 piece missing and I'm hoping the We the Arweavers can get there.

You can read more about DataOS and ANS108 at the links above, but here's a tldr.

DataOS is an interface built on top of an open data lake (Arweave Permaweb), and could completely replace all "apps" as an OS. A user should be able to speak to DataOS, and the OS will generate a user interface ON THE FLY that the user can interact with.

For example:

User: "Show me all of the houses for sale in San Diego."

DataOS: ~Finds houses for sale in San Diego and "renders" them for the user.

The user should also be able to say "I don't like these displayed as tiles, could you display them as a list?" and DataOS should update the experience for the user. When a user "likes" an experience, they should be able to "bookmark" (maybe stamp?) that experience so that DataOS can provide experiences the user likes in the future.

ANS-108 (render-with)

This standard is one of my favorite standards as I believe it starts a "race" to create the best "renderers". The concept is simply "When deploying a transaction to Arweave, specify how the "data" in the transaction can be renderered using the tag "Render-With".

Render-With should point at one of 2 options:

  1. TX_ID: A transaction ID of a renderer that can render the data. (eg. "Render-With": "BKCKJSX6WwMln0c8FcJ2voDoNn0ztc1sM8GTKuVsmhs")
  2. ARNS: An ARNS subdomain. (eg. "Render-With": "fact-renderer")

The above TX_ID is the transaction that fact-renderer ARNS name points to and can be referenced either way, but if I use the ARNS name, I can change that transaction ID when making improvements to the fact-renderer.

This is great, and it works well! There are a couple renderers out in the wild already!

Rough Proposal - Renderer-For

In thinking through a basic MVP for proving out DataOS, I ask myself "What does DataOS need to perform a task?". I have come up with this so far:

Let's stick with the "House" example to stay consistent.

DataOS needs:

  1. User Query: "Show me all the houses for sale in San Diego"
  2. Data-Structure ("Content-Type"?): house
  3. Renderers: "Renderer-For": "<content-type>" (eg. "Renderer-For": "house")

DataOS gets query then queries arweave for **houses** then queries arweave for **house** renderers then generates a UI for the user.

At this point all we have to agree on is what a standard Data-Structure for a house is. Here's a simple example JSON object:

{ "size": "number", "location": "some location", "price": "number" }

This could enable an open dApp store of "renderers" where anyone can contribute renderers that can be queried by DataOS to serve up a user experience for the user of DataOS.

The only question I have left is: how does this get documented as a protocol?

Does ANS-108 change from the Render-With standard to the "Rendering" standard to support both "Render-With" and "Render-For"? Does there need to be a new standard? Does ANS-110 handle the "Data Structure" with it's Type attribute?

I'd love to work with the community to get an DataOS POC out into the wild, taking advantage of rendering protocols.

Let me know what you think!