XSF Discussion - 2020-02-23

  1. Ellenor Malik

    MattJ: the performance in muc:prosody@ is why I predict Jabber will adopt the qline (refuse to federate with servers which do not refuse to federate with server X)

  2. neshtaxmpp


  3. neshtaxmpp


  4. neshtaxmpp

    only testing.

  5. jonas’

    If one wanted to transport Prometheus metrics over XMPP, would it make more sense to simply slap the text format of the metrics into an XML element as character data, or do you think that restructuring the data as XML makes more sense?

  6. jonas’

    I tend towards the former, because it’s easier and will interface more cleanly with existing Prometheus tooling

  7. jonas’

    I tend towards the former, because it’ll be easier to interface that with existing Prometheus tooling

  8. flow

    I guess it depends on your use case. But since those two appear to not rule out each other, I'd probably start with the easiest approach

  9. jonas’

    well, they rule each other out in the sense that nobody would want to support two different protocols for the same thing ;)

  10. Ge0rG

    Is the data easy to transform? Key value pairs or similar?

  11. Link Mauve

    Key-value pairs, tagged with a timestamp, another key-value map of parameters, a type, and a description.

  12. Zash

    How far from https://xmpp.org/extensions/xep-0039.html ?

  13. rion

    Can anyone bring fippo back? I was going to ask him about status of http://hancke.name/jabber/jingle-rtcpmux.patch

  14. rion

    seems like it stopped with this https://mail.jabber.org/pipermail/jingle/2013-May/001916.html

  15. flow

    rion, consider sending him an e-mail, cc'ing standards@

  16. rion

    I just dived into datachannels topic of jingle and was thinking how to properly maintain ICE connections, reduce amount of port allocation and reuse the ports from different jingle applications. And it seems fippo wrote all the related XEPs =)