Message contents: Pijul, PSYC, etc.

[Jeff Burdges]

>> 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