XSF Discussion - 2023-08-27

  1. Steve Kille

    > 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

  2. Steve Kille

    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

  3. MSavoritias fae.ve

    ah thanks for the insights.

  4. MSavoritias fae.ve

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

  5. MSavoritias fae.ve

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

  6. MSavoritias fae.ve

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

  7. Steve Kille

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

  8. MSavoritias fae.ve

    i am all for it at some point

  9. Steve Kille

    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

  10. Steve Kille

    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)

  11. Steve Kille

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

  12. MSavoritias fae.ve

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

  13. Steve Kille

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

  14. MSavoritias fae.ve

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

  15. Steve Kille

    what is your target application/usage?

  16. Steve Kille

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

  17. MSavoritias fae.ve

    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

  18. MSavoritias fae.ve

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

  19. Steve Kille

    yes - not losing stuff is vital

  20. Steve Kille

    Are you sure about MAM - this feels wrong to me

  21. Steve Kille

    I'd expect MAM to be lossless

  22. MSavoritias fae.ve

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

  23. Steve Kille

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

  24. MSavoritias fae.ve

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

  25. Steve Kille

    that sounds interesting

  26. MSavoritias fae.ve

    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.

  27. Zash

    Unstable MAM archives and merge issues. Good luck!

  28. MSavoritias fae.ve

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

  29. MSavoritias fae.ve

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

  30. Kev

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

  31. MSavoritias fae.ve

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

  32. MattJ

    Sounds like you invented Matrix 🙂

  33. MSavoritias fae.ve

    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

  34. MSavoritias fae.ve

    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

  35. Zash

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

  36. Kev

    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.

  37. pep.

    They had cbor support or something no?

  38. Kev

    CBOR's just an encoding, no?

  39. MSavoritias fae.ve

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

  40. MSavoritias fae.ve

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

  41. MSavoritias fae.ve

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

  42. MSavoritias fae.ve


  43. MSavoritias fae.ve

    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

  44. Kev

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

  45. Kev

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

  46. Zash

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

  47. Zash

    You know what this sounds like to me?

  48. Zash


  49. MSavoritias fae.ve

    Yeah I agree the model of matrix is wrong

  50. MSavoritias fae.ve

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

  51. MSavoritias fae.ve

    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.

  52. Kev

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

  53. Kev

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

  54. Kev

    For some values of better.

  55. Zash

    CBOR is extensible, no need for JSON

  56. qy


  57. qy

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

  58. Zash

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

  59. Zash

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