Some engines, such as Hyperion, need a place to store settings and options. Some ideas below:

• We should try to store all arcology configuration options in a single table so that individual engines don't have to deal with that.
• We store records under a combination of engine name + ID, where ID is generated by the service itself.
• For example, Hyperion could save its options under the well-known ID "settings" and the system could prepend "Hyperion". Or perhaps we treat it like other resources and only accept "Hyperion.xxxx" IDs from a the engine.
• Packages/service should also be able to define settings and options. For example, Ministry could save its list of directors as a setting. We would define an options record called "Ministry.auth" which would contain a struct with values. The package would define each of the options and provide defaults. Declaring options would also allow us to have a centralized UI for setting options across engines/services.
• In general, this system would work for small numbers of options, not for unlimited records per service. For example, we wouldn't want to create a unique options record for each user.
• We need to deal with the case where the database is on a separate machine. Do we wait until we connect to load options? Do we have a local database? [Probably the former.]
• The above implies that we cannot store arcology information required to establish the arcology. This might be OK, since all we need to join an arcology is an address and a key.
• Perhaps we need a per-user version of this system. E.g., Ministry might store a record (Ministry.settings) on a per-user basis. Rather than letting each service create their own system, we could centralize this in Cryptosaur (or Exarch).
• Imagine two tables: Arc.settings and Arc.userSettings. The first is indexed by record ID, which is of the form, {Service}.{id}, for example: Ministry.settings. The second is indexed by username and then by record ID. We could have a secondary index by service.