1. This is complicated. From a fThere is a notion of power_level, which you can set to different events. So you can set "send message" to power level 30, and an

1. This is complicated. From a fThere is a notion of power_level, which you can set to different events. So you can set "send message" to power level 30, and any user with a "power level" of 30 or more will be able to send messages. Those power levels (and the required level to send an event) are granted by the room creator. There is, however, no power_level associated with reading messages. From a federation/server<->server perspective, every message must be publicly readable (though they may be E2E-encrypted) to be usable. I think you need to be joined to a room to send messages, and to be joined, you need to be able to read messages by design (the messages form a DAG, so you need a node in the DAG to append to it). So the "inbox" model doesn't seem representable to me. But maybe I'm missing something/not creative enough X). 2. Yes. Events can refer to prior events to modify them, e.g. you can "edit" a previous message by appending a new message of type "msg.edit" (made up type, not sure what the exact it), specifying the old message id, and the new text. For matrix-based CRDT, see Matrix-CRDT[1], a Yjs backend using Matrix.