I'm very excited to be presenting at FOSDEM in February! I've been working on messaging interoperability for about 2 years now with much of that focus being on developing an open standard for that exact purpose. We'll be exploring how #Matrix works as an existing decentralized open standard for *interoperable* communications, and how other protocol development work interacts with Matrix.
Join me for a technical look at #MIMI, #DMA, and the Matrix protocol: https://fosdem.org/2024/schedule/event/fosdem-2024-3157-interoperability-matrix/
Shin.Ice :debian:
in reply to TravisR • • •clacke: inhibited exhausted pixie dream boy 🇸🇪🇭🇰💙💛
in reply to TravisR • • •@TravisR Cool! I only heard of MIMI for the first time this week. Looking forward to your talk, it sounds interesting!
I bet some of the first questions that pop into people's minds are:
1) How is MIMI not yet another XMPP
2) How is MIMI not yet another Matrix
3) In general, how does this not suffer from #xkcd927
Have you or someone else already given a talk or written a blogpost that addresses those concerns? I'd like to get a head start until February. =)
TravisR
in reply to clacke: inhibited exhausted pixie dream boy 🇸🇪🇭🇰💙💛 • • •@clacke thanks! I'm not sure there's written material on it, but the intention of MIMI is to learn from prior attempts at an interoperable protocol to build something which actually works. XMPP has largely not been adopted in this sphere, though is popular in its own right. Matrix has additional features that don't translate well to other providers as well (we'll talk about this in the talk).
It definitely feels a bit like XKCD 927, but this time we're going to interoperate with all of them :)
Dawid Rejowski
in reply to clacke: inhibited exhausted pixie dream boy 🇸🇪🇭🇰💙💛 • • •@clacke
MIMI is not a protocol, but rather something like a working group to discuss what protocol to focus on :).
"More Internet Messaging Interoperability" it stands for
TravisR
in reply to Dawid Rejowski • • •More Instant Messaging Interoperability (MIMI) using HTTPS and MLS
IETF Datatrackersmallcircles (Humanity Now 🕊)
in reply to TravisR • • •@didek @clacke
I'm no expert on IM at all, but when looking at IM protocol specs and seeing a key role for a Room at protocol level, I always wonder whether that isn't overly limiting the versatility of the protocol. In Matrix you see apps where richer social networking use cases are being modeled, but deep down everything should be rooms. But idk enough, maybe that's no issue at all.
Dawid Rejowski
in reply to smallcircles (Humanity Now 🕊) • • •@smallcircles @clacke
Room is not only a chat room, it's just a name for a "container" of some data, I think.
In Matrix rooms have chronological events, non-chronological states and members with permissions. This can also be group for posting, game lobby or user profile with interactions, basically anything.
TravisR
in reply to Dawid Rejowski • • •@didek @smallcircles @clacke this^. MIMI is highly focused on messaging, so it picks a term like "room" to best describe the container. It may in theory be able to transmit more than messages, but it's not the purpose.
Matrix is very much meant to be a generic communications layer. It happens to be that messaging works really well here, but it's not the only focus. We use "room" mostly because no one has decided to rename it following the early proof of concept demos :p
smallcircles (Humanity Now 🕊)
in reply to Dawid Rejowski • • •@didek @clacke
Yes, thank you. I should have a closer look at specific msg formats on how that's expressed. I was more of a mindset of "call a duck a duck", not a "room, type=duck" but it may boil down to not matter much, idk :)
TravisR
in reply to smallcircles (Humanity Now 🕊) • • •@smallcircles @didek @clacke MIMI's content format is still very much a WIP, and is fully intended to be focused on messaging.
Matrix however just calls everything an "event". Even within a messaging-focused room there are events that users don't see, like the events to set up VoIP calls or ensure threads work.
Critically, Matrix lets you define your own event types and use them - nothing will break from doing that. Matrix is essentially a distributed JSON database in this respect.
smallcircles (Humanity Now 🕊)
in reply to TravisR • • •@didek @clacke
Yes, I like that event extensibility. I am just wondering about that Room abstraction. But my musing on whether this abstraction is too leaky is just gut feeling, as I am not that well-informed.
Just quickly skimmed #Commune by @erlend and e.g. it looks like a Space is also a room, and a space subsequently has rooms.. https://github.com/commune-os/commune-server/blob/main/app/space.go
#PubHubs has Hubs which have rooms, and which aren't currently federated, but I suspect they'll become rooms in the msgs too.
smallcircles (Humanity Now 🕊)
in reply to smallcircles (Humanity Now 🕊) • • •@didek @clacke @erlend
XMPP otoh doesn't have rooms, and msg formats can be way more freely defined, looks like (also re-skimming just now).
TravisR
in reply to smallcircles (Humanity Now 🕊) • • •@smallcircles @didek @clacke @erlend XMPP is very similar to Matrix. Matrix's "room" concept is nothing more than a name - it just holds events. Currently those events are JSON objects with a freeform type to give them meaning.
We also specify a number of events which are applicable to certain situations, like messaging, but it's possible to build your own too.
There's a bit more detail here: https://github.com/matrix-org/matrix-spec/issues/416
spell out that 'rooms' are not chatrooms · Issue #416 · matrix-org/matrix-spec
GitHubsmallcircles (Humanity Now 🕊)
in reply to TravisR • • •@didek @clacke @erlend
Thanks for that info!
smallcircles (Humanity Now 🕊)
in reply to smallcircles (Humanity Now 🕊) • • •@didek @clacke @erlend
It may also be that my thought pattern is entirely irrational, and that just the notion of being in an enclosed room somehow restricts my mind. And that with a rename to "universe" would cause my mind to then explode 😅
TravisR
in reply to smallcircles (Humanity Now 🕊) • • •@smallcircles @didek @clacke @erlend sure :D
We needed a place to put users, so picked "room". Users send events and can set aliases on the room so others can join more easily. Aliases act as doors, to continue the analogy.
Sometimes it can be useful to think of rooms as a routing tag for an event. Each room has an ID and subscribers (members) interested in that topic - sending an event with that room ID routes the object to them equally :)