House state

These are notes for the specification of the new state of House.

Besides passkey storage (which we can’t query), browser memory, LocalStorage, and backup storage. Backup storage is either on your Arvo server if you have one, or encrypted (with the master secret) on urbit.house if you don’t.

In LocalStorage and backup storage, the per-urbit image is: a checkpoint of the per-urbit kernel (see below), plus a log of changes since. In browser memory, instead of checkpoint, we have live data structures. 

If we lose LocalStorage and backup storage, we query the blockchain to reconstruct a list of the past transactions relevant to this urbit. We essentially construct a backstory: a pseudo-log of an inferred history.

Everything should be defined for multiple chains. “The blockchain” means all global state.

There are two partitions of local: kernel state and derived state.

The kernel state is the state constructed by event processing. Functionally, the semantics of the system are defined by a pure function that accepts the old kernel and the event, and produces a new kernel and a list of sub-events. Of course, since it’s Javascript, we do this by mutating the kernel data structure.


The derived state (read only, can be computed from kernel) 

    —a presentation state as shown to React
    —a cache of HD wallet derived keys
    —a blockchain request state
    —a web request state

In kernel state:

    — a blockchain mirror
	— we mirror the state of various contracts, including: Azimuth, Nexus, and PlanetDispenser
	— we track all tokens and NFTs the user owns
	— [when writing this, adapt all the contract state from the present code. Make sure 
	— the blockchain mirror stores ONLY information received from the blockchain. Information we are trying to send to the chain
            Is in the task state.
        — blockchain mirror can also include state functionally computed from chain state; it doesn’t have to just be a contract copy

    —the user’s deanonymization notes (doxbook). For any urbit:
	—a notes field which includes other aliases, plus a text field for general commentary. An alias can be a real name (first/last), an X username, an ENS name, or an arbitrary nickname. There is a validation bit to show if we’ve checked this.

    —the list of installed urbits. For each installed urbit:
	   — master secret
           — passkey secret (unless passkey supports encryption extension)
	   — whether or not this is a headless wallet (doesn’t own its own token)
	   — metadata about the secrets 
           	— whether (we think) have a passkey on this device
	        — whether the user self-reports having saved the secret offline. Paper? Screenshot?

	   — a set of active tasks

		Tasks are things we are trying to get done onchain (or possibly on web). The way House works is that a task is a little mini-process
		with its own internal state, so tasks can be coded in a modular, separate manner. Relatively few tasks are just 
		 a matter of a single blockchain transaction, but even single transactions are tasks.

		Tasks can (a) put events into the event queue, (b) listen to blockchain events, (c) handle block reorgs :-(.
		A task must not terminate until everything it’s done is not only integrated on chain, but also finalized.
		All task operations are NON blocking.

		Tasks also define an overlay over the blockchain mirror. When we display blockchain information
		to the user, it first checks if there is a task that would modify it to some other value. If there is, 
		it displays it as red (not yet uploaded), yellow (in mempool), blue (in a block), or black (stable).

		Tasks also report their current blockchain query set. This query set is unified and used to reactively generate
		queries to blockchain services. This is NOT a procedural API in which tasks send queries.

		Although it should be less common, tasks also can make HTTP requests, also handled reactively.

		There will be permanent tasks (like watching the user’s wallet) that never end, but most tasks (like a
		a normal spend) should delete themselves once everything is stable.

		There will be a task screen in the UI where you can look at the things House is trying to do

	   — a user interface state. This includes: 
		—  current screen position in House interface
		—  modal dialog window state: a queue of pending modals
                —  notification state:
			— list of all notifications
				— read/unread, URL, summary

	   — a user-level registry. This is a history of things that have happened 
	   — settings. These include:
		—  general settings [copy these from present codebase]
		—  iframe url 
		—  settings for each room you’re in

	   — reminders. 
		—  reminder data structure:
			— reminder is just a URL shown in a frame
			— two kinds of reminders, urgent and timed. Show urgent ASAP. Timed reminders have a frequency and a last-shown bit.
			— reminders can take actions which can delete or adjust themselves