XSF Discussion - 2023-08-27

> Hey o/> I see that MIX https://xmpp.org/extensions/xep-0369.html#reqs> says:> > 11. Enable federation of a channel across multiple servers, to provide a service equivalent to "federated MUC" Federated MUC for Constrained Environments (XEP-0289) [4].> > But its not mentioned again. Is that a TBD or is it supposed to be done with > https://xmpp.org/extensions/xep-0253.html> > XEP-0253: PubSub Chaining

I note that 11. was a sensible goal for MIX, but I don't believe that it is actually addressed by the MIX specifications. There was certainly not consideration of XEP-0253

ah thanks for the insights.

then i am probably looking into adapting MIX into it. and improving MAM

at least MIX with its modular architecture and pubsub it should be easier to make it into a federated thing

ah and its not stable so maybe i could contribute a section

I think there should be some broader discussion on this, particularly involving Kev

i am all for it at some point

I had pictured that we would want to do an FMIX equivalent of FMUC (i.e., address the MIX channel federation at the MIX level). However, this was an initial thought, and will be interested in all options

For the constrained bandwidth case (naval model) you want ship and shore nodes to be able to operate independently and for traffic between them to be optimized (as FMUC does)

A more generic usage is not necessarily bandwith constrained between the nodes

ah then i am definetily interested. i have specifically needs to go as down as 0.3kbs intermittent

that sounds like the constrained bandwidth case, that I'm particularly interested in

yep. me too. so i would be very interested to find a solution for that

what is your target application/usage?

I am looking at HF Radio https://www.isode.com/whitepapers/isode-hf-roadmap.html

plus a solution that is fault tolerance. for example: I can have a node come up, start syncing at 3kbs, electricity/internet goes out, and then when it comes back on it can continue to sync from where it was

i have been told that MAM cant quarantee it currently so thats another thing i want to look at

yes - not losing stuff is vital

Are you sure about MAM - this feels wrong to me

I'd expect MAM to be lossless

hmm. not sure no. if it is all the better

There are some people in this room who should be able to speak authoritatively on MAM reliablility

> what is your target application/usage? i have been thinking radio/LoRa and such yeah. or Mesh stuff in general. or dial up local ISPs And as transports i have bundle, bramble, CoAP as interesting directions.

that sounds interesting

Specifically for MAM i am interested in 2 issues: Merging archives from multiple nodes/peers that may be in different timezones/times. So it needs to be time independent merging. And also the thing I said. If the internet/electricity cuts off in the middle of connecting i want it to continue without corruption. Both on MAM side and database side of course.

Unstable MAM archives and merge issues. Good luck!

yeah my hope was that MAM can be improved. Or we can have ARMAM. (Actually reliable MAM)

> I am looking at HF Radio https://www.isode.com/whitepapers/isode-hf-roadmap.html This seems up my alley. Thanks.

> yeah my hope was that MAM can be improved. Or we can have ARMAM. (Actually reliable MAM) But MAM *is* reliable. Or, at least, there's a flag you have to set if your results might be unstable.

yeah i see the stable attribute in MAM XEP. I will experiment setting that and see if merging works and continuity works then

Sounds like you invented Matrix 🙂

heh. it sounds close yes. But i want to avoid the DAG part. And the storing everything forever everywhere. or distributing all the join/left events

the architecture of it is not for sure yet. Because I want to make it lightweight and simple. so it doesnt need updates in hardware or software

that's a perfect recipie for needing updates to _both_. if you're lucky it won't require new physics ;)

The issue with Matrix's model is that it doesn't (from my understanding) work very well for low-bandwidth, frequently offline, setups like FMUC (and FMIX at some point) needs to solve.

They had cbor support or something no?

CBOR's just an encoding, no?

I would say its also the storage but yeah the bandwith is a problem

but thats because it uses http it seems. in the constrained environments matrix they basically swapped http for something else

they basically do: JSON -> CBOR HTTP -> CoAP HTTP long-polling -> CoAP OBSERVE (optional) TLS/TCP -> DTLS/UDP

https://github.com/matrix-org/matrix-spec-proposals/blob/kegan/low-bandwidth/proposals/3079-low-bandwidth-csapi.md

the simplest fix we could do to not have something like matrix is not having to deal with hundreds of thousands of events from rooms. I read the other day of 70GB of events coming from a single room

It's not the encoding of matrix that I was suggesting was an issue for FMUC-type situations, but the model.

(Interestingly, I'd come up with a scheme for XMPP rather like that CBOR+intkeys encoding for matrix, for the bandwidth side, but not implemented anything to test it yet)

Something like HPACK (the HTTP/2 header compression scheme) ?

You know what this sounds like to me?

FunXMPP!

Yeah I agree the model of matrix is wrong

i would be surprised if they change only this stuff anyway. since the model is incompatible for any p2p, low bandwith usage

having every room being a complete mirror so you can keep the whole history/events is not what people are interested in anyway. besides tech people.

> FunXMPP! I was looking at something like FunXMPP, but taking it further, yes.

Although I'm not sure that for the encoding it wouldn't be better to store the XML as JSON and then CBOR it.

For some values of better.

CBOR is extensible, no need for JSON

Extensible?

It encodes all forms of data, how would you extend that

You can register "tags" and "simple values", so you could define some tuple to represent XML nodes etc.

But also yeah, the data model is not as simplistic as JSON, so there are many possibilities