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 Wat
  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 Why?
  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 https://www.reddit.com/r/xmpp/comments/f0el07/can_someone_explain_to_me_whats_the_point_of
  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 (don't)
  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 Huh
  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 https://upload.umbrellix.net:5281/upload/PzgVtgcc8O76UlW8/20200219_115631210.m4a
  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 nice
  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. Right
  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’ oarrr
  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