The Matrix protocol is well worth the read. JSON-LD is a bit of a nightmare to work with, but the gist of it is a solid concept; it has drastically changed my approach to software design.
Could you expand on what you found particularly compelling about the protocol / API, and also how that's changed your software development approach?
From a technical standpoint, there are six specifications (Matrix, Mastodon, XMPP, SIP, SMTP, Microdata) that have gotten the "future of the internet" partially right, in my opinion. Some union of the them, excluding the unfortunate bits, is likely the email/Twitter/Facebook/what-have-you killer. Putting that in consumers' hands and getting them to use it is another story, but we do have the starts of a technical/back-end answer.
For example, you could embed text document edits inside of Matrix messages as Microdata (ignorantly spamming someone aside with thousands of character edits aside). Is your spouse doing their taxes? Send them a chat message with Microdata explaining to the form where the attached document goes.
As a general goalpost, WeChat (having circumvented federation problems) in China is a really great example. You can pay for food at a hotdog stand on the street with chat. Uber merely facilitates communication between taxis and commuters. Whatever the project(s) you are referring to, software usually ends up solving communication problems. Recursively simplify your problem, ultimately realize how communication fits into it, then work your way back up to your initial idea. Federated IM is ludicrously powerful and, especially with graceful degradation, can lead to some sales leads.
In my own view it's a much more robust way of architecting communication: the server(s) should assume that remote parties will be off, and remote parties will come and get what they want at their own pace and time. Maybe they won't receive a few messages immediately but can immediately retrieve multiple when needed. With a stretch you could see a parallel with Kafka: instead of trying to send stuff to consumers as soon as it is produced, just store it, and when clients are up they'll process stuff.
Yes, it does eventual consistency replication, like NNTP, but that's not an incredibly important feature.
Encrypted 1:1 messages should not be stored on servers! They should be sent between clients p2p stile or at least forwarded by servers without storing them.
however, we're adding message retention configuration currently to let you limit how long your messages get persisted for (whether they're encrypted or not): https://github.com/matrix-org/matrix-doc/blob/matthew/msc176...
Storing 1:1 messages (noting that Matrix doesn't differentiate between group chats and 1:1 chats) on a server is beneficial because you might not want to lose your entire private chat history with your family and friends whenever you lose a device (source: this happened to me multiple times with Signal -- which has an awful backup system that I didn't use because it simply doesn't work properly).
Now, there is obviously cases where you don't want the server to keep your messages forever -- and then you might want to have retention policies and so on. But I don't really agree with the security argument, since the most obvious attackers already likely have your messages, and it sacrifices a lot of convenience that most people expect (my partner didn't expect to lose all her Signal messages when her phone died unexpectedly).
From our perspective, the room replication is absolutely critical - it means that the network can partition and the servers can come up and down without the room being disrupted at all. It's the opposite of a MUC, where if the server hosting a MUC is inaccessible or goes down, you're screwed.