>> There remains a question of what should the data transported look like? >> Aside from simple messages, I think pijul looks most promising, but again I >> donno this aspect of the problem space nearly as well. > > My answer is still PSYC, the only protocol format I know that > was actually designed to do that job, but pijul could be a > good implementation backend for PSYC state and history.
I’ve forgotten what PSYC does.. I vaguely recall key values pairs ala HTML.. I’ve no real idea why a key-value abstraction helps in messaging. I think MLS addresses the minimal required state, i.e. ratchets, participant keys, etc. All these messengers have some additional room state information they maintain or propagate but the MLS folk include them. I’d expect MLS supports only specific options around message reliability and ordering, and room management. I know Matrix experienced trouble due to their federated design, so considerable work could remain in adapting the MLS ideas. Yet, I do basically think the core room properties emerge from exploring the MLS specs, issue encountered by Matrix, and also mixnet concerns. I’d think raw data with whatever reliability and ordering options emerge would be exposed for “important” applications, but.. I’d expect anything like a mixnet winds up packing unrelated messages into large packets, so most applications suggest some “niceness”, and likely whatever reliability and ordering delivery options the layer below exposes. It’s rather messy even for plain data transport though. As fo pijul, it’s the powerful asynchronous git-like tool that handles fairly weird usage, so maybe an acceptable interface for collaborative applications. I liked being git-like because then the message packing layer has common niceness and ordering information across many collaborative applications, which remains my overall point. Best, Jeff
