niconiconi @niconiconi@cybre.space

this is basically my thoughts on chat protocol design, based on basically nearly two decades of experience doing it. for the purposes of discussion, we will be comparing and contrasting IRC (which i initiated the IRCv3 initiative), XMPP, Matrix and ActivityPub with Pleroma's ChatMessage activity and ChatRoom actor type (for the purposes of today's conversation we will call that ActivityChat).

it is also important to note that these are just my opinions, and you may or may not like them. but maybe it will convince some people.

to start, the designers of XMPP have had extreme exposure to an engineering-first style of design. their philosophy is roughly something like this:

* it is important for the protocol to be semantically correct. semantic correctness is more important than simplicity.

* the protocol must be correct at all times. observable side effects are not allowed.

* the protocol must be consistent. semantic correctness is more important than consistency.

* the protocol must cover as many usecases as practical. there are many non-ratified extensions (XEPs) that add various functionality.

to contrast, lets look at Matrix:

* simplicity is more important than semantic correctness.

* observable side effects are allowed as long as consistency is eventually reached.

* consistency is more important than semantic correctness.

* the protocol must cover as many usecases as practical.

and, finally, modern IRC:

* simplicity is more important than semantic correctness.

* observable side effects are allowed without restriction.

* consistency is the most important, followed by simplicity and then semantic correctness.

* the protocol is only required to cover group chat and direct messaging. there are many non-ratified extensions (IRCv3.3 is not released yet) that add various functionality.

all of these have various problems, as we can see, but IRC is technically the worst. but it's the most reliable of the three usually. why is that? because of IRC's rudimentary design, it requires little to no effort to maintain: there simply aren't enough moving parts that a failure is possible.

so, how can we get federated chat (IRCops are bad, the portability created by federation is the fix for it, because if leaving an irc network is easy, the abusive IRCop problem becoms self-correcting) that is low effort?

a possible answer is to use ActivityPub:

* a simple transport with optional semantic validation support (this makes it easy to implement)

* 100% stateless protocol, so there's no side effects to worry about. but ActivityPub is topology-aware like Matrix, so it's efficient.

* because it's stateless, the protocol is always consistent. ordering of events is irrelevant.

* the protocol succeeds at covering as many usecases as practical through it's simple actor-oriented model. chat rooms are just a new kind of actor. extensions are easy: new activity types plus new field types, which can be processed with JSON-LD if you want to.

hopefully that explains why ActivityPub as a chat protocol makes sense :)