webdb-responses.md

If Rotonde were to switch to WebDB and to Beaker's format, wouldn't that 1. restrict Rotonde to Beaker's format; 2. force services to run in Beaker (cutting already working tools off the network)? I welcome Ingest, but... letting the browser dictate where and how social networks should store their data sounds wrong IMO.

I agree.

Regarding the tooling working outside the browser, you can use ingest directly in node, and we even have a neatly-packaged module for that: https://github.com/beakerbrowser/beaker-profiles-api (it's a little out of date compared to the spec but it'll be kept up to date -- it's what we use inside beaker). So, that shouldn't be a concern.

Rotonde doesn't have to use WebDB. We want yall to use Ingest or the files API directly if you're not interested in WebDB's schemas. The idea with WebDB is to reduce the learning curve and do some things which are otherwise hard to do right now: giving fine-grained permissions, sharing data between apps, enforcing compatibility, and so on. WebDB lets us jump straight to a good DX and UX for some common concerns, and then retroactively break out the solution into userland. (I suspect it will be done by moving WebDB into a long-running service layer in userland.)

So, two options I want to us to explore:

1. We can either pull back on WebDB for now and let userland be a little less structured in 0.8, and then write specs to accomplish the same tasks, or -
2. We can move forward with WebDB and spec out the "userlandification" of everything it does.

The specs I think we'd need to get into are userland services, permissions, schema identification, etc. These are all specs I want to have, but they'll take time and energy! So that's why I proposed option 2, because I think we can get a better result in the near term. I'm open to hearing what people think.

(FWIW) Something else to keep in mind is, portal.json is not sustainable long term. You'll need to break up the datasets into individual files, otherwise each change will require the network to resync the file, and the file will get into the MBs range. So, yall should plan to migrate to Ingest or WebDB something like it, eventually.

Regarding more new web apis and user land, I was thinking about it and discussing it for normal browsers.
Maybe it's a good idea for beaker because it can realize it more easily using dat?

beakerbrowser/specs#2