XSF Discussion - 2018-01-03


  1. Steve Kille

    does anyone have any idea why a fetch from github xsf/xeps is failing?

  2. Steve Kille

    I want to get the latest, so I can start on Dave's comments

  3. jonasw

    care to give more details?

  4. jonasw

    error message setc

  5. jonasw

    error messages etc

  6. Steve Kille

    Git GU says it is fetching, works for ages, and then complains connection timed out

  7. Steve Kille

    Has been fine before

  8. Steve Kille

    fatal: unable to access 'https://github.com/xsf/xeps/': Failed to connect to github.com port 443: Timed out

  9. jonasw

    hmm works for me

  10. jonasw

    can you open that https url manually in your browser?

  11. Steve Kille

    fine in my browser

  12. Steve Kille

    pushes of commits to Guithub was working fine yesterday

  13. Steve Kille

    I did the fetch from a different network two days ago, so I guess it could be our proxy

  14. Zash

    Proxies seem like a sensible thing to blame

  15. Steve Kille

    yup - proxy

  16. edhelas

    I'm thinking of extending 0277, having 2 nodes, one for public publication, one restricted to presences

  17. goffi

    edhelas: we have since talked in private, but for the record I have tried the 2 nodes options years ago, and it doesn't work that well. The fine permission tuning (aka items permissions) is the best option from my experience. I still need to propose a protoXEP, but lacking time to write one.

  18. edhelas

    I'd like to know if we can deprecate 0084 and go back to the good old "presence notification" for vcards

  19. edhelas

    we have 2 solutions and I though after 5 years that everyone will move to a full PEP solution

  20. edhelas

    that didn't worked

  21. edhelas

    also it doesn't work for MUC vcards

  22. edhelas

    also barelly no client is implementing it https://nl.movim.eu/?about#caps_widget_tab

  23. moparisthebest

    edhelas, did you see inputmice's talk about it?

  24. edhelas

    I was at the 34c3

  25. edhelas

    which talk ?

  26. moparisthebest

    might have been that one, doesn't that fix the problem server-side ?

  27. edhelas

    I didn't been to his talk then

  28. edhelas

    what was it about

  29. moparisthebest

    I'm trying to find a link but not having any luck yet

  30. edhelas

    https://github.com/iNPUTmice/talks/blob/master/2017_12_27_-_jabber_xmpp_the_past_the_presence_and_the_future.md

  31. moparisthebest

    yep that's it specifically https://github.com/iNPUTmice/talks/blob/master/2017_12_27_-_jabber_xmpp_the_past_the_presence_and_the_future.md#avatars

  32. moparisthebest

    it's not perfect, but you see what happens when we try to create perfect, we get MIX, and it never goes anywhere

  33. edhelas

    yup

  34. moparisthebest

    can I officially propose the future cut-down-to-useable-proportions MIX replacement be called MUX ?

  35. edhelas

    I just read about MUC-SUB https://docs.ejabberd.im/developer/xmpp-clients-bots/proposed-extensions/muc-sub/

  36. edhelas

    it's quite great, also retro-compatible

  37. moparisthebest

    ah will read, I was only aware of https://xmpp.org/extensions/inbox/muc-light.html

  38. moparisthebest

    but retro-compatible sounds great

  39. Ge0rG

    We could probably make a MUC-actor thing where your account joins MUCs on your behalf.

  40. Ge0rG

    Maybe even without changing the protocol.

  41. moparisthebest

    and requiring all user's servers to be updated would be a good test for how feasible mix is :)

  42. Ge0rG

    There are voices saying that the big servers will update fast.

  43. goffi

    is there any server MIX implementation based on current specs ? I know about the one from Ejabberd but it was on first draft and I don't think it has been maintained.

  44. edhelas

    same

  45. edhelas

    Muc/Pub is used by several clients in production as well

  46. moparisthebest

    which ones?

  47. Holger

    moparisthebest: Commercial ones.

  48. dwd

    goffi, We have a MIX implementation, but it's not quite the current spec.

  49. goffi

    dwd: is it public, can we test it ?

  50. dwd

    goffi, It is public-ish - in surevine's github in our Openfire fork. You'll need a real database, though - the embedded one doesn't work.

  51. dwd

    goffi, Also, no presence, since we didn't need that.

  52. goffi

    dwd: ok cool. Would be nice to have a simple wiki page with links to current implementations, so the day I want to start client implementation I can select a server one.

  53. moparisthebest

    you need 2 server implementations though

  54. moparisthebest

    uh, in that your server needs support, as well as a mix component

  55. moparisthebest

    so when looking for server support you need those 2 different things right?

  56. MattJ

    It means MIX is going to take years (that's years + whatever time it takes to get implementations released)

  57. MattJ

    Because MIX is not usable by the ordinary user if they can't just invite anyone on their contact list, and most people are going to be running from OS packages

  58. moparisthebest

    years or never, like privacy lists, original archiving etc

  59. MattJ

    Privacy lists was pretty widely implemented, back in the day, actually :)

  60. MattJ

    Just with a terrible UI

  61. Ge0rG

    Damn, where's my "told you so" stamp?

  62. moparisthebest

    especially if you have something simple that solves 99% of use cases and is backwards compatible, like maybe this muc-sub thing, haven't read it yet

  63. edhelas

    Ge0rG you didn't had enough ink to stamp last time, need to buy more

  64. edhelas

    muc-sub seems to be a good 50%-50% between the two XEPs

  65. Flow

    moparisthebest: which "future cut-down-to-useable-proportions MIX replacement"?

  66. __

    -____-

  67. moparisthebest

    Flow, all I know is it should be called MUX

  68. moparisthebest

    I'm just assuming there will be one in the great tradition of the XSF

  69. Ge0rG

    Flow: is it possible that smack will never cache entity caps for JIDs it didn't previously receive presence from? https://github.com/igniterealtime/Smack/blob/master/smack-extensions/src/main/java/org/jivesoftware/smackx/disco/ServiceDiscoveryManager.java#L510

  70. Flow

    moparisthebest, i'm not sure about it, but I would really like a little competition

  71. Flow

    Ge0rG, possible, I think Smack should maybe calcucate the version itself

  72. Ge0rG

    Flow: yeah. Just noticed that in smack3, I only have persistent cache items from my own caps

  73. Flow

    I can tell from the variable naming that this is veery old code ;)

  74. Ge0rG

    it's actually the same in smack3:P

  75. Flow

    looks like a good incentive to start on caps2

  76. Flow

    on a second look, that code locks correct, and is covered by integration tests

  77. pep.

    reading daniel's talk re avatars. Does 0153 really requires you to download your own avatar on every connection? If you have it locally you can just hash it and compare to what the server is sending you, right?

  78. daniel

    pep.: how do you know it hasn't been changed by another client?

  79. pep.

    You hash the one you have locally and compare it, if it's not the same your redownload it

  80. pep.

    I mean there's not need to download it _everytime_

  81. pep.

    right?

  82. moparisthebest

    don't you have to download it to calculate the hash?

  83. pep.

    You have a copy locally right?

  84. pep.

    What's different from PEP here?

  85. moparisthebest

    how does that tell you what's on the server?

  86. pep.

    "A client MUST NOT advertise an avatar image without first downloading the current vCard", that's meh

  87. pep.

    Indeed.

  88. pep.

    Isn't there a way that the server sends back a hack of the current avatar instead?

  89. lovetox

    what do you mean with is there a way

  90. lovetox

    like with a current xep?

  91. lovetox

    no, but it would probably be trivial to add to 0153 that the server sends the hash on request

  92. pep.

    Well, not 0084, as it doesn't work in groupchats

  93. lovetox

    ..

  94. pep.

    yeah

  95. lovetox

    but downloading a vcard is really nothing i would sweat about

  96. pep.

    I don't know, daniel put it in "downsides" in his talk

  97. lovetox

    i guess on mobile it is sometimes a downside

  98. lovetox

    and its not particular pretty

  99. pep.

    yeah but it's not like it couldn't be fixed

  100. lovetox

    but nothing that would stop me implementing it

  101. moparisthebest

    pep., more trivial than not changing the xep and having a server plugin just do it all for you? :P

  102. moparisthebest

    either way you are writing code and deploying it to a server

  103. moparisthebest

    I like daniel 's approach better

  104. pep.

    moparisthebest, sure, things take time. But 153 has been out for a while now

  105. lovetox

    but 153 is historical

  106. lovetox

    i dont think these are meant to be changed

  107. pep.

    Hmm.

  108. pep.

    How do you change that? You fork it?

  109. moparisthebest

    what problem are you trying to solve

  110. lovetox

    and do a pr, but i guess this will not make it :)

  111. moparisthebest

    why would you try to solve it with a xep change, client change, and server change

  112. moparisthebest

    when you could solve it with just a server change, and end up with a simpler client using less bandwidth?

  113. pep.

    lovetox, yeah, honestly I don't really care

  114. pep.

    I have enough GB on my plan so that it doesn't matter at all

  115. moparisthebest

    it's not really that, it's the added time a connection takes in my opinion

  116. pep.

    I just find sad that we have to go through convoluted ways (PEP -> vcard) to fix this kind of things

  117. moparisthebest

    the other way sounds far more convoluted

  118. pep.

    How so? Making people update their software ?

  119. pep.

    How so? Making people update their software?

  120. daniel

    > I just find sad that we have to go through convoluted ways (PEP -> vcard) to fix this kind of things I find that extremely simple and straightforward

  121. daniel

    And it's already supported by the important servers

  122. moparisthebest

    pep., again "xep change, client change, and server change, and clients use more bandwidth" vs "server change (major servers already support it)"

  123. moparisthebest

    which sounds easier and more preferable?

  124. pep.

    So that means if I want to implement a server, I'll have to support both 0153 _and_ 0084 (and PEP) for avatars? Plus also the PEP -> vcard thing

  125. pep.

    How isn't this convoluted

  126. pep.

    (No I'm not planning to implement a server, still I hope you get my point)

  127. moparisthebest

    ok, well you have to support both 0153 _and_ 0084 anyway

  128. moparisthebest

    I guess you might complain about converting, but a sane structure would have you storing them in the same place anyway?

  129. pep.

    I'm complaining about the workarounds mostly. I'm not sure how fixing a historical XEP works, but adding a "Server returns vcard hash" wouldn't be difficult

  130. pep.

    heh, the compliance suite doesn't state 153 at all?

  131. moparisthebest

    also your argument seems to be make it slightly easier to write a new server by making all existing servers add features to existing historical plugins

  132. moparisthebest

    still not buying it

  133. moparisthebest

    when in doubt go with the simplest thing that works

  134. moparisthebest

    KISS

  135. pep.

    moparisthebest, not "historical plugins" no, just "mostly used solutions", just like edhelas showed above, 0084 isn't really implemented anywhere

  136. pep.

    Also 0084 doesn't work anyway, re groupchats

  137. daniel

    I'd rather you not write a new server in the first place

  138. pep.

    daniel, sure

  139. pep.

    s/mostly/most/

  140. moparisthebest

    I'm just waiting for Link Mauve to write a server in rust so I can switch

  141. pep.

    I don't think xmpp-rs is going to be designed for servers

  142. moparisthebest

    I don't care what library he uses :)

  143. pep.

    heh. I don't think he's mad enough to do that anyway

  144. Link Mauve

    You never know!

  145. pep.

    I know you're mad, don't worry

  146. moparisthebest

    on a side note, why are the majority of major xmpp servers written in crazy esoteric languages :)

  147. Link Mauve

    :p

  148. moparisthebest

    does that say something about the people who use xmpp :'(

  149. pep.

    Link Mauve, any idea what's become of Freyskeyd and his talk of writing a server?

  150. pep.

    https://github.com/Freyskeyd/xmpp-rs/tree/master/server

  151. pep.

    fn it_works() {} :)

  152. Link Mauve

    pep., he seems to have stopped working on his library altogether.

  153. moparisthebest

    "It's goal is to be fully tested and usable."

  154. moparisthebest

    he is halfway there (it's fully tested)

  155. pep.

    it even says it works!

  156. moparisthebest

    is anyone aware of any xmpp test domains for client and/or server devs to test proper srv fallback etc ?

  157. moparisthebest

    similar to like http://www.dnssec-failed.org/ for testing dnssec

  158. moparisthebest

    many, possibly most, clients and such don't end up falling back correctly or at all turns out

  159. moparisthebest

    like they fallback if the port isn't listening, but not if it sends invalid xml, or doesn't support ciphers it likes, or various other errors

  160. Holger

    moparisthebest: You're suggesting Rust for an internet service and complaining about esoteric language choices?

  161. moparisthebest

    no I think rust would neatly fall in there right now

  162. moparisthebest

    (the esoteric lang category)

  163. Holger

    pep.: I think it's right to have the complexity on the server side.

  164. Link Mauve

    moparisthebest, you can use OpenFire or Tigase, for a very non-esoteric language.

  165. Link Mauve

    There is also Jabberd and Jabberd2.

  166. Link Mauve

    People have been writing one in PHP and one in JS too IIRC.

  167. Link Mauve

    I would know, I’ve written one in JS.

  168. Link Mauve

    (Never again. ;_;)

  169. moparisthebest

    I'd guess ejabberd/prosody/openfire is most of the public network though, and if so, that's 66% esoteric langs :P

  170. moparisthebest

    and my guess is openfire is distant 3rd there

  171. pep.

    Holger, what annoys me the most is that, from what I understand, we're just choosing the path of least resistance for the features we want out there. Yes we are mostly volonteers, and I get we don't have all the time we want. Plus users are running old software (debian I'm looking at you), etc., Still I don't think we should stop here

  172. pep.

    "That only has to be implemented server-side, let's prefer that over X", I'm not really into this kind of thought

  173. moparisthebest

    pep., good luck getting anything actually put into use then :) (looking at you MIX yet again)

  174. pep.

    daniel, do you have stats btw of what version of Conversations people are using?

  175. pep.

    Or maybe services like jabberfr do? (Link Mauve, mathieui)

  176. daniel

    pep.: no

  177. mathieui

    pep., I don’t think there’s a prosody module for that yet

  178. Holger

    pep.: The amount of madness a client developer new to XMPP is confronted with is insane. Avatar support is a very basic IM feature. We should be able to show him a simple XEP he needs to implement to make avatars 'just work'. If server-side hacks help with hiding the compatibility madness from him, I'd prefer those hacks.

  179. pep.

    For this particular case I'm not sure what's best, implement PEP _and_ 0084 _and_ 0153, or fix 0153 to have the small fix we talked about earlier, and implement only that

  180. pep.

    As a client developer, maybe I'm biased :P

  181. moparisthebest

    so implement only the historical one?

  182. moparisthebest

    seems questionable

  183. pep.

    moparisthebest, if you come up with a non-historical just for the sake of it, that has the same features, and make people use it, why not

  184. moparisthebest

    I'm also under the impression the pep one is easier for clients

  185. Holger

    Well but by now both are implemented.

  186. pep.

    That's why people are trying to shoehorn everything into PEP?

  187. moparisthebest

    it's done, accept the fact and move on 😛

  188. Holger

    I don't know why they are. I would've been opposed to that if I had been around back then.

  189. pep.

    moparisthebest, I would if it worked

  190. Holger

    I'm just saying we have both now, and we either deal with that or we break interop.

  191. moparisthebest

    omemo requires it too

  192. moparisthebest

    probably other things I don't really know about?

  193. daniel

    Neither 84 nor 153 are particularly difficult to implement.

  194. daniel

    On the client side that is

  195. pep.

    daniel, it's just an example

  196. daniel

    For what?

  197. pep.

    For what I said to Holger above, we're just choosing the path of least resistance, "because this way we'll have it implemented and usable no matter how ugly/workaroundy that is"

  198. pep.

    That's just a feeling, I would be happy to be proven wrong

  199. daniel

    I have quite the opposite impression. The Xsf is the textbook example of perfect is the enemy of good. That's why we have so many widely deployed XEPs stuck in experimental.

  200. moparisthebest

    if you want to fully reinvent the wheel pull a matrix :)

  201. daniel

    That's why we have been working on mix for three years now

  202. pep.

    moparisthebest, that's not my point.

  203. pep.

    daniel, true

  204. moparisthebest

    I agree daniel my impression is we create a complex monster of a xep where all possible usecases have to be fulfilled rather than a much simpler solution that fills 90% of usecases

  205. pep.

    so.. MIX and avatars are two extremes? :p

  206. daniel

    pep., moparisthebest: fwiw I'm not trying to be overly negative towards mix here. But choosing the complex solution over the much simpler one that fills 90% of the use cases is a pattern I see in a lot of XEPs

  207. pep.

    daniel, gotcha. I guess I wasn't around long enough

  208. pep.

    Anybody implementing 0306?

  209. pep.

    -xep 306

  210. Bunneh

    pep.: Extensible Status Conditions for Multi-User Chat (Standards Track, Deferred, 2016-06-07) See: https://xmpp.org/extensions/xep-0306.html

  211. MattJ

    pep., none that I know of