Matrix is a bunch of append-only logs automatically synchronizing all the time. The most immediate use case is message passing, but it can also be microblogging, data storage, source code repository, pretty much anything. And because it has been started with HTTP+JSON, it can be used in the browser directly.
Anything that requires any sort of communication can be built on top of Matrix, and profit from its inherent properties (authentification and authorization, encryption, signing, replication, ...)
1. Could the read & write permissions be set independently? Eg: Write by some and read by any would model a blog, and write by any and read by some would model an inbox, symmetric read&write by some would model a chatroom, etc.
2. Does "append-only" imply that the it can only model linear structure, or are there elegant ways to "de-serialize" the append-only event log into some other non-trivial structure? For example, could this append-only "event log" be used to represent... a git repository, or a collaborative document hosted on a CRDT data structure, etc.
If it is flexible in these ways, the possibilities seem endless -- matrix just becomes a decentralized addressing+auth layer with a syncing protocol, which is flexible enough that almost anything could be built/hosted on top! (Hopefully the APIs make this really easy to do, for at least power users)
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.
Anything that requires any sort of communication can be built on top of Matrix, and profit from its inherent properties (authentification and authorization, encryption, signing, replication, ...)