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.
Also, i think i learned the most by reading the client-server api spec, and figuring out how to leverage the api to send messages into a room (from a little throw-away command line app i built)...but then, i dissolved my thinking that my little playing arouind had to be a "chat message" that gets sent into a roomn, and pretended the rooms and messages were for other contexts...and that is when my brain blew up, and that matrix is much more beyond just a chat messaging protocol. From my little playing around i grew to understand use cases like event synching between, say, IoT devices, and on and on... Admittedly, the chat use case is pretty easy to get acquanted with matrix. But i feell that there is so much more in store for the future of matrix. There are lots of clever people out there; i can't wait to see what else they build with matrix!
EDIT: UPDATE...My apologies, i should not have assumed you were a dev/techie and would be willing or had the availabnility to "just build an app" in order to learn about a thing; sorry! My note about visiting the /discover page still would help in any case. :-)
Yes, decentralized through federation like Mastodon.
One other cool think about it, each "message sent to an user or a room", are "events".
And an event can be of any type, and have any sort of (json) data to it.
Through element.io (the main matrix client, developed by Matrix people), you can type `/devtools` in a chat, to test sending "custom events" to a room.
As a developer, it means you can "hack" matrix, to make it store whatever data you'd like.
The main thing you need to know about Matrix is that you need a "homeserver". The makers of Element will provide you a central one. You can make your own, or run in a VPS or something, but all your messages are stored on there and there is (last I heard) no way to move them from one homeserver to another. So, there might be strong reasons to run in a VM so you can move it around as needed. (But I am not sure about how easy it is to move it from one IP environment to another.)
If you run the flagship server, which is coded in Python, you need a lot of RAM. Gigabytes. So the $4/mo level VPS, or a cheaper Pi, might not be enough.
There has been talk about making the Element app itself work as a homeserver. I don't know how far along that is, or how well it can really work.
> If you run the flagship server, which is coded in Python, you need a lot of RAM. Gigabytes. So the $4/mo level VPS, or a cheaper Pi, might not be enough.
If you don't join lots of big federated rooms (50-100 servers, 1000s of members), 1GB is enough for Synapse+Postgres
sign up on a server of your choice. then browse rooms on eg, matrix.org and try to join a popular room. time how long it takes before it becomes usable. once that's done, login a second time on a different device and watch the various rooms go out of sync constantly :-)
As a public librarian, I was sort of thrown by the title. It's for things like image libraries, or presumably other media. Not related to lending libraries.
ah yes sorry, not only images - tough could be a (visual) start.
Hoping to get you surprised, because, libraries, I'd like more of them, more knowledge/experience sharing.
While I have not tried/implemented Libli (yet), I'm happy to see more innovation around the matrix protocol! The more, the merrier; and we all benefit! Also, it looks like it is less setup - maybe easier to run (?) - than one of the implementations that I've read about, like this one: https://evolved.systems/hosting-a-blog-on-matrix/
...But, again, I'm glad to see any and all implementations and ideas leveraging matrix! Kudos!
Thanks! It is only a client software, not the server part.
Will try to make it available through `npm` though, so it is easier to self host.
Cheers! Also really excited about matrix, having great hopes for the future :}
But, after reading this, it's obvious I was totally wrong. Matrix is to Slack like Mastodon is to Twitter: decentralized. Right?
Is there a good starting point for learning about Matrix? Especially for someone who hates chat rooms. :)