XSF Discussion - 2020-02-19

  1. pdurbin has joined

  2. pdurbin has left

  3. moparisthebest

    Do any servers support https://xmpp.org/extensions/xep-0078.html anymore?

  4. andy has left

  5. Alex has left

  6. moparisthebest

    Or might it be worth resurrecting? Since TLS is required and everyone (https world) agrees basic auth is fine, and it doesn't suffer from the "never upgradeable" problems sasl does?

  7. Ellenor Malik

    sasl is downgrade resistant

  8. moparisthebest

    And upgrade proof

  9. arc has joined

  10. karoshi has left

  11. dwd

    moparisthebest, You can get the same effect as XEP-0078 with PLAIN, and essentially the same speed with SASL2, though.

  12. matkor has left

  13. dwd

    moparisthebest, And you get to choose more secure methods than PLAIN, as well.

  14. moparisthebest

    I'm not clear on what those are, I know about "channel binding" for instance, and iirc it's been broken before and such, but assuming not who cares anyway

  15. moparisthebest

    If every http application ever can live without it, what's the point

  16. arc has left

  17. arc has joined

  18. moparisthebest

    Again, I understand not sending something plaintext across the network that can be used to login as you was absolutely critical when XMPP was written, TLS wasn't the norm then

  19. moparisthebest

    Is it valuable in a world where everything is TLS though?

  20. mukt2 has joined

  21. dwd

    HTTP applications often use OAuth, which can be done over SASL but not XEP-0078, for example.

  22. moparisthebest

    That's normally when you authenticate with a 3rd party service though right?

  23. moparisthebest

    Like, sign into this site with your GitHub account?

  24. moparisthebest

    Does anything in XMPP do that?

  25. dwd

    Yes. But that doesn't matter - point is that SASL is extensible, whereas XEP-0078 isn't.

  26. dwd

    And certainly some deployments seem to like having channel binding around, or not having plaintext password equivalents on the wire even with TLS in play.

  27. Ellenor Malik

    moparisthebest: SASL is the pinnacle

  28. moparisthebest

    Oh I get it's more extensible, it just seems 99% of the time the extra complexity and RTTs is not desirable

  29. matkor has joined

  30. moparisthebest

    Seems like 0078 should be the norm and sasl the exception nowadays I'm saying?

  31. moparisthebest

    My impression is this situation is similar to Direct TLS vs STARTLS

  32. mimi89999 has left

  33. mimi89999 has joined

  34. arc has left

  35. arc has joined

  36. mimi89999 has left

  37. mimi89999 has joined

  38. arc has left

  39. arc has joined

  40. lskdjf has left

  41. mimi89999 has left

  42. mimi89999 has joined

  43. mimi89999 has left

  44. mimi89999 has joined

  45. mimi89999 has left

  46. mimi89999 has joined

  47. lskdjf has joined

  48. lskdjf has left

  49. mukt2 has left

  50. andrey.g has left

  51. pdurbin has joined

  52. adiaholic has joined

  53. Max has left

  54. pdurbin has left

  55. Max has joined

  56. mukt2 has joined

  57. Yagiza has joined

  58. adiaholic has left

  59. adiaholic has joined

  60. adiaholic has left

  61. adiaholic has joined

  62. arc has left

  63. arc has joined

  64. pdurbin has joined

  65. arc has left

  66. arc has joined

  67. pdurbin has left

  68. mukt2 has left

  69. Nekit has joined

  70. adiaholic has left

  71. karoshi has joined

  72. andy has joined

  73. adiaholic has joined

  74. lorddavidiii has joined

  75. andrey.g has joined

  76. serge90 has left

  77. Max has left

  78. Max has joined

  79. Tobias has joined

  80. mukt2 has joined

  81. paul has joined

  82. pdurbin has joined

  83. LNJ has joined

  84. serge90 has joined

  85. LNJ has left

  86. LNJ has joined

  87. LNJ has left

  88. LNJ has joined

  89. mukt2 has left

  90. pdurbin has left

  91. arc has left

  92. arc has joined

  93. j.r has left

  94. mukt2 has joined

  95. debxwoody has joined

  96. mukt2 has left

  97. j.r has joined

  98. mukt2 has joined

  99. waqas has left

  100. debxwoody has left

  101. adiaholic has left

  102. adiaholic has joined

  103. mukt2 has left

  104. serge90 has left

  105. flow

    moparisthebest, I think SASL PLAIN is the same (or at least close to xep78) in terms of complexity and round trips

  106. nyco-2 has joined

  107. nyco-2 has left

  108. mimi89999 has left

  109. nyco-2 has joined

  110. mimi89999 has joined

  111. serge90 has joined

  112. flow

    dwd, what's the benefit, besides feature discovery maybe, of "simple json" compared to xep335?

  113. flow

    and will I find an answer ot this question by carefully reading the simple json XEP?

  114. dwd

    I think so. How would a developer go about using 335? Would it involve more code than simple json?

  115. dwd

    The comparison isn't between simple json and raw 335, it's between simple json and stuffing json in directly into message bodies.

  116. ellenor has left

  117. Ellenor Malik has left

  118. sonny has joined

  119. ellenor has joined

  120. Ellenor Malik has joined

  121. mukt2 has joined

  122. adiaholic has left

  123. adiaholic has joined

  124. emus has joined

  125. lorddavidiii has left

  126. lorddavidiii has joined

  127. andrey.g has left

  128. mukt2 has left

  129. mukt2 has joined

  130. Daniel

    Isn't the comparison between stuffing json anywhere and explaining people what the x in xmpp stands for?

  131. Marc has left

  132. Marc has joined

  133. goffi has joined

  134. dwd

    Pretty much.

  135. mukt2 has left

  136. dwd

    But I do understand that "Here is a protocol framework. Now off you go and design a protocol and implement it in multiple libraries" is quite a steep learning curve.

  137. Dele Olajide has joined

  138. Ge0rG

    HTTP REST is even less than a protocol framework.

  139. Ge0rG still isn't over that app downloading 780KB of HTML from Google Play on each launch just to check if it's up-to-date.

  140. dwd

    Ge0rG, Yes, but you just stuff JSON into named endpoints and you're done.

  141. dwd

    Ge0rG, And moreover, even if you do download 780k, it won't damage the network. Whereas stuffing JSON into <body/> does, since naive clients can't be used anymore.

  142. Ge0rG

    League of Legends used to stuff XML into the body, which of course was encoded.

  143. mukt2 has joined

  144. dwd

    Novel, at least.

  145. Ge0rG

    I think it's been in use a decade ago.

  146. Ge0rG

    > Release: October 27, 2009

  147. mukt2 has left

  148. goffi has left

  149. goffi has joined

  150. goffi has left

  151. goffi has joined

  152. Max has left

  153. Max has joined

  154. DebXWoody has left

  155. Dele Olajide has left

  156. Dele Olajide has joined

  157. mimi89999 has left

  158. Alex has joined

  159. mukt2 has joined

  160. lorddavidiii has left

  161. Alex has left

  162. Alex has joined

  163. lorddavidiii has joined

  164. Alex has left

  165. Alex has joined

  166. Alex has left

  167. Alex has joined

  168. Alex has left

  169. DebXWoody has joined

  170. mukt2 has left

  171. Alex has joined

  172. Dele Olajide has left

  173. mukt2 has joined

  174. mimi89999 has joined

  175. arc has left

  176. arc has joined

  177. Dele Olajide has joined

  178. goffi has left

  179. nyco-2 has left

  180. nyco-2 has joined

  181. nyco-2 has left

  182. nyco-2 has joined

  183. goffi has joined

  184. APach has left

  185. larma has left

  186. ralphm

    Ge0rG, there's no last-modified/etag check upon retrieval?

  187. lskdjf has joined

  188. Ge0rG

    ralphm: the code is straight from https://stackoverflow.com/a/36509726/539443

  189. Ge0rG

    It's surprising that almost none of the http client libraries actually supports local caching

  190. Ge0rG

    so you end up doing it manually, badly. if at all

  191. DebXWoody has left

  192. ralphm

    That's pretty terrible indeed.

  193. larma has joined

  194. ralphm

    I.e. I can't get over how little people know about stuff like this, and always get this wrong.

  195. ralphm

    Especially when people were still doing RSS aggregators.

  196. Ge0rG

    Hey, encoding a bet on Google not changing their HTML into your app is also a rather dumb decision

  197. APach has joined

  198. Ge0rG

    Luckily, the app's API designers were competent at least.

  199. ralphm

    I guess

  200. nyco-2 has left

  201. nyco-2 has joined

  202. DebXWoody has joined

  203. mukt2 has left

  204. mukt2 has joined

  205. nyco-2 has left

  206. nyco-2 has joined

  207. larma has left

  208. andrey.g has joined

  209. Max has left

  210. Max has joined

  211. larma has joined

  212. MattJ

    should iq type="get" *never* have side-effects?

  213. MattJ

    Because we have an example of such in... RFC 6121

  214. MattJ

    Requesting the roster "subscribes" you to roster pushes

  215. Zash


  216. larma

    vanitasvitae: do XMPP libraries typically provide APIs to easily send arbitrary XML? I was under the assumption they don't make it that easy

  217. MattJ

    > If a connected resource or available resource requests the roster, it is referred to as an "interested resource". The server MUST send roster pushes to all interested resources.

  218. MattJ

    larma, totally depends on the library

  219. vanitasvitae

    larma: in Smack you could do it fairly easily I think

  220. MattJ

    Some are high level, and try to hide everything from you, some are low level and offer barely any XMPP stuff - some fall in between (you could say they fail at both)

  221. arc has left

  222. arc has joined

  223. vanitasvitae

    Yeah, in Smack you can parse the XML into a "StandardExtensionElement" and append that to your messages.

  224. larma

    vanitasvitae: that isn't what I would call an easy API

  225. vanitasvitae


  226. vanitasvitae

    PR welcome :P

  227. pep.

    MattJ, ugh (re roster). I can see why that's been done but that seems like breaking some assumptions indeed

  228. larma

    I just wonder how we are considering to add stream.send_json(to, json), when we don't have stream.send_xml(to, XML)

  229. Alex has left

  230. MattJ

    It seems obvious that 99% of the time if you request the information you are also interested in changes to that information

  231. Alex has joined

  232. pep.

    That seems like a bold assumption to make. Especially since we have mechanisms to say we're interested in the data

  233. Alex has left

  234. Link Mauve

    pep., they wouldn’t be atomic.

  235. Alex has joined

  236. pep.

    what do you mean

  237. Link Mauve

    pep., caps to your server may be known to your server long after you’ve requested the roster.

  238. Link Mauve

    In the meantime, you would miss roster pushes.

  239. pep.

    Seems like an edge-case no? Or maybe there's something missing for this kind of case (subscribing to data around bind)

  240. MattJ

    Atomic get-and-subscribe is quite an important operation to have

  241. mukt2 has left

  242. pep.

    Yes but it this really what we want for iq type="get"? :x

  243. pep.

    Does that mean because I've requested somebody's version I want to know now everytime they change

  244. mukt2 has joined

  245. MattJ

    The XEP doesn't specify that behaviour, so no, it doesn't mean that

  246. MattJ

    It means instead that you have to poll if you ever do want that :)

  247. lorddavidiii has left

  248. lorddavidiii has joined

  249. dwd

    larma, Most libraries let you send/receive arbitrary XML, in various ways that are individually reasonably sane. The problem is that they're all radically different from one another and involve a lot of implied knowledge to use well.

  250. larma

    Yeah, but we are we then not unifying/easying the use of custom XML in XMPP and instead only unify/ease the use of custom JSON in XMPP?

  251. larma

    Yeah, but why are we then not unifying/easying the use of custom XML in XMPP and instead only unify/ease the use of custom JSON in XMPP?

  252. dwd

    larma, I can't think of a way to do that without essentially distilling it into "learn XMPP really good".

  253. mtavares has left

  254. dwd

    larma, Don't get me wrong; that's my preferred solution. I just think it's impractical.

  255. Dele Olajide has left

  256. larma


  257. larma

    Also, why is it required to learn xmpp really good for that?

  258. Daniel

    does anyone know of a thing that is an xmpp client on one end and a rest api on the other?

  259. Daniel

    with rest calls to send; and where you can put in (http) callbacks for notifications

  260. Daniel

    bot developers these days can’t be bothered to connect to anything not http

  261. dwd

    Daniel, Like the Prosody API, or XMPP-FTW?

  262. Daniel

    maybe. let me take a look

  263. dwd

    larma, I don't know where you'd start with trying to create a generic API. I got a lot of pushback for including the sketch in the original UDT.

  264. dwd

    Daniel, I don't know how maintained XMPP-FTW is, now. At one point it was heavily worked on by Lloyd, but he's moved onto other things and I don't know anyone else picked it up. It was, at one point, looking as if it'd merge the XML <-> JSON translations bits with stanza.io^Wjs.

  265. larma

    dwd: when searching for how to do custom XML in smack I found https://stackoverflow.com/questions/6387947/how-to-send-custom-xml-packet-using-javas-smack-api which basically says, "here is how you, but don't do it"

  266. larma

    It already starts with the requirement to define a namespace...

  267. Daniel

    dwd, yeah; probably something like mod_rest for prosody. probably a little less generic; and kinda scoped to one user (callbacks for just one user; not all users)

  268. larma

    dwd: can we at least agree that it should just be sending strings instead of json so that it can be any notation, or just strings, or base64 encoded binary, or ... Also that would allow libraries to not care about json at all (the current proposal requires libraries implementing it to at least include a json validator)

  269. Zash

    Daniel: Use case? Bots or something?

  270. Daniel

    Zash: yes bots

  271. Zash

    I'd like mod_rest to support that. Currently it's probably awkward unless you give the bot an entire domain

  272. Daniel

    Yes. Mod_rest isn't too far of from what we want to do. Except that. And except that we have only limited control over the server (don't ask) and are not running prosody

  273. dwd has left

  274. LNJ has left

  275. LNJ has joined

  276. moparisthebest

    that is generally my complaint with about every XMPP library I've ever used, they all make you jump through a series of hoops when I just want to send a String

  277. Zash

    Daniel: mod_component_client! (Connect Prosody as a 114 component to another XMPP server)

  278. Link Mauve

    Daniel, you also have mod_slack_webhooks, which AIUI lets Slack bots connect to Prosody.

  279. Zash

    moparisthebest: That's a good thing IMO. Pain to enforce well-formedness and stanza counting for 198 if you just get strings.

  280. Daniel

    Link Mauve: oh that might be interesting

  281. Zash

    We have a ton of variations of this, sending messages via http. mod_rest is kinda meant to be the one that does it all

  282. Zash

    I wonder i f this is something we wanna standardize tho, "HTTP based component/bot interface"

  283. Link Mauve

    This has been proposed at Summit, but other things took priority.

  284. moparisthebest

    Zash, so if you are building a client or, something serious it's a good thing, if you just want to experiment quickly not so much

  285. moparisthebest

    I tend to think they should be built in layers, bottom just deals with strings, slightly higher XML, over that you have your normal API that helps with things

  286. Link Mauve

    Oh, you actually meant printf XML?

  287. pep.

    larma, yeah I tend to agree with that. since it's really application specific I'm not sure why we'd restrict it to JSON, not sure why the library would fiddle with that

  288. Zash

    Sure, but I think you still wanna discourage people from sending raw strings too often.

  289. pep.

    And I don,t really see the point in specifying it anyway

  290. moparisthebest

    last night I was purposefully trying to send ridiculous things to see how servers would handle them for instance, ended up just not using any library because none of them had good support for this, so "testing" would be at least one use-case

  291. pep.

    moparisthebest, in any library it's possible to declare new tags to include as part of stanzas.. I am all for writing (better) documentation in libraries

  292. Zash

    I know in verse you can access the underlying socket and do whatever, but it's easy to compose arbitrary xml without reaching for strings

  293. Zash

    And prosody too

  294. Daniel

    Not just documentation. Also make it easier. The way slixmpp does it is horrible

  295. Daniel

    Where as prosody stuff is relatively easy to understand

  296. pep.

    Daniel, I don't disagree about slixmpp being horrible :)

  297. Daniel

    I mean for complex things prosody also gets in your way

  298. Link Mauve

    I usually found the declarative way in slixmpp (and in stanza.io and various other projects from Lance) to be quite good for extensibility.

  299. Daniel

    But for a simple I want to add a key value pair it's super easy

  300. pep.

    Link Mauve, fwiw I'm still confused when adding an ElementBase in slix

  301. Link Mauve

    Really? :/

  302. pep.

    "what attributes do I need again, and what do they do"

  303. moparisthebest

    https://github.com/moparisthebest/jDnsProxy/blob/master/xmpp-dox/src/main/java/com/moparisthebest/dns/xmpp/DnsIq.java#L41 java/smack isn't much better here

  304. Daniel

    The slack webhook thing is kinda nice

  305. Daniel

    I mean it's not exactly what we need. But it helps me understand the problem space better

  306. Dele Olajide has joined

  307. Zash

    MUC bots needing to actually join the relevant rooms is a bit awkward, the slack thing doesn't have that problem. But it's awkward in another direction instead IIRC

  308. Dele Olajide has left

  309. Dele Olajide has joined

  310. Dele Olajide has left

  311. Dele Olajide has joined

  312. adiaholic has left

  313. adiaholic has joined

  314. Yagiza has left

  315. flow

    > larma> I just wonder how we are considering to add stream.send_json(to, json), when we don't have stream.send_xml(to, XML) Probably because the data users want to send is already in json. And that does not mean that an API should (or can) not provide "sendXml(to, xml)"

  316. Zash

    send_whatever(to, mimetype, binary, data)

  317. pep.

    What Zash say

  318. pep.

    I personally don't want to include 42 parsers in my lib. Let the user validate themselves

  319. pep.

    Even though.. I'm not fond of the mimetype thing

  320. pep.

    I'd say s/mimetype/namespace/ :)

  321. flow

    > moparisthebest> that is generally my complaint with about every XMPP library I've ever used, they all make you jump through a series of hoops when I just want to send a String One of the first things Jive Software implemented in Smack ~20 years ago was an API to make that easy

  322. flow

    pep., I don't think including a parser is a necessary prerequisite for such an API

  323. flow

    Zash, binary *and* data?

  324. Zash

    flow: boolean for whether to base64 the data blob I guess

  325. flow

    ahh, is_binary (or so) then

  326. pep.

    isn't udt^WJSONthing requiring the JSON data to be validated? (well it does say "JSON", that means valid JSON)

  327. lorddavidiii has left

  328. Zash

    (mod_rest has a thing for udt already)

  329. flow

    pep., if you are prepared to receive json, then you probalby have a json parser (and validator) already available,

  330. moparisthebest

    validation sounds like the recipient's problem :P

  331. flow

    I don't think I would bundle one with smack if I where to implement something like simple json

  332. pep.

    moparisthebest, if you implement that you implement both sides

  333. pep.

    I guess

  334. moparisthebest

    s/recipient/consumer of that json data/

  335. pep.

    In any case, I don't think all of this is necessary anyway..

  336. mukt2 has left

  337. lorddavidiii has joined

  338. adiaholic has left

  339. adiaholic has joined

  340. adiaholic has left

  341. adiaholic has joined

  342. Yagiza has joined

  343. eevvoor has joined

  344. mukt2 has joined

  345. adiaholic has left

  346. adiaholic has joined

  347. Dele (Mobile) has joined

  348. adiaholic has left

  349. adiaholic has joined

  350. mukt2 has left

  351. mukt2 has joined

  352. adiaholic has left

  353. adiaholic has joined

  354. Dele Olajide has left

  355. Dele Olajide has joined

  356. Dele Olajide has left

  357. Dele Olajide has joined

  358. pdurbin has joined

  359. adiaholic has left

  360. lorddavidiii has left

  361. Dele Olajide has left

  362. Dele (Mobile) has left

  363. Dele Olajide has joined

  364. lorddavidiii has joined

  365. Dele Olajide has left

  366. Dele Olajide has joined

  367. Dele Olajide has left

  368. Dele Olajide has joined

  369. pdurbin has left

  370. Dele Olajide has left

  371. Dele Olajide has joined

  372. Dele Olajide has left

  373. pdurbin has joined

  374. Dele Olajide has joined

  375. Dele Olajide has left

  376. larma

    flow, if you don't validate that the string provided by the user is in fact valid JSON, one could argue that you are not standards compliant, because the json XEP clearly clarifies that what is in a <json> element MUST be valid JSON according to (insert reference to RFC here)

  377. flow

    larma, I didn't say that nobody should validate it. Just that it don't see it as strictly necessary to include a json validator in smack if I where to add support for something like simple json

  378. moparisthebest

    larma, is it the library's job to ensure anything sent using it is standards compliant? that sounds... very wrong?

  379. moparisthebest

    how do you develop new extensions then, for example

  380. larma

    moparisthebest, not in general, but when it provides a highly abstract API, like the send_json(to, data) I would expect it to only send standards compliant things on the wire

  381. Dele Olajide has joined

  382. Dele Olajide has left

  383. Dele Olajide has joined

  384. larma

    I also expect it to escape my strings when I do send(to, body) with body = "x < pi &&", no?

  385. Dele Olajide has left

  386. flow

    sure, but if you already ensure in a higher level that 'data' is valid json, then it only adds an unnecessary validation step if the library performs another check if data is json

  387. moparisthebest

    if the API lets me send a string I expect it to send exactly the bytes I tell it to

  388. moparisthebest

    if the API lets me send some XML object, then I expect that XML lib to do that kind of escaping

  389. flow

    I does not really hurt, but I don't see it a strict requirement for a library to perform that validation here

  390. Kev

    I suspect that's an unusual position. If would find it surprising if message->setBody(someString) required me to first escape somString.

  391. moparisthebest

    yea ^ that sounds like the second thing, some XML object that should be escaping things

  392. flow

    some goes for the receiving side

  393. Dele Olajide has joined

  394. flow

    also "escaping rules" != "validating something"

  395. eevvoor has left

  396. moparisthebest

    if all xmpp client libs refuse to send non-valid things, how are we testing that server implementations deal with bad input correctly? (or are we?)

  397. pep.

    moparisthebest, I doubt allowing to send bad input is a good API

  398. larma

    Do you think it should be allowed to do send_json("test@example.com", "urn:example:type", "Nope, I don't do JSON here")? And on the recipient side it would just provide a string. So that if people don't want to do JSON they'll just end up using that method and we have an even worse problem as right now with JSON in body

  399. pep.

    You can have escape hatches for sure in the lib

  400. pep.

    But that shouldn't be the default

  401. moparisthebest

    well sure, completely agree there

  402. Kev

    At least for Swiften the idea is that stuff you send should largely be valid, and that there's an escape hatch for shoving octets onto the wire (which will break everything).

  403. Kev

    i.e. it makes it hard to do the Wrong Thing.

  404. moparisthebest

    sounds right, no argument there

  405. calvin has joined

  406. Marc has left

  407. Marc has joined

  408. nyco-2 has left

  409. nyco-2 has joined

  410. Dele Olajide has left

  411. Dele Olajide has joined

  412. lorddavidiii has left

  413. pdurbin has left

  414. lorddavidiii has joined

  415. Wojtek has joined

  416. mukt2 has left

  417. calvin has left

  418. calvin has joined

  419. mukt2 has joined

  420. adiaholic has joined

  421. andrey.g has left

  422. mukt2 has left

  423. mukt2 has joined

  424. Nekit has left

  425. Nekit has joined

  426. Dele Olajide has left

  427. Dele Olajide has joined

  428. rion has left

  429. rion has joined

  430. david has left

  431. andrey.g has joined

  432. david has joined

  433. nyco-2 has left

  434. mukt2 has left

  435. mukt2 has joined

  436. Link Mauve

    moparisthebest, I’d also expect a library implementing JSON to not take a raw string as input, but the language representation of the JSON thing (for instance a Python dict containing lists and other dicts and strings and such), so that the user of the library couldn’t do it wrong.

  437. Link Mauve

    Of course, the raw XML extension API wouldn’t do this validation, so you could send invalid JSON using it.

  438. mukt2 has left

  439. Dele Olajide has left

  440. Dele Olajide has joined

  441. lovetox has joined

  442. Dele Olajide has left

  443. mukt2 has joined

  444. Dele Olajide has joined

  445. Dele Olajide has left

  446. Dele Olajide has joined

  447. Dele Olajide has left

  448. Dele Olajide has joined

  449. mukt2 has left

  450. Douglas Terabyte has joined

  451. Douglas Terabyte has left

  452. Douglas Terabyte has joined

  453. Dele Olajide has left

  454. Nekit has left

  455. nyco-2 has joined

  456. pdurbin has joined

  457. Douglas Terabyte has left

  458. adiaholic has left

  459. adiaholic has joined

  460. calvin has left

  461. calvin has joined

  462. pdurbin has left

  463. david has left

  464. david has joined

  465. Ellenor Malik

    Ryanair just screwed everything.

  466. Ellenor Malik

    Do I have to, like, hire Landor myself to come up with a new brand name for XMPP?

  467. Link Mauve

    Snikket it is.

  468. Ellenor Malik

    except that's not XMPP. That's a subset of XMPP

  469. Link Mauve

    How so?

  470. Ellenor Malik

    one could argue it's even a "proprietary" messenger.

  471. Link Mauve

    Good luck, but how?

  472. mukt2 has joined

  473. moparisthebest

    what? how could you argue that?

  474. jonas’

    Ellenor Malik, that’s bullshit.

  475. nyco-2 has left

  476. jonas’

    of course it’s a subset of XMPP. why would it need support for the IoT XEPs.

  477. jonas’

    and it’s all free and libre software, there’s nothing proprietary about it.

  478. Ellenor Malik

    "XMPP is not Snikket's focus."

  479. jonas’

    you misunderstood that

  480. Ellenor Malik


  481. jonas’

    MattJ explained it in more detail here: https://old.reddit.com/r/xmpp/comments/f0el07/can_someone_explain_to_me_whats_the_point_of/fgto5h0/

  482. nyco-2 has joined

  483. jonas’

    you know about that thread, so I’m assuming you are intentionally ignoring data

  484. Ellenor Malik

    > jonas’ has written: > of course it’s a subset of XMPP. why would it need support for the IoT XEPs. why do you need a whole-ass XEP for IoT anyway? the way you control IoT on IRC is just by a standard privmsg, and XMPP doesn't need to be any different

  485. nyco-2 has left

  486. Dele Olajide has joined

  487. Link Mauve

    Ellenor Malik, err, no.

  488. moparisthebest

    Ellenor Malik, my take is for developers that know to search "xmpp" there are numerous servers/clients/etc, for "users" that just want "to chat", that's what snikket seems to be targeting, it's still standard/interoperable/federating/open xmpp

  489. Link Mauve

    Encoding machine-readable stuff in the body would be utterly stupid.

  490. Ellenor Malik

    moparisthebest: the whitelabel clone of conversations is refusing to connect to under-compliant XMPP servers. to me that seems far too close to a proprietary system for anyone to be comfortable with it

  491. Link Mauve

    Ellenor Malik, you mean that your server didn’t implement XEP-0401 yet?

  492. Link Mauve

    That’s a complaint to direct to your server implementation, not to that client.

  493. Link Mauve

    That’s a complaint to direct to your server implementation, not to a client using it.

  494. Daniel

    it's also not true

  495. Daniel

    i’m fairly certain that snikket would open xmpp:anyserver.tld?register

  496. Daniel

    not sure why you would want to use snikket with non snikket servers

  497. Daniel

    but if you wanted to you could

  498. mukt2 has left

  499. moparisthebest

    if you know about non-snikket servers then snikket probably isn't for you

  500. Dele Olajide has left

  501. Dele Olajide has joined

  502. Daniel

    The amount of bullshit and conspiracy theories that go around when ever someone - who has a well established record for working in the xsf - tries something new, is unbelievable

  503. Daniel

    Happened to me with Quicksy as well

  504. jonas’

    it’s almost as if people didn’t want XMPP to change to something successful

  505. Ellenor Malik

    it's almost as if refusing to connect to slightly behind the curve servers amounts to vendor lockin

  506. jonas’

    some call it vendor lock-in, others call "providing a decent UX in a federated system"

  507. jonas’

    take it or leave it, noones forcing you

  508. jonas’

    MattJ won’t make Snikket not federate.

  509. jonas’

    I’m rather confident in that.

  510. moparisthebest

    anecdotal quicksy story, was having an argument about why xmpp was superior to everything in an IRC channel recently, and they brought up how hard it was to install Conversations and know what a JID and a server etc was, get an account, compared to Signal where you just install it and it works

  511. moparisthebest

    I said "what about Quicksy" and got "oh, hadn't seen that before, looks really nice"

  512. moparisthebest

    another one brought over to the dark side >:)

  513. jonas’ puts some cookies on the table

  514. Ellenor Malik

    if you think I'm mentally ill now, try feeding me some cookies.

  515. moparisthebest

    I'm not personally going to use Quicksy or Snikket, I already have a setup I like, but I am VERY happy to recommend them to others that do not

  516. Ellenor Malik


  517. Ellenor Malik

    > jonas’ has written: > some call it vendor lock-in, others call "providing a decent UX in a federated system" the alternative is to prompt. "The presence server you have chosen does not support all of the features of Snikket. At this stage, you have three choices. Continue connecting, and experience marginally degraded functionality (you'll still be able to chat and join conferences), pick another server (and then the client can call a few web servers in a round-robin which can recommend a few servers based on geography), or, if you know the server administrator personally, flame them and tell them to upgrade to Snikket." > take it or leave it, noones forcing you Welcome to juntist Brazil. > MattJ won’t make Snikket not federate. > I’m rather confident in that. still, makes me uncomfortable

  518. Daniel

    Ellenor Malik: can you post a screen shot of the error message where it says you can't use a certain server?

  519. Ellenor Malik


  520. calvin has left

  521. calvin has joined

  522. Ellenor Malik

    i was providing an example of an error message I would supply if the server was not fully compliant.

  523. Daniel

    No. You said earlier that snikket is doing vendor lock in. I'm asking you to provide proof for that

  524. Zash

    I just got Snikket (client) to connect to my main account on my non-snikket server that doesn't even have registration.

  525. Ellenor Malik

    Zash: oookaaayy

  526. Zash

    Had to `qrencode -t ansi 'xmpp:me@myserver.tld?register'` and uncheck a hidden checkbox tho

  527. Ellenor Malik

    that's more than a mite absurd

  528. Ellenor Malik

    I'm pretty sure on the server side snikket refers to a feature set and not a specific server

  529. moparisthebest

    yes "modern xmpp" for lack of a better term

  530. Zash


  531. jonas’

    moparisthebest, better term .... liiiike .... snikket?

  532. moparisthebest

    sure :)

  533. Ellenor Malik

    Zash: having to qrencode the registration seems more than a mite barrier to entry shaped

  534. mukt2 has joined

  535. Zash

    No, quite the opposite

  536. Ellenor Malik

    (she says, while planning a Website for her XMPP server which will do just that)

  537. Zash

    QR code with `xmpp:example.com?register` on your website would work just fine in Conversations too

  538. moparisthebest

    Ellenor Malik, have you ever instead tried to send someone a username and password over SMS or something

  539. sonny has left

  540. sonny has joined

  541. Ellenor Malik

    the main issue is getting people to transcribe domain names

  542. moparisthebest

    also the people that always capitalize the first letter of everything without telling you

  543. Dele Olajide has left

  544. Ellenor Malik

    why are we sending passwords over SMS anyway?

  545. Dele Olajide has joined

  546. moparisthebest

    I said or something :)

  547. moparisthebest

    I've done it using Silence before

  548. Ellenor Malik

    ... but why are we sending qr codes over SMS?

  549. calvin has left

  550. calvin has joined

  551. moparisthebest

    you don't

  552. Ellenor Malik

    I should probably come up with a module to an XMPP server that makes it so that users can only federate if they verify their phone number

  553. moparisthebest

    what are you going to use to verify phone number?

  554. Ellenor Malik

    that is, they can only message out of the local server

  555. jonas’

    Ellenor Malik, sounds like a plan for anti-spam in some deployments

  556. eevvoor has joined

  557. moparisthebest

    Ellenor Malik, also sounds like you are just talking about https://www.kontalk.net/

  558. Ellenor Malik

    everything that can be done by someone with a 132 iq has already been done

  559. moparisthebest

    fyi that's mostly standard xmpp too and federates

  560. moparisthebest

    last I checked he was taking out the non-standard extensions slowly

  561. Ellenor Malik

    probably preparing to shut down

  562. Ellenor Malik

    which is bad

  563. Dele Olajide has left

  564. Dele Olajide has joined

  565. dwd has joined

  566. mukt2 has left

  567. j.r has left

  568. adiaholic has left

  569. adiaholic has joined

  570. Dele Olajide has left

  571. Wojtek has left

  572. Wojtek has joined

  573. mukt2 has joined

  574. SubPub has joined

  575. arc has left

  576. arc has joined

  577. arc has left

  578. arc has joined

  579. sonny has left

  580. mukt2 has left

  581. calvin has left

  582. calvin has joined

  583. calvin has left

  584. calvin has joined

  585. j.r has joined

  586. arc has left

  587. arc has joined

  588. david has left

  589. david has joined

  590. LNJ has left

  591. mukt2 has joined

  592. Douglas Terabyte has joined

  593. rion has left

  594. rion has joined

  595. pdurbin has joined

  596. Douglas Terabyte has left

  597. pdurbin has left

  598. david has left

  599. mukt2 has left

  600. mukt2 has joined

  601. krauq has left

  602. SubPub has left

  603. david has joined

  604. Yagiza has left

  605. krauq has joined

  606. mukt2 has left

  607. mukt2 has joined

  608. MattJ

    I'm happy that most people in the community do understand the motivation behind Snikket <3

  609. MattJ

    and yes, you can connect to non-Snikket servers with the Snikket app, and yes, you can connect to a Snikket server from a non-Snikket app

  610. Marc has left

  611. Marc has joined

  612. MattJ

    But it's not advertised that way because that's not really what provides the best user experience

  613. MattJ

    and I have had to explain to multiple people who try to use Snikket with non-Snikket servers that they really really should just go and use Conversations

  614. moparisthebest

    you'd have to explain "what is XMPP" to people that *just* want a chat app

  615. MattJ

    The problem is that anyone in this room, or who even knows what XMPP is most likely is not the target audience for Snikket

  616. moparisthebest

    *eyes glaze over* thinks to self: when will this idiot shut up so I can just go install Signal

  617. MattJ

    Off to dinner now, don't worry :)

  618. moparisthebest

    haha sorry if the sarcasm wasn't implied, that's an impression of a user who just wants a chat app when you go into a "what is XMPP and why is it the best" explanation

  619. adiaholic has left

  620. Douglas Terabyte has joined

  621. MattJ


  622. !XSF_Martin

    Don't explain it, just force them to use it. 😃

  623. calvin has left

  624. debacle has joined

  625. Shell has joined

  626. mukt2 has left

  627. mukt2 has joined

  628. krauq has left

  629. Ellenor Malik

    MattJ: would it not be ideal to splash up a warning when a non-snikket compliant server is used?

  630. Ellenor Malik


  631. krauq has joined

  632. mukt2 has left

  633. LNJ has joined

  634. mukt2 has joined

  635. jonas’

    I’m halfway through writing down the (xmpp) protocol used by search.jabber.network in a proper ProtoXEP by the way.

  636. jonas’

    or rather, a cleaned up variant of that.

  637. Marc has left

  638. moparisthebest


  639. Marc has joined

  640. david has left

  641. calvin has joined

  642. kuvoh has joined

  643. kuvoh has left

  644. pep.

    for s.j.n, I'd like not to have to use HTTP btw, and some clients seemed to prefer that for possible anonymity purposes. jonas’ would it be a problem for you if servers provided anon hosts that have s.j.n whitelisted? (so potentially you could get spammed from all around)

  645. jonas’

    pep., interesting idea

  646. jonas’

    I mean, I can get spammed via HTTP already

  647. pep.


  648. jonas’

    and with tor you can make that even more fun

  649. jonas’

    I don’t block anything at the moment

  650. jonas’

    but we’ll have to write down how to behave when I reply with rate-limiting error codes

  651. kuvoh has joined

  652. jonas’

    also, see what I wrote in https://github.com/horazont/muchopper/issues/51

  653. kuvoh has left

  654. mukt2 has left

  655. moparisthebest

    <body>{"code":"502", "message":"please come back later"}</body>

  656. jonas’ stomps moparisthebest

  657. jonas’

    to make this less painful: <error type='wait'><resource-constraint xmlns='...'/><rate-limit xmlns='urn:xmpp:channel-search:0'/></error>

  658. mukt2 has joined

  659. jonas’

    moparisthebest, there’s SO MUCH wrong with that. I can only compliment you, you put a lot of triggers in just 63 bytes.

  660. jonas’

    only thing that’s missing is some unicode shenangians

  661. Alex_ has joined

  662. Alex_ has left

  663. Alex__ has joined

  664. david has joined

  665. moparisthebest

    jonas’, lol yea "how to trigger XMPP developers in only 63 characters!!!"

  666. moparisthebest

    also HTTP developers if they are paying attention

  667. lskdjf has left

  668. lskdjf has joined

  669. moparisthebest

    I guess I could have used smart quotes instead...

  670. jonas’


  671. calvin has left

  672. MattJ


  673. moparisthebest

    jonas’, just for you <body>{“code”: “502”, “message”: “please come back later”}</body>

  674. Zash

    What have you cursed us with‽

  675. Max has left

  676. mukt2 has left

  677. Max has joined

  678. calvin has joined

  679. calvin has left

  680. calvin has joined

  681. marc has left

  682. mukt2 has joined

  683. marc has joined

  684. Marc has left

  685. pdurbin has joined

  686. Shell has left

  687. Shell has joined

  688. arc has left

  689. arc has joined

  690. Shell has left

  691. pdurbin has left

  692. Shell has joined

  693. Tobias has left

  694. lovetox has left

  695. mukt2 has left

  696. lorddavidiii has left

  697. Shell has left

  698. Shell has joined

  699. mathijs has left

  700. calvin has left

  701. mukt2 has joined

  702. karoshi has left

  703. karoshi has joined

  704. Wojtek has left

  705. LNJ has left

  706. eevvoor has left

  707. LNJ has joined

  708. arc has left

  709. arc has joined

  710. mukt2 has left

  711. gav has left

  712. gav has joined

  713. pep.

    I have moved the Summit minutes (pad) to the wiki, https://wiki.xmpp.org/web/Conferences/Summit_24#Minutes

  714. pep.

    I wanted to do something a bit more elaborated, but I don't have much time so that'll do. There is still quite a few pieces missing, I'd appreciate if people present could have a look

  715. LNJ has left

  716. mukt2 has joined

  717. goffi has left

  718. Shell has left

  719. mukt2 has left

  720. pdurbin has joined

  721. sonny has joined

  722. mukt2 has joined

  723. adiaholic has joined

  724. karoshi has left

  725. Shell has joined

  726. mukt2 has left

  727. mukt2 has joined

  728. SubPub has joined

  729. emus has left

  730. adiaholic has left

  731. adiaholic has joined

  732. debacle has left

  733. debacle has joined

  734. debacle has left

  735. pdurbin has left

  736. mukt2 has left

  737. raghavgururajan has joined