XSF Discussion - 2021-04-14

  1. adiaholic has left

  2. eevvoor has left

  3. adiaholic has joined

  4. derwin has left

  5. derwin has joined

  6. adiaholic has left

  7. lorddavidiii has joined

  8. alexbay218 has joined

  9. paul has left

  10. Aleksej has left

  11. debacle has left

  12. mukt2 has left

  13. chronosx88 has left

  14. lskdjf has left

  15. chronosx88 has joined

  16. Vaulor has left

  17. adiaholic has joined

  18. arc has left

  19. arc has joined

  20. adiaholic has left

  21. mukt2 has joined

  22. sebastian has left

  23. sebastian has joined

  24. arc has left

  25. arc has joined

  26. neshtaxmpp has left

  27. Vaulor has joined

  28. neshtaxmpp has joined

  29. stp has left

  30. adiaholic has joined

  31. Calvin has left

  32. mukt2 has left

  33. millesimus has left

  34. arc has left

  35. arc has joined

  36. arc has left

  37. arc has joined

  38. arc has left

  39. arc has joined

  40. arc has left

  41. arc has joined

  42. arc has left

  43. arc has joined

  44. millesimus has joined

  45. alameyo has left

  46. mukt2 has joined

  47. adiaholic has left

  48. adiaholic has joined

  49. Seve has joined

  50. alacer has left

  51. Syndace has left

  52. Syndace has joined

  53. govanify has left

  54. govanify has joined

  55. lorddavidiii has left

  56. lorddavidiii has joined

  57. arc has left

  58. floretta has left

  59. stp has joined

  60. floretta has joined

  61. govanify has left

  62. govanify has joined

  63. alacer has joined

  64. stp has left

  65. chronosx88 has left

  66. chronosx88 has joined

  67. eric has left

  68. eric has joined

  69. mukt2 has left

  70. dos1 has left

  71. rdelaage has left

  72. superkuh has left

  73. antoine has left

  74. moparisthebest has left

  75. moparisthebest has joined

  76. moparisthebest has left

  77. moparisthebest has joined

  78. adiaholic has left

  79. adiaholic has joined

  80. mukt2 has joined

  81. adiaholic has left

  82. moparisthebest has left

  83. Yagiza has joined

  84. moparisthebest has joined

  85. adiaholic has joined

  86. moparisthebest has left

  87. adiaholic has left

  88. adiaholic has joined

  89. moparisthebest has joined

  90. moparisthebest has left

  91. moparisthebest has joined

  92. sebastian has left

  93. Neustradamus has joined

  94. moparisthebest has left

  95. Vaulor has left

  96. chronosx88 has left

  97. chronosx88 has joined

  98. moparisthebest has joined

  99. moparisthebest has left

  100. moparisthebest has joined

  101. Neustradamus has left

  102. Neustradamus has joined

  103. Seve has left

  104. moparisthebest has left

  105. menel has joined

  106. moparisthebest has joined

  107. sebastian has joined

  108. adiaholic has left

  109. adiaholic has joined

  110. moparisthebest has left

  111. moparisthebest has joined

  112. moparisthebest has left

  113. moparisthebest has joined

  114. adiaholic has left

  115. adiaholic has joined

  116. Syndace has left

  117. Syndace has joined

  118. jjrh has left

  119. jjrh has joined

  120. adiaholic has left

  121. andy has joined

  122. mukt2 has left

  123. sebastian has left

  124. adiaholic has joined

  125. sebastian has joined

  126. APach has left

  127. APach has joined

  128. adiaholic has left

  129. adiaholic has joined

  130. adiaholic has left

  131. paul has joined

  132. adiaholic has joined

  133. karoshi has joined

  134. Tobias has joined

  135. mukt2 has joined

  136. steffen has joined

  137. emus has joined

  138. moparisthebest has left

  139. moparisthebest has joined

  140. moparisthebest has left

  141. adiaholic has left

  142. adiaholic has joined

  143. moparisthebest has joined

  144. moparisthebest has left

  145. moparisthebest has joined

  146. moparisthebest has left

  147. moparisthebest has joined

  148. moparisthebest has left

  149. adiaholic has left

  150. moparisthebest has joined

  151. moparisthebest has left

  152. moparisthebest has joined

  153. moparisthebest has left

  154. adiaholic has joined

  155. moparisthebest has joined

  156. moparisthebest has left

  157. moparisthebest has joined

  158. adiaholic has left

  159. adiaholic has joined

  160. chronosx88 has left

  161. chronosx88 has joined

  162. mukt2 has left

  163. Andrzej has joined

  164. mukt2 has joined

  165. wurstsalat has left

  166. mathijs has left

  167. mathijs has joined

  168. Andrzej has left

  169. sebastian has left

  170. menel has left

  171. croax has joined

  172. Guus has joined

  173. raghavgururajan has left

  174. raghavgururajan has joined

  175. ti_gj06 has joined

  176. sebastian has joined

  177. wladmis has left

  178. wladmis has joined

  179. Syndace has left

  180. Syndace has joined

  181. mukt2 has left

  182. moparisthebest

    when confronted with a too-big stanza as a server, what would the implications be if the server just silently dropped the stanza and carried on instead of terminating the stream with an error ?

  183. moparisthebest

    maybe this answer is different for s2s vs c2s

  184. jonas’

    moparisthebest, if it can do that, it should instead bounce the stanza properly

  185. jonas’

    then there are no (new) implications, beyond what you already get when servers make decisions about which stanzas to deliver

  186. moparisthebest

    what if it can drop it, but can't parse it

  187. jonas’

    unlikely, I think

  188. jonas’

    to bounce a stanza, you only need the startElement SAX event

  189. jonas’

    (or equivalent)

  190. jonas’

    I think you already need that + endElement + magic to determine the stanza boundaries anyway

  191. BASSGOD has left

  192. mukt2 has joined

  193. jonas’

    I guess dropping would be similar to s2s-closing (without stream management), so there’s not much of a difference there, except that deliverability of other stanzas will be improved (as they don’t get lost in s2s TCP buffers when the stream is killed)

  194. Andrzej has joined

  195. moparisthebest

    I'm determining stanza boundaries by counting tags and don't have an XML parser

  196. jonas’

    how are you counting tags?

  197. jonas’

    (to count tags, you already need something like an XML parser ;))

  198. Guus has left

  199. jonas’

    enough of an XML parser to add only a shim layer to extract the attributes out of the tags anyway

  200. jonas’

    enough of an XML parser to add only a shim layer to extract the attributes out of the attributes needed for bouncing anyway

  201. moparisthebest

    roughly, incrementing on < and decrementing on /> or </ so a stanza boundary is when the counter hits 0

  202. jonas’

    <![CDATA[ < ]]>?

  203. moparisthebest

    hopefully no one sends that :D seems to have worked so far

  204. jonas’

    it is valid though

  205. jonas’

    and: what stops you from catching the slice from the first < to the first > and parsing that as attributes? you can drop all namespace-related stuff as that’s not needed on stanzas anyway, just plain key/value

  206. moparisthebest

    hrm maybe, so you think that'd be valid? sending an error response on too-big-stanzas and just skipping them otherwise? but not terminating the stream?

  207. jonas’


  208. jonas’

    <policy-violation/> would be an appropriate stanza error I think

  209. jonas’

    or maybe <resource-constraint/>

  210. yushyin has left

  211. marek has left

  212. BASSGOD has joined

  213. jonas’


  214. jonas’

    look at that, policy-violation has stanza size limit as an example

  215. jonas’

    oh, that’s the stream error, sorry

  216. yushyin has joined

  217. moparisthebest

    antranigv in this MUC has an avatar that makes a stanza bigger than 262,144 bytes for instance

  218. jonas’

    but I think the stanza error is as valid

  219. jonas’

    and bouncing individual stanzas with whatever errors you feel like is the right of a server; clients need to cope with that

  220. marek has joined

  221. jonas’

    dropping on the other hand is tricky because it may be seen as violation of the "MUST reply to IQ requests" clause of RFC 6120

  222. flow

    > moparisthebest> antranigv in this MUC has an avatar that makes a stanza bigger than 262,144 bytes for instance One of the reasons that make me believe that servers should be very conservative about the sizes of stanzas they accept. Someting in the range of 10 KiB to 64 KiB seems appropriate

  223. flow

    I also think that with larger stanza sizes you get easily into scheduling issues, as in, a single stanza can dominate the link while it is transferred

  224. flow

    This is turn means, that you should probably bounce to big stanzas at the first hop, and close the stream on all following hops as soon as the limit is reached

  225. flow

    This is turn means, that you should probably bounce too big stanzas at the first hop, and close the stream on all following hops as soon as the limit is reached

  226. jonas’

    good point about hogging the link

  227. flow

    Unfortunately, I believe that the major parts of the ecosystem would break if we do that

  228. flow

    But I really hope that we get the ecosystem towards a reasonable sized stanza limit in the future

  229. flow

    Of course, this requires, things like RSM on disco#(info|item) responses

  230. flow

    Of course, this requires things like RSM on disco#(info|item) responses

  231. jonas’

    servers already do that :(

  232. dwd

    I wonder if MAM-like responses on disco might make more sense. Or additional sense.

  233. jonas’


  234. millesimus has left

  235. flow

    Furthermore, if we talk about techniques that split large content into multiple stanzas, then we have to be aware that it's not easy for the generating entity to assess the resulting stanza size

  236. jonas’

    just found this https://github.com/horazont/muchopper/commit/7affc581a8539eebc190371d95539bed1fb8bd7c#diff-6d5dca6e6e9b9db00d48d0bb6b748f7302f6b941e4bcee48427a54ff74122c46R48

  237. jonas’

    just found this https://github.com/horazont/muchopper/commit/7affc581a8539eebc190371d95539bed1fb8bd7c#diff-6d5dca6e6e9b9db00d48d0bb6b748f7302f6b941e4bcee48427a54ff74122c46R53-R59

  238. flow

    But probably a pramgatic approach like, "aim for 10KiB stanzas, but limit at 32KiB" is good enough here

  239. flow

    jonas’, is https://github.com/horazont/muchopper/commit/7affc581a8539eebc190371d95539bed1fb8bd7c#diff-6d5dca6e6e9b9db00d48d0bb6b748f7302f6b941e4bcee48427a54ff74122c46R53 fixed today?

  240. jonas’

    I did not check again since that commit

  241. millesimus has joined

  242. moparisthebest

    it's ok I'm 99% sure I found an ejabberd bug while looking at this too, are `<features xmlns="http://etherx.jabber.org/streams"><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls></features>` and `<stream:features><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls></stream:features>` the same or not?

  243. mukt2 has left

  244. moparisthebest

    prosody, dino, gajim, and conversations are ok with either, ejabberd requires the second

  245. jonas’

    they are the same in XML 1.0 with Namespaces

  246. jonas’

    but yeah, ejabberd is picky

  247. moparisthebest

    odd failure mode too, it just hangs for 90 seconds and then sends `<stream:error><connection-timeout xmlns='urn:ietf:params:xml:ns:xmpp-streams'/><text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-streams'>Idle connection</text></stream:error>` and hangs up

  248. jonas’

    yep, probably the parser doesn’t read it as belonging to the stream namespace and then drops it

  249. jonas’

    moparisthebest, but note the interop note in https://tools.ietf.org/html/rfc6120#section-4.8.5

  250. alexbay218 has left

  251. jonas’

    > Implementations are advised that using a prefix other than 'stream' for the stream namespace might result in interoperability problems.

  252. moparisthebest

    ah, nice

  253. flow

    moparisthebest, sounds like you have a new(?) project, what is it? :)

  254. Aleksej has joined

  255. floretta has left

  256. moparisthebest

    flow, reverse proxy https://github.com/moparisthebest/xmpp-proxy still super early, just started dogfooding it on my server recently :)

  257. BASSGOD has left

  258. mathijs has left

  259. mathijs has joined

  260. adiaholic has left

  261. mukt2 has joined

  262. adiaholic has joined

  263. menel has joined

  264. BASSGOD has joined

  265. adiaholic has left

  266. peetah has left

  267. peetah has joined

  268. adiaholic has joined

  269. Seve has joined

  270. Vaulor has joined

  271. flow

    moparisthebest, so you are competing with dwd now? :)

  272. dwd

    Competition always welcome.

  273. dwd

    Especially as I've not had any time for Metre recently.

  274. jonas’

    I think metre doesn’t do c2s, does it?

  275. dwd

    It does not, no.

  276. dwd

    Going to go out on a limb and suggest that xmpp-proxy doesn't do S2S, it's just a connection proxy, too.

  277. eevvoor has joined

  278. moparisthebest

    https://github.com/surevine/Metre ? quite a bit different I guess

  279. mukt2 has left

  280. debacle has joined

  281. moparisthebest

    xmpp-proxy does c2s and s2s, and multiplexes both along with starttls + direct tls all on the same port(s), but also limits stanza sizes

  282. dwd

    But inbound only if I follow this right?

  283. moparisthebest

    correct, inbound only, and provides TLS

  284. dwd

    And that StanzaFilter looks scary. :-)

  285. Kev

    How does it cope with presenting the client cert to the server?

  286. Andrzej has left

  287. Kev

    Or is there a ‘I have verified trust, just do external’ flag being passed to the server-proper somehow?

  288. Andrzej has joined

  289. dwd

    Kev, Yeah, doesn't seem to be any support for that.

  290. Kev

    Probably more applicable to C2S where client certs are uncommon than to S2S then, I guess?

  291. moparisthebest

    no support for client cert auth, server just trusts connections from it is encrypted implicitly (also for the PROXY header)

  292. Kev

    Although I guess it probably gets in the way of -PLUS too?

  293. dwd

    It'd break channel bindings, yes. Also I think the start-tls handling makes me cry.

  294. papatutuwawa has joined

  295. moparisthebest

    yes I agree the StanzaFilter is scary haha

  296. moparisthebest

    these are all correct reactions I think

  297. Kev

    I keep getting tempted to write one of these for M-Link, but I keep deciding it needs to be more than a naive proxy because of the interactions between TLS and auth.

  298. Kev

    (Also because I’d like to use it as a mechanism for seamless upgrades).

  299. moparisthebest

    (personal opinion for my use-cases only incoming) interactions between TLS and auth are dead, let them lie

  300. dwd

    Funnily enough, I thought about adapting the Metre code into an Openfire C2S connection manager.

  301. dwd

    moparisthebest, I think that's not true given channel bindings especially.

  302. moparisthebest

    do they work with TLS 1.3 yet ?

  303. Kev

    moparisthebest: You might not like channel binding, but surely you’re not opposed to S2S strong auth?

  304. dwd

    moparisthebest, Thanks to Sam, yes.

  305. moparisthebest

    will they work with QUIC

  306. dwd

    moparisthebest, Your xmpp-proxy doesn't work with QUIC, so somewhat irrelevant, but I think they should given they're simply based on an exported key.

  307. menel has left

  308. superkuh has joined

  309. antoine has joined

  310. dos1 has joined

  311. mukt2 has joined

  312. rdelaage has joined

  313. moparisthebest

    unfortunately if the web doesn't use them, we can't rely on them being supported anywhere

  314. dwd

    moparisthebest, Except key exports *are* used and seem well supported, so Sam's approach seems much more likely to be generally available.

  315. floretta has joined

  316. moparisthebest

    and QUIC is the future so I wouldn't call it irrelevant, still a hair early though, we'll see

  317. dwd

    moparisthebest, Sure. I expect we'll have XMPP over QUIC at some point. But I don't think key exporting is affected by QUIC versus TLS/TCP, so everything should "just work".

  318. dwd

    moparisthebest, Obviously there's very much a place for xmpp-proxy as a bridge to uplift existing servers and services with QUIC etc support though.

  319. millesimus has left

  320. millesimus has joined

  321. jonas’

    moparisthebest, so that effectively forces use of dialback? or what?

  322. dwd

    moparisthebest, I think your StanzaFilter works for idiomatic XMPP XML, but I'm not entirely sure it'll work correctly in some edge cases. I suspect if I'm sufficiently abusive I can at least sneak a closing stream tag past it.

  323. jonas’

    I’ll just say CDATA

  324. dwd

    jonas’, Oh, yeah, good point, that too.

  325. Andrzej has left

  326. moparisthebest

    also '< stream:stream' and a few other things, probably ok, it accomplishes it's goal

  327. Andrzej has joined

  328. dwd

    moparisthebest, And '<str:stream', and all sorts. Likely it'll work in all non-abusive cases. But yeah, I can get it to terminate the session without the XMPP server thinking its over, and I can get the XMPP server to close it without xmpp-proxy to work. And any server advertising -PLUS basically won't allow auth. Hopefully. But as I say, it'll mostly work and it's a useful tool for a number of cases.

  329. wurstsalat has joined

  330. Kev

    dwd: The server needs to know there’s a TLS terminator in the way anyway, so presumably should not present any auth mechs that don’t proxy in any case.

  331. moparisthebest

    yep I agree, it was written in a bit of a hurry for one specific use-case which it accomplishes, I'll elaborate more later, and in the meanwhile think about if it can support CDATA sanely without bringing in an XML parser :/

  332. emus has left

  333. Kev

    I would be inclined to bring in an XML parser, personally.

  334. alameyo has joined

  335. Kev

    Well, let me rephrase that.

  336. Kev

    If I wanted this to be generally useful, I would bring in an XML parser.

  337. dwd

    Kev, Oh, I think it *is* generally useful, but possibly limited to testing out deployment strategies you'd then incorporate into server mainline code.

  338. Kev

    If it just needs to meet a use case and it meets it, *shrug*.

  339. moparisthebest

    I only hesitate because historically XML parsers have been known to have worse bugs than "closes connection wrongly sometimes"

  340. Kev

    That is not unfair.

  341. emus has joined

  342. dwd

    moparisthebest, This is true, but I can smell the faint odour of a DoS attack there somewhere.

  343. bean has joined

  344. moparisthebest

    I think yes, but only in terms of killing s2s connections ?

  345. Kev

    Killing S2S is probably less bad than *not* killing S2S

  346. Kev

    (I have no idea if such an issue can present)

  347. adiaholic has left

  348. adiaholic has joined

  349. lskdjf has joined

  350. LNJ has joined

  351. mukt2 has left

  352. adiaholic has left

  353. Syndace has left

  354. Syndace has joined

  355. adiaholic has joined

  356. flow

    moparisthebest, jxmpp has a XmlSplitter, which probably does something similar to yours. It doess not contain a full blown XML parser, but is a little bit more robust as yoursI think

  357. mukt2 has joined

  358. flow

    I guess what I am trying to say is, that there exists probably a middle ground between having a full blown XML parser and too trivial parsing for things like that

  359. menel has joined

  360. moparisthebest

    flow, thanks, I'll have a look https://github.com/igniterealtime/jxmpp/blob/master/jxmpp-core/src/main/java/org/jxmpp/xml/splitter/XmlSplitter.java

  361. paul has left

  362. paul has joined

  363. BASSGOD has left

  364. BASSGOD has joined

  365. pasdesushi has joined

  366. govanify has left

  367. govanify has joined

  368. pasdesushi has left

  369. ralphm has joined

  370. mathieui

    So… it has come to my attention that profanity is essentially using 140-chars ids for every stanza

  371. mathieui

    was there any rationale for not limiting the length of the id attributes? we do cap the size of JID, afair

  372. flow

    mathieui, sadly the length restriction of JID parts is the

  373. flow

    exeception, not the rule

  374. flow

    we do not limit pubsub IDs either

  375. BASSGOD has left

  376. BASSGOD has joined

  377. mathieui

    indeed :/

  378. mathieui

    but as far as I understand it, the only properties we want for identifiers is "we can fit something non-guessabled and non-bruteforceable in it, and all the better if we can write some arbitrary data for testing"

  379. mathieui

    but going over 30 or 50 characters seems overkill in every case

  380. menel has left

  381. jonas’

    https://modules.prosody.im/mod_client_proxy.html would like to have a word with you ;)

  382. derwin has left

  383. flow

    mathieui, yes, I think you are mixing two aspects here: the missing length restriction for many ID things in XMPP *and* the question what a sufficiently long ID is

  384. Aleksej has left

  385. flow

    that said, 140 chars is way to long

  386. mathieui

    flow: true, but one could influence the other

  387. flow

    not really

  388. flow

    just because a random ID can be shorter, there may be very well use cases for long IDs which carry some semantics

  389. flow

    arguably, this may not be likely for stanza IDs, but very true for e.g. pubsub IDs

  390. flow

    and I am not sure if it isn't true in some case for stanza IDs

  391. flow

    in any way, we should point the profanity guys to https://www.grc.com/haystack.htm

  392. mdosch has left

  393. mdosch has joined

  394. millesimus has left

  395. floretta has left

  396. Andrzej has left

  397. mukt2 has left

  398. hamish has left

  399. Steve Kille has left

  400. dwd

    Every now and then, I wonder about translation to a UUID in all cases. Mostly for the database efficiency.

  401. edhelas

    dwd +1

  402. Steve Kille has joined

  403. mukt2 has joined

  404. Zash

    36 octets for 122(?) bits of entropy feels inefficient, plus they don't help with sort order

  405. millesimus has joined

  406. dwd

    Yes, you need both a sequential id and a uuid in the database. But cheap to lookup a 128 bit number in an index.

  407. larma

    Also UUIDs can be compressed on wire if octet optimization is what you aim for

  408. hamish has joined

  409. jonas’

    something about https://github.com/ulid/spec

  410. dwd

    I mean, if we wer etalking XMPP 2.0, I'd be saying stanza ids are alwasys UUIDv4 and any duplications detected cause immediate session termination.

  411. Kev

    Of course, even a 128bit integer in string form is less than 140 characters :D

  412. adiaholic has left

  413. Zash

    Profanity with their signed IDs?

  414. mathieui

    the worst part of the profanity thing is that the id is a base64 of some form of humongous uuid in string form

  415. mathieui

    so it’s like thrice the size for no entropy gain

  416. Zash

    Uuid + hmac(key, uuid) IIRC

  417. mathieui

    but why

  418. dwd

    So you can detect forged responses and bounces, I imagine.

  419. Ge0rG

    Except nobody does it.

  420. Ge0rG

    I've looked into that source code before. But then I erased my memories with alcohol.

  421. adiaholic has joined

  422. dwd

    But it seems to me that the most interesting attacks based around forging responses would be based around witnessing an existing outbound and just copying the ID, which isn't affected by whether or not the id is signed.

  423. Ge0rG


  424. Ge0rG

    IIRC I did a benchmark of "who does the longest message IDs" on my server, and #1 was bifrost, which stuck whole XMPP messages into the ID, for reasons nobody can anticipate, and #2 was profanity

  425. mukt2 has left

  426. menel has joined

  427. floretta has joined

  428. jonas’


  429. goffi has joined

  430. edhelas

    time to to XMPP stanza over XMPP messages ids

  431. edhelas


  432. stp has joined

  433. dwd

    Years ago, a security audit on some stuff I did decided the id space was a side-channel attack. (As were arbitrary XML attributes etc).

  434. dwd

    I mean, it's fair enough, but in cases where that matters you need a protocol break anyway.

  435. adiaholic has left

  436. Wojtek has joined

  437. mukt2 has joined

  438. adiaholic has joined

  439. pasdesushi has joined

  440. pasdesushi has left

  441. pasdesushi has joined

  442. adiaholic has left

  443. pasdesushi has left

  444. adiaholic has joined

  445. Zash has left

  446. Zash has joined

  447. Zash has left

  448. Zash has joined

  449. pasdesushi has joined

  450. pasdesushi has left

  451. mukt2 has left

  452. govanify has left

  453. adiaholic has left

  454. govanify has joined

  455. mukt2 has joined

  456. adiaholic has joined

  457. pasdesushi has joined

  458. adiaholic has left

  459. pasdesushi has left

  460. pasdesushi has joined

  461. pasdesushi has left

  462. pasdesushi has joined

  463. adiaholic has joined

  464. strypey has joined

  465. strypey has left

  466. menel has left

  467. pasdesushi has left

  468. menel has joined

  469. adiaholic has left

  470. adiaholic has joined

  471. papatutuwawa has left

  472. adiaholic has left

  473. pasdesushi has joined

  474. adiaholic has joined

  475. pasdesushi has left

  476. pasdesushi has joined

  477. pasdesushi has left

  478. pasdesushi has joined

  479. pasdesushi has left

  480. pasdesushi has joined

  481. pasdesushi has left

  482. pasdesushi has joined

  483. adiaholic has left

  484. mukt2 has left

  485. pasdesushi has left

  486. floretta has left

  487. adiaholic has joined

  488. adiaholic has left

  489. chronosx88 has left

  490. chronosx88 has joined

  491. mukt2 has joined

  492. eric has left

  493. eric has joined

  494. floretta has joined

  495. pasdesushi has joined

  496. mukt2 has left

  497. mukt2 has joined

  498. pasdesushi has left

  499. jubalh has joined

  500. mdosch


  501. mdosch

    > Our brilliant plan to make Profanity famous among the XMPP community was a huge success. > Profanity became a constant hit for discussions in the community. Everybody was and is talking about its huge IDs. > Now that we have achieved making people aware of Profanitys existence it's time to make them love Profanity. > So let's have shorter IDs.

  502. Zash

    "If you want an answer on the Internet, post the wrong answer first."

  503. pasdesushi has joined

  504. edhelas

    the community manager of Profanity Inc. is a genius

  505. edhelas

    i propose that the XSF hire him

  506. Andrzej has joined

  507. floretta has left

  508. DebXWoody

    #1520 \o/ We will be seen by movim :-)

  509. adiaholic has joined

  510. Andrzej has left

  511. Andrzej has joined

  512. mukt2 has left

  513. pasdesushi has left

  514. Andrzej has left

  515. Andrzej has joined

  516. ti_gj06 has left

  517. Kev

    Certainly the best issue I’ve read today.

  518. derwin has joined

  519. ti_gj06 has joined

  520. lovetox has left

  521. Andrzej has left

  522. pasdesushi has joined

  523. ti_gj06 has left

  524. floretta has joined

  525. ti_gj06 has joined

  526. lovetox has joined

  527. deuill has left

  528. pasdesushi has left

  529. deuill has joined

  530. deuill

    Another one for XMPP2

  531. mukt2 has joined

  532. pasdesushi has joined

  533. pasdesushi has left

  534. Andrzej has joined

  535. alameyo has left

  536. adiaholic has left

  537. adiaholic has joined

  538. alameyo has joined

  539. mukt2 has left

  540. mukt2 has joined

  541. adiaholic has left

  542. alameyo has left

  543. Andrzej has left

  544. mukt2 has left

  545. adiaholic has joined

  546. millesimus has left

  547. mukt2 has joined

  548. Andrzej has joined

  549. steffen has left

  550. jubalh

    Hi guys

  551. Zash


  552. jubalh

    Profanity actually used UUIDs before. We later added an identifier (instance id + barejid) and hashed that together with an uuid and take a base64 from it. The reason for this was that we didn't have any database and we used this to filter messages in MUCs.

  553. Ge0rG

    that sounds like insanity

  554. jubalh

    And yeah I just used a UUID instead of a shorter value to hash together because I was lazy and the XEP didn't forbid it :)

  555. Zash

    The XEP‽

  556. jubalh

    I mean no rfc or XEP said anything (to my knowledge) about the length of an ID

  557. Andrzej has left

  558. Zash

    Maybe every RFC and XEP should have the text "Use your common sense." somewhere.

  559. mathieui

    jubalh, I am curious though, apart from the hack with the hmac, what is the base64 for?

  560. Ge0rG

    mathieui: because base-16 is not sufficiently inefficient

  561. Ge0rG

    so it needs to be wrapped

  562. jubalh

    Zash: it was not about common sense. It was about having few time and solving an issue quickly ;)

  563. jubalh

    mathieui: I don't remember right now. Maybe it had to do with using barejid or something and the allowed values? Not sure anymore.

  564. jubalh

    I'll read the code in the next days and change that. We also have a DB now so we could actually check in there if we send the message ourselves.

  565. jubalh

    And the part about making Profanity famous is half-true too :) Because I knew (and more people brought it to my attention) pretty long value and devs will notice ;)

  566. Ge0rG

    I noticed.

  567. jubalh


  568. Ge0rG

    Other people noticed too.

  569. jubalh

    I love you too Ge0rG :)

  570. mathieui

    Ge0rG, you did not complain hard enough!

  571. Ge0rG

    I even spent ~half an hour trying to understand what devil has ridden you for doing it this way

  572. moparisthebest

    > Zash: it was not about common sense. It was about having few time and solving an issue quickly ;) amen brother

  573. Ge0rG

    mathieui: I did, but probably in the wrong place

  574. mathieui

    But having the messages not display in movim because the DB field for the ID is too short was certainly more fun

  575. Zash

    Don't trust remote IDs?

  576. jubalh

    Isn't having a limit length for IDs in the DB even more wrong? :) There is no max length defined AFAIK

  577. moparisthebest

    a way to send messages that only display in certain clients you say mathieui ? nice attack

  578. mathieui

    jubalh, edhelas trusted "common sense", and having an index on a TEXT column is meh

  579. Ge0rG

    also relevant here: https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html#:~:text=The%20index%20key%20prefix%20length,REDUNDANT%20or%20COMPACT%20row%20format.

  580. jubalh

    i never trust common sense. I have seen all kinds of IDs so our DB doesnt limit it for example. There are some clients that start from 1 and increase their IDs upon each message. If you restart they start from 1 again. I think Pidgin did something funny too (at one point)

  581. mathieui

    jubalh, is it still the case though? (for the increasing onces) I though every client switched to some kind of uuid

  582. Ge0rG

    jubalh: yeah, that was funny.

  583. Ge0rG

    mathieui: BWAHAHAHA

  584. Ge0rG


  585. mathieui

    let me dream Ge0rG

  586. mathieui

    you evil man

  587. millesimus has joined

  588. mukt2 has left

  589. Zash

    Why did I even click a link to MySQL docs‽

  590. jubalh

    mathieui: I'm not sure. I just remember seeing it. And I think Profanity was using the increasing IDs too. And one of my first contributions was to switch it to UUIDs if I remember correctly.

  591. Ge0rG

    there was a "nice" bug in bifröst, where its xmpp backend de-duplicated stanzas based on their ID, and presence stanzas that didn't have an ID got into the same deduplication slot and were dropped

  592. Ge0rG

    smack will use $random_prfix-$autoincrement

  593. Kev

    ids do have a max length, BTW.

  594. Andrzej has joined

  595. Zash

    Kev, ~10MB?

  596. Ge0rG

    Kev: where is it defined? In XML?

  597. jubalh

    Kev: which is? And where is it written?

  598. Kev

    Because a stanza is allowed to have a max length of anything down to 10k, it means an id can’t be longer than that, less the rest of the stanza ;)

  599. jubalh

    you see guys. So Profanity is all good. Maybe we should stay as is then :)

  600. Kev

    I’d say you had a bit more room to play with, even.

  601. jubalh

    I'll think of something

  602. Zash

    (unique stream-id + counter), Ge0rG? Like the thing we keep mentioning as The Best Thing? 🙂

  603. Ge0rG

    Kev: there is no upper limit on the upper limit for stanza sizes, so technically it's unbounded.

  604. Kev


  605. Ge0rG

    Zash: not quite.

  606. mathieui

    jubalh, tbh if you get the binary uuid & hash and encode it in ascii85 (instead of picking the ascii repr and growing it with base64) you would fit easily into most lower limits without losing information :p

  607. Zash


  608. adiaholic has left

  609. adiaholic has joined

  610. steffen has joined

  611. Ge0rG

    Zash: https://github.com/igniterealtime/Smack/blob/48f5e349b9a318ba2a1d82aef9fa069e62da10bb/smack-core/src/main/java/org/jivesoftware/smack/packet/id/StandardStanzaIdSource.java#L30

  612. Zash

    Ge0rG, so, per process?

  613. pjn has left

  614. pjn has joined

  615. Ge0rG

    Zash: yes

  616. ti_gj06 has left

  617. adiaholic has left

  618. adiaholic has joined

  619. Andrzej has left

  620. deuill

    Perhaps the there can/should be an XEP that provides some sort of best practice for ID generation? There's been a number of advances over UUID algorithms that avoid clashes while retaining sortability.

  621. Zash

    deuill, are you volunteering? 😉

  622. deuill

    Twitter Snowflake IDs were, I think, the first of their kind, but others have emerged since.

  623. Ge0rG

    deuill: yes, and that XEP should be RFC6120'

  624. Zash

    I looked at those. Also LUID and various variants of concat(timestamp, random)

  625. jonas’


  626. Zash

    [IDLU]{4} 🤷️

  627. mathieui


  628. deuill

    Actually, maybe that's a good way for me to contribute. What I can't tell is why the original RFC says stanzas SHOULD have a unique ID assigned (not MUST?). I need to re-read those passages.

  629. Zash

    For fire-and-forget, who cares what the ID is

  630. deuill

    I think some of these algorithms assume Infinite computational power as well, or at least cycles to spare.

  631. deuill

    Conversations apparently tries to de-dup based on ID (even empty IDs)? People's definition of fire-and-forget may vary lol

  632. Zash

    Here's a start: ``` xeps$ pandoc -t ./tools/2xep.lua >inbox/best-id.xml <<. > % Best practices for stanza IDs > > Use UUIDv4. > . ```

  633. Aleksej has joined

  634. Zash runs away and hides `base64url(random.bytes(12))`

  635. Aleksej has left

  636. deuill

    Co-Authored-By: Alex P

  637. deuill

    Thanks Zash

  638. Calvin has joined

  639. Ge0rG

    jonas’: I didn't make a github PR for the CVE formatting back then, but I'd still love to move forward with it.

  640. Ge0rG

    jonas’: with your Editor hat on, what do you suggest me to do next?

  641. jonas’

    Ge0rG, remove the background color, make a PR?

  642. Ge0rG

    jonas’: but I like the background color!

  643. Zash

    Does anyone know offhand where it says that 128 bit IDs should be enough until the end of time, for use as reference?

  644. Zash

    (UUID is less because version numbers and stuff tho)

  645. jonas’

    Ge0rG, I don’t, it makes for a lack of contrast. And if even *I* find the contrast lacking, any a11y tool will throw it in your face.

  646. Freddy has left

  647. jonas’

    Zash, we use 128 bit strength for cryptography, suggesting that you cannot reasonably brute-force a 128 bit thing

  648. Zash

    jonas’, cargo cult?

  649. deuill

    (Tangentially related but this was an interesting comparison of GUID algorithms, albeit all implemented in Go: https://blog.kowalczyk.info/article/JyRZ/generating-good-unique-ids-in-go.html)

  650. jonas’

    Zash, https://crypto.stackexchange.com/a/48669/16902

  651. hamish has left

  652. Ge0rG

    jonas’: you only disliked the contrast to the links, right? Can I make the links red-colored in the cve box to satisfy you?

  653. jonas’

    Ge0rG, no

  654. jonas’

    also the text<->background was lacking IMO

  655. jonas’

    but I may be misremembering

  656. jonas’

    you could refresh my memory with a screenshot

  657. Ge0rG

    jonas’: https://op-co.de/tmp/xep-template.html#example-1

  658. jonas’

    so red-on-red would definitely make this worse

  659. jonas’

    and yeah, weave is contrast-error marking all of that

  660. jonas’

    ok, the black-on-red not, but green-on-red it doesn’t like

  661. mukt2 has joined

  662. Ge0rG

    jonas’: I've reduced contrast of the red, can you shift+reload

  663. Ge0rG

    maybe you still have my old version cached

  664. Zash

    jonas’, IIRC even counting to 2⁶⁴ in boil-the-oceans levels, but for IDs it's more about the chances of accidentally generating the same ID twice during the lifetime of the scope.

  665. jonas’

    Ge0rG, same

  666. jonas’

    z https://en.wikipedia.org/wiki/Birthday_attack#Mathematics

  667. Zash

    jonas’, IIRC even counting to 2⁶⁴ is boil-the-oceans levels, but for IDs it's more about the chances of accidentally generating the same ID twice during the lifetime of the scope.

  668. jonas’

    Zash, https://en.wikipedia.org/wiki/Birthday_attack#Mathematics

  669. Ge0rG

    jonas’: maybe it's because the default text color is #444

  670. Zash

    Oh look, it has a table

  671. jonas’

    Ge0rG, it’s complaining about the coloured text, not about the grayscale text

  672. hamish has joined

  673. Ge0rG

    jonas’: another shift-reload?

  674. jonas’

    I don’t see the link as link anymore

  675. jonas’

    looks black to me

  676. xecks has left

  677. jonas’

    (but weave is happy about the contrast… which is pointless though)

  678. jonas’

    welcome to the world of making an accessible thing.

  679. Ge0rG

    jonas’: is your monitor calibrated?

  680. jonas’

    do I need a calibrated monitor to read XEPs?

  681. xecks has joined

  682. Ge0rG

    jonas’: you need a calibrated monitor to complain about lack of contrast ;)

  683. jonas’

    no, I don’t

  684. Ge0rG

    jonas’: I *really* want that reddish background, because without it just looks naked

  685. jonas’

    sorry for your loss

  686. papatutuwawa has joined

  687. jonas’

    I won’t accept a reddish background just because you prefer it if it renders XEPs less readable for people with visual deficiencies or under bad lighting conditions or whatever

  688. jonas’

    I took great care during the XEP redesign to avoid such pitfalls, I’m not going to let you ruin that ;P

  689. Ge0rG

    said the person who uses #444 instead of black for text.

  690. Ge0rG

    jonas’: shift-reload again for the naked box.

  691. Daniel

    > said the person who uses #444 instead of black for text. That's better than #666

  692. jonas’

    Ge0rG, LGTM

  693. Ge0rG

    Le Sigh.

  694. Ge0rG

    now how do I add a huge red warning sign there?

  695. jonas’

    but I knew that already, I tested your design with background-color disabled and was immediately happy

  696. Ge0rG

    so we can't both be happy, right?

  697. jonas’


  698. Ge0rG

    well, I can be happy if that box has a huge red ⚠️ in the left, but I don't know how to make it

  699. jonas’

    Ge0rG, you need to do something with <img/> or background-image

  700. steffen has left

  701. Kev

    Why should we be making these things prominent anyway?

  702. jonas’

    to get a warning sign without disturbing a11y tools

  703. Kev

    Security considerations aren’t, for example.

  704. Sam

    Yah, this seems like something to be aware of but not something that you absolutely definitely must see at all costs (as opposed to security considerations which are that)

  705. Sam

    These are just non-normative examples of what can go wrong.

  706. jonas’

    and examples of where the security considerations have been ignored, so placing them really prominently is something I’d deem useful

  707. Ge0rG

    What jonas’ said

  708. Sam

    Prominent placement is fine, but it's not important to specifically draw the users attention to them over other things like the security considerations

  709. Ge0rG

    let's add a red background to the security considerations then!

  710. mathijs has left

  711. chronosx88 has left

  712. chronosx88 has joined

  713. jonas’

    and make them blinking /s

  714. Ge0rG

    jonas’: at least it won't complain about contrast then!

  715. Zash

    `<blink><marquee>🚨️ ⚠️ ACHTUNG!</blink></marquee>`

  716. jonas’

    so my opinion is roughly: If you don’t read the security considerations, you are a bad developer. No matter how emphasized they are compared to other sections. But there’s nothing wrong with us pointing out and highlighting exceptional cases where there are documented, wide-spread exploits because of such neglect with extra emphasis.

  717. steffen has joined

  718. Kev

    This is not a hill for me to die on, but I don’t understand why we would say the most important thing about a XEP is a section saying someone once got it wrong.

  719. Sam

    +1 ^

  720. mukt2 has left

  721. jonas’

    do you have other proposals to improve the situation that people clearly ignore security considerations?

  722. Kev

    Accept that it’s not the spec author’s responsibility, nor is it within their ability, to make implementors read the spec?

  723. Ge0rG

    write shorter specs.

  724. Ge0rG

    also: write specs that are harder to implement in insecure ways.

  725. Kev

    Focus on writing clear specs that are easy to get right.

  726. jonas’

    Kev, that’s not an improvement to the situation, only to your (our) perception of it

  727. Sam

    What Ge0rG said.

  728. jonas’

    but we can’t fix e.g. carbons and such

  729. Ge0rG

    XMPP 2.0!

  730. larma has left

  731. larma has joined

  732. Sam

    I don't think this will do what you think you're doing either though. This is just a distraction that may or may not actually have anything to do with the security considerations and may or may not actually contain anything of value that's likely to be repeated.

  733. Sam

    It's a nice thing to have, it just doesn't seem like the thing we want to drag users eyes to (and possibly away from other important normative things like security considerations)

  734. Sam

    Everyone only reads the examples and not the normative text, let's not also make them only read the CVEs and not the security considerations.

  735. jonas’

    Sam, but they’re *already* not reading the security considerations.

  736. Sam

    So don't make it worse.

  737. Sam

    It's a separate problem is what I'm saying

  738. MattJ

    I don't have full context here, and don't have time to review the entire conversation, but if this is about relevant CVEs being highlighted in XEPs, that's definitely a thing we should do

  739. Sam

    Add CVEs, that's a good idea I think. If you want to make people read the security considerations, highlight that, not the new non-normative may or may not exist or be relevant examples.

  740. adiaholic has left

  741. Ge0rG

    MattJ: it's about the format of that: https://op-co.de/tmp/xep-0280.html#security

  742. Sam

    I have no strong feelings about how this should be formatted, FWIW, I just want to suggest that adding more and more stuff isn't doing what you think it's doing.

  743. Sam

    On first impressions the one Ge0rG just linked looks great to me and is enough extra formatting.

  744. Kev

    Especially without context.

  745. mathijs has joined

  746. MattJ

    Ok, if it's just about bikeshed formatting, I definitely have other things to do... :)

  747. MattJ

    Oh no, but I can't help it... FWIW I would group all the CVEs into a single box with "The following security vulnabilities have previously been found in some implementations of this specification:"

  748. Ge0rG

    MattJ: that can be achieved by different XSLT, I'm sure.

  749. Kev

    MattJ: This isn’t all CVEs though, Jonas’ said it’s only those that were widely applicable.

  750. jonas’

    "worth highlighting" for whatever definition of that

  751. MattJ

    I didn't say "all", did I?

  752. Kev

    Oh, and exploited widely, in fact.

  753. Kev

    You didn’t, but just saying “here are some CVEs” implies it’s somewhat more exhaustive than CVEs that have been widely exploited.

  754. MattJ

    Then insert "notable" somewhere, or something. Or don't :)

  755. Kev

    Anyway, if we’re only talking about vulnerabilities that were widely exploited (which has been precisely 0 vulneralibilities that I can remember), my concerns about them being overemphasised are probably overblown.

  756. jonas’

    Kev, sorry, I didn’t mean to say "exploited"

  757. jonas’

    but widely exploitable with simple-enough PoCs

  758. Andrzej has joined

  759. jonas’

    but I am also fine with less strict constraints

  760. karoshi has left

  761. Freddy has joined

  762. flow

    listing related CVEs is probably fine, but not like https://op-co.de/tmp/xep-0280.html#security please

  763. flow

    the text of the security considerations is more improtant than the related CVEs. but the currently proposed visualization puts the focus on the CVEs

  764. Andrzej has left

  765. Andrzej has joined

  766. jonas’

    flow, see above for my rationale for that

  767. flow

    jonas’, not sure if I looked at the right rationale, at least I fail to see how this counters my argument

  768. ti_gj06 has joined

  769. jonas’

    > so my opinion is roughly: If you don’t read the security considerations, you are a bad developer. No matter how emphasized they are compared to other sections. But there’s nothing wrong with us pointing out and highlighting exceptional cases where there are documented, wide-spread exploits because of such neglect with extra emphasis.

  770. werdan has joined

  771. flow

    that is what I read. But I don't interpret this as something that argues in favor of making the CVEs visually more prominent than the security considerations

  772. flow

    if anything, be sparse with visual effects

  773. karoshi has joined

  774. jonas’


  775. flow

    It feels like Ge0rG had the changelog of a software in mind when he designed this

  776. BASSGOD has left

  777. Sam

    What flow says. I don't have strong feelings about the current formatting, but we definitely shouldn't do much more than this (stop signs and big red backgrounds and whatever was being discussed before). And even as is now I still think it will be just like examples where users automatically read the shiny things and ignore the text assuming the examples (or CVEs) cover all the things they need to know.

  778. Ge0rG

    Sam: if the people read the CVE, that's a huge win already.

  779. Sam

    I kind of doubt it in most cases, especially if it comes at the cost of ignoring the text, but maybe.

  780. Ge0rG

    Sam: as jonas’ said before, the text is already being ignored

  781. flow

    I am not sure if adding big red boxes under the text being ignored helps with that

  782. Sam

    Ge0rG: right, and this won't fix it and could make it worse.

  783. Sam

    And now the only thing they maybe look at is some random examples that may or may not actually be a good representation of the actual problems and weren't actually a part of the XEP process.

  784. flow

    If anything, a short, potentially visually featured, sentenced at the beginning of the xep that states "This XEP has Security Considerations, make sure to read them", would be better IMHO

  785. flow

    If anything, a short, potentially visually featured, sentence at the beginning of the xep that states "This XEP has Security Considerations, make sure to read them", would be better IMHO

  786. adiaholic has joined

  787. Ge0rG

    well, if they read the CVE text, the chances are higher that they'll come to the same conclusion that's implied in the security considerations

  788. Sam

    I doubt it. I'd bet most of them end up with one or two things that are mostly unrelated, or only cover one tiny part of the security considerations.

  789. BASSGOD has joined

  790. Steve Kille has left

  791. Ge0rG

    Well, the list of CVEs is evidence that the current aproach does *not* work. Let's try the alternative suggestion as an A/B test then

  792. Sam

    If that's actually the problem you're trying to solve, flow's alternative seems better.

  793. adiaholic has left

  794. Zash

    A/B tests \o/

  795. mukt2 has joined

  796. adiaholic has joined

  797. Sam

    (FWIW if we had a way to actually A/B test this that would be great, but I don't think we do)

  798. Ge0rG

    let's bikeshed A/B testing infrastructure then!

  799. Daniel

    > Well, the list of CVEs is evidence that the current aproach does *not* work. Let's try the alternative suggestion as an A/B test then Do we have evidence that the clients effected by the CVE ever read the xeps?

  800. jonas’

    how would the know how to enable carbons if not?

  801. Daniel

    The developers of those clients

  802. Ge0rG

    Daniel: are you saying that you can implement a XEP without reading it?

  803. Daniel

    jonas’: gajim XML console

  804. jonas’

    Daniel, please no

  805. Daniel

    Looking at other implementations

  806. jonas’

    please no.

  807. jonas’

    I’m going to get dinner now

  808. moparisthebest

    reading the xeps don't even matter, what clients/servers send/accept in practice is what matters :D

  809. jonas’

    because I can’t take that

  810. Daniel

    I'm fairly convinced that this is how a lot of those clients were developed

  811. flow

    ahh, the thought of XMPP devs not even looking briefly at XEPs when implementing them

  812. flow

    enough xsf@ for today

  813. jonas’ cries

  814. Kev

    I *know* there have been implementations of features done by looking at sent/received protocol, and not the XEPs.

  815. Kev

    That’s not even hypothetical :)

  816. Steve Kille has joined

  817. Daniel

    That's how I implemented <session/>

  818. moparisthebest

    aren't there plenty of things that are well known not to even be implementable looking at XEPs ? just "shared knowledge" stuff ?

  819. Daniel

    Didn't know what it was. Just knew that sending this magic made things work

  820. Sam

    I'd be willing to be that between what Daniel said, looking at the XEP but only at the examples, and copy/paste from Stack Overflow you'd cover over 99% of all XMPP development. I don't think I'm joking when I say that I'd put money on this.

  821. moparisthebest

    if a client dev implemented OMEMO from the XEP today they'd probably be pretty sad when they couldn't interop with a single other client ?

  822. Sam


  823. Sam

    And I'd bet that the other <1% are 99% people in this room :)

  824. moparisthebest

    there is a massive difference between what client/servers *should* accept/handle and what they actually *will* accept/handle in practice, you can't get that from looking at XEPs

  825. Ge0rG

    moparisthebest: that's actually also a statement about the horrible state of the OMEMO XEP

  826. moparisthebest

    same situation with RFCs, and everything in web-land too

  827. moparisthebest

    computers: they bad

  828. mukt2 has left

  829. mathieui

    Sam, knowing ex-coworkers who have worked on XMPP for a client website project, that probably sums up 99% of all private-sector XMPP development for people not familiar with standards, yes

  830. mathieui

    "I just loaded xmpp.js, why doesn’t it work!"

  831. moparisthebest

    when I implemented XEP-0368 in Conversations I didn't know the XSF or XEPs existed

  832. Sam

    mathieui: indeed, I was specifically thinking of a colleague at HipChat who asked me a question about the protocol and I wasn't sure off the top of my head so I said "Here, pull up RFC 6120" and their response was "wait, you actually read these things?"

  833. Sam

    Although as far as libraries go, "I just loaded <library>, it should work" seems reasonable.

  834. moparisthebest

    my reasoning was roughly: email clients are fine doing direct-tls instead of starttls without any formal specification, why not XMPP

  835. Sam

    I mean, assuming they actually called it somehow, you know what I mea.n

  836. paul has left

  837. mathieui

    Sam, well, except you need to at least know some part of the semantics and how they relate with what you want to do

  838. paul has joined

  839. Kev

    I think there’s multiple things here. * People understanding how they should learn what to do * People being willing to do stuff properly * People being competent to do stuff properly * Doing stuff properly being possible to do * Doing stuff properly being easy to do

  840. Kev

    And probably others.

  841. mathieui

    Most certainly others, yes.

  842. BASSGOD has left

  843. Sam

    mathieui: yah, I feel like that's a library design problem though. For most people I suspect they want to call conn = xmpp.Connect("domain.com"); conn.SendMessage("Hi") or something. I really want to eventually get my own stuff to that point

  844. Zash

    Do we need to stick "The Official XMPP $Language SDK" sticker on some libraries?

  845. Kev

    I think it’s unduly naive to think we can have much influence over some of those, and showing that people aren’t getting it Right doesn’t, in itself, mean that if we just shout at them louder it’ll get better.

  846. Sam

    What Kev said.

  847. debacle has left

  848. Kev

    OTOH, some of them (particularly the last two, but also the first) are entirely within our remit.

  849. mathieui

    Sam, well, if I remember correctly it was something like they did not expose bosh or websocket in their ejabberd container

  850. mukt2 has joined

  851. goffi has left

  852. Sam

    Fair; ops is hard no matter what.

  853. moparisthebest

    and don't get me wrong XEPs are super valuable and we should cram all the relevant info needed in them, if only for a place to point to other than "look what client X does" which sucks

  854. moparisthebest

    still, many times you have to dig into what X does, and assume many/most people use this instead of XEPs on how to learn it

  855. adiaholic has left

  856. moparisthebest

    TLS had the same problem with people hardcoding version numbers right?

  857. moparisthebest

    "it works for the current input" not realizing it'd break on 1.3, 1.3 ended up working around it entirely

  858. adiaholic has joined

  859. debacle has joined

  860. BASSGOD has joined

  861. paul has left

  862. paul has joined

  863. derwin has left

  864. derwin has joined

  865. derwin has left

  866. derwin has joined

  867. Andrzej has left

  868. paul has left

  869. paul has joined

  870. adiaholic has left

  871. arcxi has left

  872. arcxi has joined

  873. papatutuwawa has left

  874. arcxi has left

  875. arcxi has joined

  876. arcxi has left

  877. arcxi has joined

  878. peetah has left

  879. paul has left

  880. paul has joined

  881. paul has left

  882. paul has joined

  883. mukt2 has left

  884. Andrzej has joined

  885. moparisthebest

    https://mastodon.xyz/@nextcloud/106058947562901204 :)

  886. peetah has joined

  887. BASSGOD has left

  888. mukt2 has joined

  889. arcxi has left

  890. adiaholic has joined

  891. arcxi has joined

  892. debacle has left

  893. debacle has joined

  894. BASSGOD has joined

  895. adiaholic has left

  896. arcxi has left

  897. arcxi has joined

  898. BASSGOD has left

  899. mukt2 has left

  900. werdan has left

  901. BASSGOD has joined

  902. ti_gj06 has left

  903. mukt2 has joined

  904. adiaholic has joined

  905. papatutuwawa has joined

  906. mathijs has left

  907. mathijs has joined

  908. mukt2 has left

  909. BASSGOD has left

  910. adiaholic has left

  911. adiaholic has joined

  912. mukt2 has joined

  913. adiaholic has left

  914. paul has left

  915. adiaholic has joined

  916. BASSGOD has joined

  917. mukt2 has left

  918. adiaholic has left

  919. karoshi has left

  920. karoshi has joined

  921. mukt2 has joined

  922. pasdesushi has joined

  923. BASSGOD has left

  924. Andrzej has left

  925. Wojtek has left

  926. BASSGOD has joined

  927. adiaholic has joined

  928. Yagiza has left

  929. adiaholic has left

  930. arcxi has left

  931. pasdesushi has left

  932. pasdesushi has joined

  933. papatutuwawa has left

  934. pasdesushi has left

  935. mukt2 has left

  936. BASSGOD has left

  937. adiaholic has joined

  938. BASSGOD has joined

  939. adiaholic has left

  940. ti_gj06 has joined

  941. BASSGOD has left

  942. BASSGOD has joined

  943. hamish has left

  944. hamish has joined

  945. LNJ has left

  946. Syndace has left

  947. Syndace has joined

  948. chronosx88 has left

  949. arcxi has joined

  950. pasdesushi has joined

  951. goffi has joined

  952. BASSGOD has left

  953. murabito has joined

  954. mukt2 has joined

  955. BASSGOD has joined

  956. murabito has left

  957. neshtaxmpp has left

  958. lovetox_ has joined

  959. Syndace has left

  960. chronosx88 has joined

  961. Syndace has joined

  962. adiaholic has joined

  963. lovetox_ has left

  964. mathijs has left

  965. lovetox_ has joined

  966. lovetox_ has left

  967. lovetox_ has joined

  968. adiaholic has left

  969. LNJ has joined

  970. BASSGOD has left

  971. andy has left

  972. Syndace has left

  973. Syndace has joined

  974. alameyo has joined

  975. BASSGOD has joined

  976. Syndace has left

  977. Syndace has joined

  978. arc has joined

  979. arc has left

  980. arc has joined

  981. goffi has left

  982. arc has left

  983. arc has joined

  984. alameyo has left

  985. arc has left

  986. arc has joined

  987. arc has left

  988. arc has joined

  989. chronosx88 has left

  990. chronosx88 has joined

  991. arc has left

  992. arc has joined

  993. arc has left

  994. arc has joined

  995. arc has left

  996. arc has joined

  997. neshtaxmpp has joined

  998. mukt2 has left

  999. lovetox_ has left

  1000. ti_gj06 has left

  1001. Aleksej has joined

  1002. Adi has left

  1003. arc has left

  1004. arc has joined

  1005. arc has left

  1006. mukt2 has joined

  1007. arc has joined

  1008. arc has left

  1009. arc has joined

  1010. Aleksej has left

  1011. Maranda has left

  1012. arc has left

  1013. Aleksej has joined

  1014. arc has joined

  1015. Maranda has joined

  1016. Tobias has left

  1017. menel has left

  1018. arc has left

  1019. arc has joined

  1020. arc has left

  1021. arc has joined

  1022. eevvoor has left

  1023. Adi has joined

  1024. chronosx88 has left

  1025. chronosx88 has joined

  1026. DebXWoody has left

  1027. alameyo has joined

  1028. arc has left

  1029. arc has joined

  1030. arc has left

  1031. arc has joined

  1032. Seve has left

  1033. DebXWoody has joined

  1034. mathijs has joined

  1035. pasdesushi has left

  1036. pasdesushi has joined

  1037. DebXWoody has left

  1038. pasdesushi has left

  1039. pasdesushi has joined

  1040. steffen has left

  1041. pasdesushi has left

  1042. pasdesushi has joined

  1043. arc has left

  1044. arc has joined

  1045. arc has left

  1046. arc has joined

  1047. pasdesushi has left

  1048. lorddavidiii has left

  1049. pasdesushi has joined

  1050. adiaholic has joined

  1051. arc has left

  1052. arc has joined

  1053. BASSGOD has left

  1054. arc has left

  1055. arc has joined

  1056. croax has left

  1057. pasdesushi has left

  1058. pasdesushi has joined

  1059. pasdesushi has left

  1060. pasdesushi has joined

  1061. adiaholic has left

  1062. alameyo has left

  1063. BASSGOD has joined

  1064. pasdesushi has left

  1065. bean has left

  1066. alameyo has joined

  1067. pasdesushi has joined

  1068. pasdesushi has left

  1069. pasdesushi has joined

  1070. hamish has left

  1071. hamish has joined

  1072. pasdesushi has left

  1073. sebastian has left

  1074. pasdesushi has joined

  1075. pasdesushi has left

  1076. rdelaage has left

  1077. dos1 has left

  1078. antoine has left

  1079. superkuh has left

  1080. pasdesushi has joined

  1081. pasdesushi has left

  1082. pasdesushi has joined

  1083. emus has left

  1084. karoshi has left

  1085. govanify has left

  1086. govanify has joined

  1087. pasdesushi has left

  1088. pasdesushi has joined

  1089. sebastian has joined

  1090. karoshi has joined

  1091. pasdesushi has left

  1092. pasdesushi has joined

  1093. pasdesushi has left

  1094. karoshi has left

  1095. arc has left

  1096. arc has joined

  1097. karoshi has joined

  1098. rdelaage has joined

  1099. dos1 has joined

  1100. antoine has joined

  1101. superkuh has joined

  1102. arc has left

  1103. Calvin has left

  1104. arc has joined

  1105. pasdesushi has joined

  1106. pasdesushi has left

  1107. LNJ has left

  1108. arc has left

  1109. arc has joined

  1110. arc has left

  1111. arc has joined

  1112. karoshi has left

  1113. pasdesushi has joined

  1114. BASSGOD has left

  1115. arc has left

  1116. arc has joined

  1117. pasdesushi has left

  1118. pasdesushi has joined

  1119. arc has left

  1120. arc has joined

  1121. steffen has joined

  1122. karoshi has joined

  1123. pasdesushi has left

  1124. pasdesushi has joined

  1125. BASSGOD has joined

  1126. stp has left

  1127. pasdesushi has left

  1128. arc has left

  1129. arc has joined

  1130. arc has left

  1131. arc has joined

  1132. strypey has joined

  1133. strypey has left

  1134. strypey has joined

  1135. strypey has left

  1136. Calvin has joined

  1137. pasdesushi has joined

  1138. chronosx88 has left

  1139. chronosx88 has joined

  1140. hamish has left

  1141. pasdesushi has left

  1142. hamish has joined

  1143. arc has left

  1144. arc has joined

  1145. arc has left

  1146. arc has joined

  1147. arc has left

  1148. arc has joined

  1149. chronosx88 has left

  1150. chronosx88 has joined

  1151. debacle has left

  1152. arc has left

  1153. arc has joined

  1154. arc has left

  1155. arc has joined

  1156. mukt2 has left