MUD protocol checklist

[holic]

Things we need to do before considering the "MUD protocol" stable, because any changes here would be considered breaking and possibly a new major version.

• Add missing events to Store (for setting partial fields) and review existing events #1121
• Prefix all events and errors with library/contract name #1126
• Add indexed to tableId in all Store update events #1127
• Rename table to tableId and key to keyTuple in Store events #1128
• Replace ephemeral tables with offchain tables #1123
• Combine registration of schema with registration of metadata to have tighter constraints and simplify indexer logic #1043
• Rename schema to valueSchema (to make it consistent with keySchema) #1129
• Add a protocol version to Store and World #1130
• Use 0x00 as key for singleton tables instead of empty array, require at least one element in a keyTuple #1125
• Discussion: support STRING_ARRAY and BYTES_ARRAY schema types in Store #447
• Remove on-chain validation of schema from as many places as possible #1131

---

General thoughts

• Is there any way to shave off more bytes in World, etc. without substantially increasing gas costs?
  • Should each table config have more fine-tuned control over what gets autogenerated? Or do these unused methods get compiled out of the bytecode, even though they exist in the ABI? -> they get compiled out, see https://docs.soliditylang.org/en/v0.8.4/contracts.html#libraries
• Given that forge flattens ABIs (see feat(store,world): add errors to IStore, rename error interfaces #759), should we prefix more of our contract names to get them out of the way of any potential user code? -> if we find a more unique name use that as prefix, if we keep store and world then prefix with mud
• PackedCounter -> DynamicDataLayout? -> packed counter is general, we could rename the variables in the code where we use it for the dynamic data lengths though
• Have we audited our full set of config options for simplicity, consistency, and understandability?
• Are we happy with "Store" and "World" naming?
  • We recently had trouble figuring out a good name for the TS (client-side but maybe eventually server-side) store/cache for data from the Solidity events, and using "Store" anywhere in the name makes it hard to infer which package represents which language.

[holic]

A recent thing brought up in Discord is it might make sense to have a notion of both events and ephemeral tables and/or some way to opt-in to historical syncing of them (all events rather than just current -> future events).

I think with ephemeral tables, we were originally designing around event-like things, like the result of a given action that doesn't need on-chain storage (e.g. to trigger animations).

Another potential use case is more of an activity log, where you don't need to store values on chain but would like to display them in the client. A kill count, for example, might not be necessary to store/keep long term, but would be nice for the client to be able to sync historical data on for some kind of scoreboard.

[holic]

I think we've addressed ~all of these things