3 ms·

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

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)

roblabla 5y ago
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.
deleted 5y ago
[deleted]

roblabla 5y ago

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.

deleted 5y ago

[deleted]