This project is still very much personal and experimental. I should at least add a notice about it being very alpha and that user data may be regularly deleted. I should also maybe limit user access until things are more stable

Although we now have support for asyncronous commands, there is no user feedback that those commands are in progress. There needs to be something built into the command palette that shows commands while they're processing.

I pulled app-scripts out into its own module a while ago without ever coming back and adding it to the project that started the migration lol. Let's get it converted and cleaned up.

When building webdesserts.com I tried a bunch of new design patterns. Those patterns are very visibly missing from this site. I should expose those components to a common library so I can share them between websites.

The route for deleting entries is currently 404ing on existing logs.

Right now I'm using the classic "Loading..." loading state. I should probably add something more graceful.

Right now we are letting zeit now compile our api routes from ts. However this means we end up with some long build times for every individual route. We should precompile these apis so that I don't have to wait 10s everytiem I request a new route.

I also think this would be a good opportunity to move our server-side source files into the src directory.

So originally I wanted to do this completely over dat, but because I will be going back and forth between my work and home computer I've decided that I really need some sort of multi device functionality before I can go 100% dat. Instead, I've decided on using a traditional http server that uses a dat drive as its storage medium. This has a few advantages:

• I get to familiarize myself with the dat apis.
• the user can access all their log data via a dat url.
• If a user ever wants full control to their data they can either clone it or I can export the write keys.
• users can mount their data to a beaker profile where beaker apps can easily access it.

Although I could take this approach with a traditional login scheme, I'm going to instead try using the publicKey and privateKey as username and password. If you have the publicKey you get a read-only view of the user. If you have the privateKey you can make requests to the server and ask it to modify your log.

Since we're using dat as the underlying data-store, If a user has both of these, they technically have full control over their data anyway, so why not? Perhaps eventually in-browser authentication becomes a thing and I'll integrate with that, until then this is probably good enough for me. Some things we could do with key authentication:

• "signup" is just us generating a hyperdrive and handing its keys to the user.
• "login" is just the user handing us their keys.
• This technically means that we can "import" their data as long as that hyperdrive comes in the correct format
• We could "fork" log data as long as the user has access to the publicKey.
• We could also "wipe" the user's data from our server if they can prove they have both keys (but it could still exist out on the p2p web).

I don't think the above user experience is ideal. I think it would be better if there was a traditional login scheme on top of their keys and we could import/export data without losing that user's "identity". I would prefer to use web-authentication, but that's not quite ready yet. So I think key authentication could be a good replacement until then.