XSF Discussion - 2018-06-26

mimi89999: for me, FMIX is a key goal. So this is a requirement. Details on achieving this will be additional to MIX core specs. The important thing for the core specs is that they are done in a way that will facilitate this. FMIX is going to be simpler and cleaner than FMUC. WIll also address some issues in FMUC.

Steve Kille, maybe add most of what you just wrote (as note) to MIX-CORE?

I'm sure mimi89999 won't be the only one wondering about this

flow: makes sense. I'll add this in the next round of edits

Steve Kille, thanks

So you don't go for a Matrix like approach?

mimi89999, as far as I can tell no. Matrix is consists of multiple dezentralized archives which get merged once in a while to form a graph (as far as I can tell, happy to be corrected if I'm wrong). MIX, right now, is a master archive from which participant's server could sync from

That would mean no connectivity to the master server means participants on a different server wouldn't be able to communicate in the room

which is exactly what FMUC was designed to allow, iirc

MattJ, right, but note that I wasn't talking about FMUC or FMIX

Yep, I agree with your description of Matrix, and of MIX, but just adding the observation that the MIX model as you describe it will not suffice for FMIX

MattJ, right, something like FMIX would basically mean bi-directional sync from/to the "master" instead of uni-directional sync

Shouldn't that be designed in the XEP as it is on of the requirements listed?

mimi89999, why shall we bloat the core xep by stuffing everything, especially optional functionality, into it?

mimi89999, the requirements state that the federation must be "enabled", not "supported"

this might be nitpicking, but the requirement, in my reading, just says that the spec must take care that such federation isn’t actively hindered

jonasw: that was my intent. I care a lot about this. it will be in (yet another) XEP in the MIX family

will tweak the words to make this clear