XSF Discussion - 2014-02-11


  1. ralphm

    https://twitter.com/g0rdin/statuses/432999314257084417

  2. ralphm

    For those with some German skills. For those without, the executive summary is: "Carbons >>> Hangouts, Stream Management is awesome. Yeah. The future. Yeah."

  3. simon

    he's a happy camper. Now we just need to get some mobile clients sorted.

  4. ralphm

    I really like watching http://display.ik.nu/xmpp.

  5. Tobias

    you and your self-signed certs ;)

  6. ralphm

    :-D

  7. ralphm

    Better than nothing, I suppose?

  8. Tobias

    probably

  9. Tobias

    it says via Twitter, are there other source that go into it?

  10. ralphm

    Not for this feed, no. But ikDisplay can have multiple different sources. It was originally created as a back channel for the federated semantic-web-like social networking sites I worked on at Mediamatic.

  11. ralphm

    Including ActivityStreams.

  12. ralphm

    https://github.com/ralphm/ikdisplay

  13. ralphm

    Tobias: do you have any use cases?

  14. Tobias

    ralphm, just wondered about the sources...but i suppose not many networks have sources for public streams anyway

  15. ralphm

    Yay silos.

  16. ralphm

    Tobias: That said, it probably should have support for Superfeedr. However, its XMPP PubSub API has some non-standard warts.

  17. dwd

    xnyhps, To be fair, if you send more than 2^96 stanzas, you've a better than even chance of hitting a collision.

  18. xnyhps

    You want to send the entire internet how many times? ;)

  19. dwd

    xnyhps, Although I imagine we could mitigate that by recommending people restart their XMLStream at least once before the heat death of the universe.

  20. Lloyd

    :)

  21. jabberjocke

    anybody have a good federated xmpp domain for groupies to the philips hue bands we are startig around the world

  22. jabberjocke

    the anni-frid@jabber.se <mailto:anni-frid@jabber.se>,bjorn@jabber.se <mailto:bjorn@jabber.se>, benny@jabber.se <mailto:benny@jabber.se> agneta@jabber.se <mailto:agneta@jabber.se> from abba@jabber.se <mailto:abba@jabber.se> is soon online

  23. Tobias

    disco will get a completely new meaning in the XMPP world (:

  24. jabberjocke

    YEEES :)

  25. ralphm

    jabberjocke: looking awesome #hue

  26. dwd

    xnyhps, Oh, he's right.

  27. dwd

    xnyhps, I think you hit parity on the probability of hitting a 10 hex-char (ie, 48-bit) hash fragment after only 4.5 million years on a stanza per second.

  28. xnyhps

    I meant outputting the first 10 bytes of the hash, not the first 10 bytes of the hex representation of the hash, so 80 bit.

  29. xnyhps

    (Also, 10 hex-char is 40 bit, isn't it?)

  30. dwd

    Ah, yes.

  31. Kev

    It is worth noting, potentially, that while they're a generally bad idea, 0-based integer counters do have bandwidth going for them :)

  32. Tobias

    yeah...think of all the savings....when outputting tons of bloated XML

  33. Tobias

    ^^

  34. dwd

    Oh, don't start.

  35. Tobias

    ;)

  36. xnyhps

    Use compression, and pick random parts from the stream so far to use as ids.

  37. dwd

    That actually works.

  38. Kev

    Absolutely.

  39. Kev

    Use an RNG to select bits of a stream to avoid needing to use an RNG.

  40. dwd

    Kev, No, this is for saving bandwidth.

  41. xnyhps

    Just hope you don't actually pick the content of a message. :P

  42. Kev

    dwd: It can't possibly save bandwidth.

  43. Kev

    However many bytes of entropy you want to have are going to take that many bytes to transmit.

  44. Kev

    (At least that many bytes to transmit, you could transmit lots with little entropy, I realise)

  45. dwd

    Kev, No, not at all. If you select carefully, you can generate random identifiers that are always encoded by zlib as a reference, hence three octets or so.

  46. Kev

    And by doing so, you're reducing the entropy.

  47. Kev

    You're talking about selecting your randomness very carefully so that it's not too random :)

  48. dwd

    Smallish number of bits.

  49. dwd

    But it's OK, because you could send the *real* random data earlier in the stream to refer back to.

  50. Kev

    This is close enough to the edge of my knowledge that I accept I could be wrong in this. But this sounds like Not A Good Idea.

  51. xnyhps

    I was entirely not serious.

  52. dwd

    xnyhps, Nor me. But I'm wondering how far I can string Kev along. :-)

  53. Kev

    xnyhps: You, I believe. Dave I have less faith in...

  54. dwd

    Kev, You didn't like the suggestion that you'd put arbitrary random data in the stream, then refer back to it, so you get both the compression *and* the randomness?

  55. dwd

    I was proud of that one.

  56. Kev

    That bit I assumed was a joke. The rest I was less convinced about.

  57. stpeter thinks of the acronym DFTT

  58. xnyhps

    Sorry Peter.

  59. stpeter

    xnyhps: I haven't seen anything useful from this person, but I admit that I have started to tune him out (not quite killfile, but close)

  60. xnyhps

    Me neither

  61. Kev

    You're talking about me, right? :p

  62. stpeter

    ;-)

  63. Zash

    Who are you?

  64. jabberjocke

    created a fosdem post draft at xmpp.org <http://xmpp.org> please review and add a good foto

  65. Kev

    Right, I think that's comments for the people who asked for them on GSoC ideas given.