XSF Discussion - 2020-04-19

  1. david has left
  2. david has joined
  3. neshtaxmpp has left
  4. karoshi has left
  5. neshtaxmpp has joined
  6. neshtaxmpp has left
  7. aj has left
  8. xsf has left
  9. xsf has joined
  10. xsf has left
  11. xsf has joined
  12. larma has left
  13. larma has joined
  14. pdurbin has joined
  15. debacle has left
  16. xsf has left
  17. xsf has joined
  18. xsf has left
  19. xsf has joined
  20. pdurbin has left
  21. xsf has left
  22. xsf has joined
  23. lskdjf has left
  24. Chobbes has joined
  25. arc has left
  26. arc has joined
  27. arc has left
  28. arc has joined
  29. neshtaxmpp has joined
  30. arc has left
  31. arc has joined
  32. arc has left
  33. arc has joined
  34. neshtaxmpp has left
  35. Daniel has left
  36. Daniel has joined
  37. xsf has left
  38. xsf has joined
  39. adiaholic_ has left
  40. adiaholic_ has joined
  41. adiaholic_ has left
  42. adiaholic_ has joined
  43. Chobbes has left
  44. neshtaxmpp has joined
  45. adiaholic_ has left
  46. adiaholic_ has joined
  47. bear has left
  48. arc has left
  49. arc has joined
  50. adiaholic_ has left
  51. adiaholic_ has joined
  52. Max has left
  53. Max has joined
  54. serge90 has left
  55. serge90 has joined
  56. bear has joined
  57. pdurbin has joined
  58. ths has joined
  59. ths has left
  60. ths has joined
  61. bear has left
  62. serge90 has left
  63. nyco has left
  64. nyco has joined
  65. neshtaxmpp has left
  66. zukzuk has left
  67. Yagiza has joined
  68. neshtaxmpp has joined
  69. rion has left
  70. rion has joined
  71. Daniel has left
  72. bear has joined
  73. xsf has left
  74. xsf has joined
  75. Daniel has joined
  76. xsf has left
  77. xsf has joined
  78. DebXWoody has joined
  79. DebXWoody has left
  80. bear has left
  81. DebXWoody has joined
  82. nyco has left
  83. mukt2 has joined
  84. mukt2 has left
  85. mukt2 has joined
  86. lovetox has joined
  87. nyco has joined
  88. mukt2 has left
  89. wurstsalat has left
  90. adiaholic_ has left
  91. adiaholic_ has joined
  92. bear has joined
  93. Daniel has left
  94. lorddavidiii has joined
  95. Daniel has joined
  96. lovetox has left
  97. paul has joined
  98. bear has left
  99. nyco has left
  100. lovetox has joined
  101. Daniel has left
  102. Daniel has joined
  103. nyco has joined
  104. mukt2 has joined
  105. mukt2 has left
  106. mukt2 has joined
  107. mukt2 has left
  108. mukt2 has joined
  109. Daniel has left
  110. Daniel has joined
  111. Daniel has left
  112. Daniel has joined
  113. Daniel has left
  114. Daniel has joined
  115. Daniel has left
  116. Daniel has joined
  117. nyco has left
  118. Daniel has left
  119. Daniel has joined
  120. bear has joined
  121. nyco has joined
  122. Daniel has left
  123. Daniel has joined
  124. goffi has joined
  125. andy has joined
  126. bear has left
  127. mukt2 has left
  128. DebXWoody has left
  129. DebXWoody has joined
  130. DebXWoody has left
  131. DebXWoody has joined
  132. Daniel has left
  133. Daniel has joined
  134. DebXWoody has left
  135. DebXWoody has joined
  136. DebXWoody has left
  137. DebXWoody has joined
  138. DebXWoody has left
  139. DebXWoody has joined
  140. DebXWoody has left
  141. DebXWoody has joined
  142. DebXWoody has left
  143. DebXWoody has joined
  144. waqas has left
  145. DebXWoody has left
  146. DebXWoody has joined
  147. matkor has joined
  148. Jeybe has joined
  149. Daniel has left
  150. Daniel has joined
  151. DebXWoody has left
  152. Jeybe has left
  153. Daniel has left
  154. Daniel has joined
  155. Jeybe has joined
  156. DebXWoody has joined
  157. DebXWoody has left
  158. DebXWoody has joined
  159. Jeybe has left
  160. Jeybe has joined
  161. Daniel has left
  162. Daniel has joined
  163. Daniel has left
  164. Daniel has joined
  165. Daniel has left
  166. Daniel has joined
  167. Tobias has joined
  168. werdan has joined
  169. Jeybe has left
  170. Jeybe has joined
  171. Daniel has left
  172. Daniel has joined
  173. neshtaxmpp has left
  174. bear has joined
  175. werdan has left
  176. Nekit has joined
  177. Daniel has left
  178. Daniel has joined
  179. mukt2 has joined
  180. Daniel has left
  181. Daniel has joined
  182. Jeybe has left
  183. Jeybe has joined
  184. Daniel has left
  185. Daniel has joined
  186. LNJ has joined
  187. arc has left
  188. arc has joined
  189. lovetox has left
  190. mukt2 has left
  191. mukt2 has joined
  192. Daniel has left
  193. Daniel has joined
  194. lovetox has joined
  195. bear has left
  196. karoshi has joined
  197. Mikaela has joined
  198. Jeybe has left
  199. Jeybe has joined
  200. edhelas has left
  201. edhelas has joined
  202. Jeybe has left
  203. Jeybe has joined
  204. Jeybe has left
  205. Jeybe has joined
  206. lovetox has left
  207. edhelas has left
  208. edhelas has joined
  209. sonny has joined
  210. lorddavidiii has left
  211. arc has left
  212. arc has joined
  213. lorddavidiii has joined
  214. Daniel has left
  215. Daniel has joined
  216. Daniel has left
  217. Daniel has joined
  218. Daniel has left
  219. Daniel has joined
  220. Daniel has left
  221. Daniel has joined
  222. Daniel has left
  223. Daniel has joined
  224. Daniel has left
  225. Daniel has joined
  226. lovetox has joined
  227. debacle has joined
  228. larma has left
  229. Daniel has left
  230. Daniel has joined
  231. Daniel has left
  232. Daniel has joined
  233. xsf has left
  234. xsf has joined
  235. Jeybe has left
  236. Jeybe has joined
  237. larma has joined
  238. wurstsalat has joined
  239. jonas’ just get snikket listed there
  240. Daniel has left
  241. Daniel has joined
  242. Ge0rG I wonder how much user meta data is stored on a matrix home server. Probably the answer will be "roughly as much as xmpp"
  243. !XSF_Martin And afaik it is stored forever.
  244. Daniel They have to please their investors somehow
  245. Daniel has left
  246. Daniel has joined
  247. Marc has joined
  248. mukt2 has left
  249. Nekit has left
  250. Nekit has joined
  251. bear has joined
  252. Jeybe has left
  253. arc has left
  254. arc has joined
  255. Jeybe has joined
  256. Daniel has left
  257. Daniel has joined
  258. Yagiza has left
  259. robertooo has joined
  260. mukt2 has joined
  261. Jeybe has left
  262. Jeybe has joined
  263. Jeybe has left
  264. Jeybe has joined
  265. Jeybe has left
  266. Jeybe has joined
  267. jubalh has joined
  268. mukt2 has left
  269. mukt2 has joined
  270. lskdjf has joined
  271. Jeybe has left
  272. Jeybe has joined
  273. bear has left
  274. Jeybe has left
  275. emus has joined
  276. arc has left
  277. arc has joined
  278. goffi has left
  279. lskdjf has left
  280. neshtaxmpp has joined
  281. DebXWoody has left
  282. lskdjf has joined
  283. DebXWoody has joined
  284. mukt2 has left
  285. bear has joined
  286. mukt2 has joined
  287. Maranda Erm didn't Riot.im stop using Matrix? Or am I confusing with something else?
  288. werdan has joined
  289. !XSF_Martin I guess you are. It is their main client.
  290. Zash The flagship Matrix client even.
  291. Yagiza has joined
  292. eevvoor has joined
  293. Maranda Zash, oh sorry confused with disroot
  294. Maranda And I can't find a client which actually uses either xep 215 or 278 to fetch sturn/turn data for A/V
  295. bear has left
  296. Maranda Jitsi which supposedly should use Jingle Relay Nodes, does SRV look ups.
  297. jonas’ Jitsi Meet does '215
  298. jonas’ but I haven’t gotten it to actually use the results…
  299. Maranda jonas’, Jitsi Meet is a bit too much OOB for my likings.
  300. Maranda Movim uses a hardcoded list of stun services which almost never work...
  301. Neustradamus Holger: https://github.com/processone/ejabberd/issues/3229
  302. j.r has left
  303. Holger Neustradamus: Do you have a client that would use this?
  304. Holger Neustradamus: E.g. the WebRTC spec explicitly doesn't support this.
  305. Holger > Jitsi Meet does '215 Only extdisco:1 though. (Dunno whether Maranda uses Prosody's mod_turncredentials which supports that.)
  306. Neustradamus Holger: I will search...
  307. Neustradamus Holger: STUN ejabberd works with IPv6?
  308. Holger Neustradamus: No.
  309. Neustradamus A ticket is needed too :/
  310. Neustradamus https://github.com/jselbie/stunserver
  311. Holger Neustradamus: Someone having time to implement such stuff is needed 🙂
  312. Maranda Holger, Metronome has mod_extdisco which supports both 1 and 2 fully (aka has support for <credentials /> queries)
  313. eevvoor has left
  314. Neustradamus Holger: Can you move my ticket in the good repository?
  315. Maranda at least in the latest commits, also I implemented jingle relay nodes tonite.
  316. Holger Maranda: Ok. I'm still hoping they'll just update to extdisco:2 as I'm not aware of another client needing :1 and don't want to spam the code with :1 support just for Meet …
  317. Maranda Holger, tbh I didn't even take Meet in consideration as on Android it looks to be not using xmpp even, it just wants some kind of URL, didn't understand how to add a xmpp account
  318. Maranda which tells much about the UX there
  319. jonas’ Maranda, yeah, the UX is pretty amazing
  320. jonas’ you only need the URL to the meeting
  321. Holger Maranda: Well it's all XMPP but without roster, yes. Different use case.
  322. Holger The XMPP account is usually an anon account.
  323. werdan has left
  324. Neustradamus Holger: I have listened a lot of remaks like it, in a server case "a client supports?" and in a client case "a server supports?" ah ah
  325. Holger Neustradamus: Really? I have not seen a single client developer saying that. I've seen the WebRTC guys explicitly stating they don't want it despite other STUN/TURN servers supporting it.
  326. Holger Neustradamus: If you have a link to any STUN/TURN client dev making such a statement I'd be interested.
  327. eta has left
  328. eta has joined
  329. Neustradamus Holger: coturn supports it :) - https://github.com/coturn/coturn/blob/master/README.md
  330. Holger Neustradamus: I know that. That's good, no? Client devs interested in it could just use that.
  331. Holger Neustradamus: And ejabberd admins interested in offering that could just set up coturn.
  332. j.r has joined
  333. mukt2 has left
  334. bear has joined
  335. adiaholic_ has left
  336. adiaholic_ has joined
  337. mukt2 has joined
  338. jubalh has left
  339. bear has left
  340. andrey.g has left
  341. lovetox has left
  342. arc has left
  343. arc has joined
  344. mukt2 has left
  345. mukt2 has joined
  346. eevvoor has joined
  347. j.r has left
  348. j.r has joined
  349. alexis has left
  350. alexis has joined
  351. jubalh has joined
  352. lovetox has joined
  353. Nekit has left
  354. jubalh has left
  355. mukt2 has left
  356. pdurbin has left
  357. eta has left
  358. eta has joined
  359. Guus Holger: unsure about the exact details of what you are proposing, and don't have the time to dig into it. However, breaking backwards compatibility of extdisco because "only Meet" does not sit well with me.
  360. Guus It's an older spec that we know has at least one fairly popular user. Who knows what we don't know about.
  361. Guus Apologies if my drive-by reading of this caused a misinterpretation of what you actually mean.
  362. bear has joined
  363. Zash Come to think of it, why wasn't http upload made on this?
  364. jubalh has joined
  365. MattJ Nice thought
  366. Zash Not an exact fit tho
  367. Holger Guus: https://github.com/jitsi/jitsi-meet/issues/5786
  368. Guus Holger: my point is that there could be other implementations that we don't know about. Breaking backwards compatibility should be avoided where possible, especially for XEPs that have been published a long time ago.
  369. Holger Guus: I.e. it's just about whether I should add support for an old (5 years) version of the XEP. I'll probably just submit a PR against Meet if they don't do it themselves. Less work than adding support for that old 0215 revision to ejabberd.
  370. mukt2 has joined
  371. Holger Guus: Sure, I'm all on your side when it comes to keeping existing support. ejabberd still does mam:tmp and all following revisions. But do you really implement each and every old revision of an XEP when adding a new module?
  372. Guus Holger: oh, no. I am fine with introducing new versions. I was under the impression you were suggesting incompatible changes to the xep without a namespace bump.
  373. Holger Guus: Ah, no not at all.
  374. Guus My bad, carry on. 😁
  375. Holger I'm implementing the current revision of the XEP which is 5 years old. My problem is just that Meet doesn't support this revision yet.
  376. Guus Openfire has a dead simple plugin that supported what Meet needed a couple of years ago.
  377. Guus Nothing after that
  378. Guus Iirx
  379. pep. Guus: that's a very broad comment which I generally disagree with, the backward compatibility one. https://tools.ietf.org/html/draft-iab-protocol-maintenance-04 (I thought there were more revisions)
  380. Guus We publish standards. People using them must be able to rely on some form of stability.
  381. edhelas has left
  382. flow pep., could you clarify with what exactly you disagree with?
  383. lovetox has left
  384. pep. keeping backwards compat forever and never deprecating anything because !!!
  385. pep. "some implementations might.."
  386. flow Holger, do you have an idea what damencho means with "port the changes" in https://github.com/jitsi/jitsi-meet/issues/5786#issuecomment-610921989
  387. Kev That's not the point, is it? The point is that if you implement X.Y, X.Y should not change such that you no longer interoperate, as I understand it. Which I agree with.
  388. Zash I got the impression that they had a fork of the Prosody plugin
  389. Kev It's fine to deprecate support for X.Y, but any X.Y implementations should interop
  390. bear has left
  391. flow pep., I don't see anything wrong with keeping backwards compat for a long period of time, as long as it does not block certain breaking changes in newer protocol versions
  392. pep. Kev: well that's the point, if you always keep backwards compat then the protocol never evolves
  393. Kev A given version of the protocol doesn't evole, that's kinda the point.
  394. flow what Kev says
  395. Guus I'm fine with breaking changes, but not without a new namespace to ensure that the old version remains unchanged/compatible
  396. Kev If you want to do new backwards-incompatible things, you signal that.
  397. pep. then you get things like "we should do bind2 / im-next"
  398. Kev Guus: Actually, usually a feature flag is preferable to a ns bump, IMNSHO.
  399. pep. there's still a migration in between that's required
  400. Guus Kev: sure. Some kind of identifying thing suffices
  401. edhelas has joined
  402. Holger flow: > Holger, do you have an idea what damencho means with "port the changes" in https://github.com/jitsi/jitsi-meet/issues/5786#issuecomment-610921989 Yes what Zash says, they have a fork of the Prosody module. The upstream module supports the current revision, their fork (and their client-side code) doesn't.
  403. pep. I'm not discussing the fact that a version doesn't change obviously. just discussing the fact that x.y doesn't have to be backwards compat with x.y+1 (note that XEPs are not following semver)
  404. flow Holger, so its about changing the code to match the xep, and not bumping the xep to match the code, right?
  405. xsf has left
  406. Holger flow: Yes.
  407. flow pep., obviously a namespace bumped xep protoocl is (typically) not compatible with the previous namespace protocl version
  408. flow if that's includes what you are expressing with x.y+1
  409. flow so I somehow think we me be all on the same page of the same book but written in different languages ;)
  410. Guus I'm thinking we're all pretty much mean the same
  411. Holger It's Sunday so we're all procrastinating to avoid family things?
  412. MattJ I think some things changed when we introduced namespace versioning
  413. flow so I somehow think we may be all on the same page of the same book but written in different languages ;)
  414. flow Holger, already did my obligatory bike ride with two kids in the trailer!
  415. MattJ In the olden days, an experimental XEP just changed
  416. flow I guess there was a reason why this is no longer the case
  417. Holger flow: 👍
  418. jonas’ MattJ, <3
  419. flow I guess there is a reason why this is no longer the case
  420. MattJ flow, "I have a cool idea - we could bump the namespace every time", which seemed like a good idea (not saying it was/wasn't), but I think this also subtly shifted expectations about an experimental XEP
  421. DebXWoody has left
  422. MattJ and possibly even contributed to the laziness about advancing them
  423. flow MattJ, part of the problem is that we have to staging area for breaking changes
  424. MattJ That used to be experimental, is basically what I'm saying
  425. MattJ which is why it's called experimental, and that status has the description text it has
  426. flow Right, and I think it shouldn't be experimental because there is a reason why this is longer the case, while I think we should introduce a staging area
  427. MattJ I think in hindsight (which nobody had back then), introducing namespace versioning should have been bundled with other changes
  428. flow there is no reason we can't have stable namespaces (urn:xmpp:foo:1) and staging namespaces (urn:xmpp:foo:2-snapshot)
  429. jonas’ Namespace "versioning" is also misleading IMO. There is no such thing as versions in XML namespaces. Changing the number there (in an, to the XML parser, opaque string) forks all elements to be entirely different.
  430. MattJ "Implementation of the protocol described herein is not recommended for production systems." made sense when the protocol was liable to change on the server side with no warning (same namespace)
  431. jubalh has left
  432. jonas’ flow, but then you can’t promote 2-snapshot to 2 without touching all pieces of software, see above
  433. MattJ jonas’, shorthand for "namespace-based versioning", i.e. versioning the protocol by bumping the namespace
  434. jonas’ MattJ, that makes much more sense, thanks
  435. flow MattJ, true, but that doesn't mean that it suddenly does not make sense to have that disclaimer for experimental
  436. flow jonas’, I think a sed would be sufficient
  437. MattJ Jitsi Meet is successful software using an experimental XEP in a production setting
  438. jonas’ flow, go and sed all existing debian packages of $client then.
  439. flow jonas’, that would make no sense
  440. MattJ Were they wrong? They haven't suffered at all, and we're discussing how to let them get away with their choice without being burnt - i.e. protecting production implementations of experimental XEPs
  441. MattJ and if we're going to protect implementations of experimental XEPs from breaking changes, we needn't have that disclaimer
  442. jonas’ flow, but then clients which implement the logic of a :2-snapshot version which is identical to :2 are unable to talk to entities only supporting :2 for no good reason.
  443. MattJ Yes, namespace bumps hurt - another thing that wasn't clear at the time, without implementation experience
  444. flow jonas’, I wouldn't expect software using -snapshot namespaces to be shipped, or at least not to be shipped with support for this explicitly enabled
  445. jonas’ flow, that’s not how it works
  446. jonas’ otherwise, software wouldn’t implement and ship Experimental XEPs by default
  447. flow because a -snapshot is for experimenting in an agile way with unstable protocol extensions
  448. Zash End users don't care about Experimental or not
  449. jonas’ flow, but then experimentation settles down and half a year later we figure out that this is the thing we want to use in the future
  450. mukt2 has left
  451. jonas’ and then it gets promoted to :2
  452. flow you'd never would want them to be available for end-users. otherwise you would risks XMPP reputation
  453. jonas’ and we can only learn that it works by deploying it
  454. jonas’ and then there’s a bunch of software running on the latest :2-snapshot from that half-a-year window which is locked out for no good reason
  455. jonas’ flow, I think we’d be more risking XMPP’s reputation by not having MAM, Carbons and other things which are in fluctuation rolled ou
  456. jonas’ flow, I think we’d be more risking XMPP’s reputation by not having MAM, Carbons and other things which are in fluctuation rolled out
  457. flow jonas’, experimental xeps a bump namespace on breaking changes are very different to -snapshot namespaces
  458. pep. > flow> so I somehow think we may be all on the same page of the same book but written in different languages ;) yes and no, it often feels like people are afraid to break anything. Not saying "break all the things!", but if there a breakage that will.make things easier/better afterwards, just do it.
  459. flow jonas’, experimental xeps with a bump namespace on breaking changes policy are very different to -snapshot namespaces
  460. flow as other said, nobody cares about if it's called experimental or not
  461. flow what matters is that the protocol identified by its namespace is interoperable.
  462. flow and that is not true for -snapshot namespaces
  463. Kev > and if we're going to protect implementations of experimental XEPs from breaking changes, we needn't have that disclaimer I think it depends on the Experimental etc.
  464. Kev It's all somewhat more nuanced than the stages suggest.
  465. flow jonas’1> flow, I think we’d be more risking XMPP’s reputation by not having MAM, Carbons and other things which are in fluctuation rolled out And i never said that I want to take that away
  466. flow but we are obviously very bad at preparing new backwards-incomptabile versions of XEPs
  467. jonas’ flow, you did by saying that -snapshot should not be delivered
  468. jonas’ or do you honestly think that carbons in its current state wouldn’t be -snapshot?
  469. flow jonas’, I think you are reading more into it than I actually said
  470. jonas’ then I must’ve completely misread 11:48:13 flow> jonas’, I wouldn't expect software using -snapshot namespaces to be shipped […] care to clarify?
  471. flow jonas’, I think there could be an upper bind in time after which -snapshot gets into a stable namesapce
  472. flow then everyone would know how long he has to get his favorite change into the new xep version
  473. mukt2 has joined
  474. flow jonas’, proposed and "accepted" changes are staged in a -snapshot namespace for x time, after that it becomes the stable namespace
  475. jonas’ what if another change happens in x time?
  476. jonas’ does that delay the propagation of the first change to stable?
  477. flow details we could discuss, but this basically mimics certain software development models
  478. flow but it is obvious that it should not be possible to delay a new stable namespace forever
  479. jonas’ I’m not so sure that you can simply transfer software development models to standards/protocol development models
  480. flow I think you can do, we already do namespace versioning
  481. flow (obviously you can not do everything from one domain into another)
  482. flow (obviously you can not transfer everything from one domain into another)
  483. flow but aren't xeps managed in a source code control system?
  484. pep. I think any solution based on time is naïve. We know all too well the "volunteer effect"
  485. flow pep., I am always happer to hear different better ideas
  486. flow pep., I am always happy to hear better ideas
  487. flow and we already have a lot of time based policiy when managing XEPs, sure it does not work that well, but I think an immiment timeout caused me to take action once in a while
  488. pep. Not depending on volunteers only (but paying people to work on $things) :) And that's a different topic I want to expand on quickly
  489. flow and we already have a lot of time based policiy when managing XEPs, sure it does not work that well, but I think an imminent timeout caused me to take action once in a while
  490. pep. Not depending on volunteers only (but paying people to work on $things) :) And that's a different but related topic I'd like to see started quickly
  491. flow right, we could do that too. but it is not really an argument against what I suggested
  492. pep. Sure
  493. pep. Anyway I still think people are always afraid to break anything even if that would make things better and that annoys me
  494. flow I'd also like to point out that a staging area and a -snapshot version could be considered similar to how RFCs are updated: 'bis' I-Ds as staging area, and some use a reserved value that is sometimes not the same value as the afterwards released RFCs for protocol version signalling
  495. flow I'd also like to point out that a staging area and a -snapshot namespace version could be considered similar to how RFCs are updated: 'bis' I-Ds as staging area, and some use a reserved value that is sometimes not the same value as the afterwards released RFCs for protocol version signalling
  496. jubalh has joined
  497. mukt2 has left
  498. bear has joined
  499. andrey.g has joined
  500. lovetox has joined
  501. mukt2 has joined
  502. Max has left
  503. Max has joined
  504. lovetox has left
  505. bear has left
  506. jubalh has left
  507. nyco has left
  508. nyco has joined
  509. pdurbin has joined
  510. nyco has left
  511. nyco has joined
  512. pdurbin has left
  513. Jeybe has joined
  514. bear has joined
  515. LNJ has left
  516. Jeybe has left
  517. Jeybe has joined
  518. Jeybe has left
  519. Jeybe has joined
  520. goffi has joined
  521. mukt2 has left
  522. LNJ has joined
  523. DebXWoody has joined
  524. debacle has left
  525. Max has left
  526. Max has joined
  527. adiaholic_ has left
  528. adiaholic_ has joined
  529. bear has left
  530. lovetox has joined
  531. Chobbes has joined
  532. lovetox hm can someone stop MattJ from bumping the namespace of the MAM XEP?
  533. lovetox just in theory
  534. Chobbes has left
  535. Daniel everyone has a price
  536. lovetox i thought experimental XEPs are totally in the hands of the Author
  537. lovetox if he doesnt change the nature of the XEP
  538. jonas’ lovetox, council can take authorship away
  539. jonas’ and then they could either roll back or instruct the editor to hold the PR
  540. Zash Wasn't it to be an additional feature?
  541. lovetox i wonder because it seems all very subjective and council members seem only to really care about XEPs they care about
  542. Daniel tbh i haven’t been following the current mam discussions. but whether justified in this case or not; the amount of different MAM namespaces conversations currently supports is ridiculous
  543. mukt2 has joined
  544. lovetox Daniel but nobody forces you to support these, really if you support :1 and :2 this is already very good
  545. lovetox i hope you dont support :0 and :tmp
  546. Zash This is the price you pay for deploying Experimental XEPs :)
  547. adiaholic_ has left
  548. pep. I guess paid work incentives people to support ancient tech forever
  549. Daniel i support 0; because openfire i think
  550. Zash Mmm, deployment stats would be handy
  551. Zash Current stable Prosody does only :2 unless you go for 3rd party MAM module. Similar with Carbons.
  552. lovetox yeah next Gajim version will only support :2
  553. pep. For what poezio support it's only :2
  554. lovetox :2 is already years old
  555. pep. For what poezio supports it's only :2
  556. Jeybe has left
  557. Jeybe has joined
  558. mukt2 has left
  559. adiaholic_ has joined
  560. Jeybe has left
  561. mukt2 has joined
  562. Jeybe has joined
  563. Ge0rG > If the 'with' field's value is the bare JID of the archive, the server must only return results where both the 'to' and 'from' match the bare JID (either as bare or by ignoring the resource), as otherwise every message in the archive would match What's the rationale behind that in 0313?
  564. Ge0rG Was that for PubSub still?
  565. Kev Ge0rG: I don't think so, no. Every message in your archive matches your own jid for either from or to, so searching for your own jid would be useless unless it meant something else - e.g. both to and from must match.
  566. neshtaxmpp has left
  567. Ge0rG On a personal archive that makes sense. What about on a semi anonymous MUC?
  568. Zash Is 'with' even used in MUCs?
  569. Zash The Prosody implementation just ignores that field on MUCs
  570. jubalh has joined
  571. Zash (actually because the internal field is overloaded and used for something else there)
  572. rion has left
  573. rion has joined
  574. mukt2 has left
  575. Kev Ge0rG: On a MUC you wouldn't be searching for the MUC's bare JID if you want a particular user, you'd be searching on full JID.
  576. bear has joined
  577. Ge0rG Kev: that makes sense
  578. lorddavidiii has left
  579. Ge0rG Maybe I should reword my question into: "the rationale for this should be added to the XEP"
  580. Ge0rG Also I'm confused about that custom <flip-page/> element inside a data form. Why not a boolean field?
  581. Zash Wait, inside?
  582. Ge0rG Cc MattJ
  583. Zash Not as a sibling to?
  584. lorddavidiii has joined
  585. krauq has left
  586. Ge0rG Oh, maybe yes. I'm reading the diff by flow
  587. Ge0rG Still, my question remains
  588. krauq has joined
  589. Zash Because it's related to the result page, not the query?
  590. Ge0rG Also what's the benefit of defining the gone error condition over just item-not-found?
  591. eevvoor has left
  592. Zash Huh
  593. Jeybe has left
  594. Jeybe has joined
  595. lovetox has left
  596. mukt2 has joined
  597. MattJ Ge0rG, isn't the rationale for that in the XEP?
  598. MattJ :)
  599. Zash before-/after-id selects an exclusive (excluding? words?) range?
  600. nyco has left
  601. MattJ Daniel, for the record, I haven't bumped the namespace in MAM. There are some additional features which have a new disco feature, which can only be advertised on top of the current one. So if you don't use those features, you don't need to make any changes.
  602. Ge0rG MattJ: the rationale for with=account? I must have missed it
  603. MattJ The rationale of <gone/>
  604. Ge0rG MattJ: yes, there is one. But is it really useful to have?
  605. Zash Doesn't gone mean the JID (you're talking to) has gone away?
  606. Ge0rG Is there any additional information for the client in it?
  607. MattJ Yes
  608. Ge0rG Threads, where are you?
  609. Zash Seems a stretch to use 'gone' for items when there's an 'item-not-found'?
  610. MattJ <gone/> means the item used to exist, and has been purged/trimmed. If you're doing full-sync MAM, that means you lost messages, and also that you should resync the full archive to catch up.
  611. Ge0rG MattJ: I need to check for two different error conditions now, but the server developers won't store all UIDs ever used anyway, so I won't ever experience that in practice.
  612. MattJ <item-not-found/> is ambiguous, e.g. if the archive was restored from a backup
  613. bear has left
  614. MattJ so with item-not-found you can't assume that the id was ever known to the server
  615. Zash Why not a custom error condition?
  616. Ge0rG MattJ: but what does that knowledge give me?
  617. MattJ Ge0rG, that resyncing the archive would potentially be a very wrong thing to do
  618. Ge0rG MattJ: and that I should do what instead?
  619. MattJ Because you'll just refetch an entire archive of messages you already have
  620. MattJ You're the client dev, you decide :)
  621. Ge0rG So I have to re-fetch the whole archive to see where the server has new data.
  622. nyco has joined
  623. MattJ You can page backwards instead, or do something time-based, etc.
  624. jubalh has left
  625. Ge0rG MattJ: but that's also what I'd do on gone.
  626. MattJ Zash, I originally did use a custom error condition. But I'm sure there is a stronger argument for re-using existing conditions where possible.
  627. Ge0rG MattJ: because you can't guarantee that I'll actually get gone as a dedicated error at all
  628. MattJ You're right that <gone/> may be misinterpreted, so a custom condition probably does make sense
  629. mukt2 has left
  630. Ge0rG MattJ: you could help me by returning me the timestamps and IDs around the gap
  631. mukt2 has joined
  632. Ge0rG MattJ: but you don't know whether my request is for before the start of the archive or for a missing message from in between
  633. MattJ Missing messages in-between are forbidden by the XEP
  634. MattJ So if something is missing it's missing at either the start or the end
  635. Ge0rG MattJ: you can only solve that by demanding that I request an ID and the respective timestamp
  636. Ge0rG MattJ: but you just said restored from archive
  637. Ge0rG That implies there are missing messages in the middle
  638. Zash This reminds me of what I've heard of how version control things do sync
  639. Ge0rG MattJ: because after the restore there will be new messages added
  640. MattJ At some point, yes
  641. Ge0rG MattJ: yes, so I don't see the point.
  642. MattJ Well, better suggestions welcome
  643. MattJ Otherwise I can nuke any attempt at trying to provide the client some useful information about what might be going on
  644. Ge0rG MattJ: you could use the same error with an additional custom condition, but I really don't see what I can do differently in that situation
  645. Ge0rG MattJ: if a leak in the middle is forbidden, you MUST NOT restore the archive from a backup that's not a complete replica at the time of the crash
  646. MattJ differently to...? What would you do today?
  647. Ge0rG Which makes backups useless
  648. Zash mumbles something about pointer to previous message something something linked list
  649. Ge0rG MattJ: a full sync for 7 days or some such
  650. MattJ So you may still download 6.9d of messages you already have
  651. Ge0rG MattJ: so you suggest that I go backwards from $NOW until I encounter a known message?
  652. ths has left
  653. Zash Ask for the last message in the archive, ???, do something with that
  654. MattJ (the last message id/timestamp could be included in the error, as Ge0rG suggested)
  655. Ge0rG Zash: the last message in the archive will be from just five minutes ago
  656. MattJ (last and first?)
  657. Ge0rG The first message in the archive will be either before or after the last message the client knows about
  658. Ge0rG And that would be somehow actionable for me
  659. Zash Have the client send id of the last message it has, then the server replies with its own last message id, then you compute something magic with set and graph theory and then you're golden
  660. jubalh has joined
  661. Ge0rG If it's before, then there is a hole in the archive
  662. MattJ FWIW my plan for bind-ng was to include the id of the first/last message in the archive already
  663. Ge0rG I want my client to store messages in the database in roughly chronological order, because ordering a table with two years of chat history is fucking slow.
  664. Ge0rG There is no way to resync that with an archive that has unknown holes.
  665. Jeybe has left
  666. Jeybe has joined
  667. MattJ I agree, unknown holes are the enemy and are what I'm trying to prevent (as well as useless full resyncs)
  668. MattJ So I'm trying to give the client information that it can use, because a simple "it's not here" is not enough
  669. Ge0rG And a client that doesn't need to store in chronological order will just page backwards in any case
  670. Ge0rG MattJ: why not?
  671. MattJ Because it could mean you didn't sync soon enough and you missed some messages, the archive was purged, or it was restored
  672. Ge0rG Especially given that most implementations won't actually be able to tell me "your ID is too old and got wiped" anyway
  673. MattJ Ok, so I'll remove it I guess
  674. MattJ Maybe bind-ng can fill the gap instead
  675. Ge0rG MattJ: you could make it mandatory to store all IDs forever, that would make the feature useful
  676. Zash Or blockchain!!!!
  677. Ge0rG What Zash said
  678. MattJ I'm not going to make that mandatory, but there are other ways to implement this
  679. MattJ (ordered ids, for example)
  680. Ge0rG MattJ: a bloom filter?
  681. Ge0rG Ordered and encrypted?
  682. Ge0rG Timestamp plus random salt encrypted with a private key, so that the server can reverse it?
  683. MattJ Exactly
  684. Ge0rG See, it's so easy. Make it mandatory!
  685. Ge0rG Oh, also renumber all existing archives!
  686. Zash Oh glob
  687. jonas’ Ge0rG, no, renumbering would be too invasive
  688. adiaholic_ has left
  689. adiaholic_ has joined
  690. MattJ That's exactly why I didn't make it mandatory
  691. jonas’ let’s just introduce another ID :)
  692. Ge0rG Also all client copies, synchronously!
  693. Zash High precision timestamp
  694. Ge0rG MattJ: just add a way to query the size of the archive
  695. MattJ The size doesn't really help
  696. MattJ unless you mean time period
  697. MattJ But I hesitate to do anything much based on timestamps
  698. Ge0rG The size can be measured in days as well
  699. Ge0rG Yeah, I understand that
  700. Ge0rG I understand the rationale now and see how you could pull it off. But would you actually do that in prosody?
  701. MattJ Potentially, yes, if it can be done in a sane way
  702. MattJ But now it may just be better to replace this all with a query that returns some metadata about the archive
  703. MattJ The first/last ids and timestamps
  704. MattJ Even more info in the hands of clients
  705. Zash Summary thing?
  706. MattJ Summary!
  707. Ge0rG Or have a multi query where the client sends its last known ID and timestamp and the server just fills up
  708. Ge0rG Smart servers, dumb clients!
  709. Zash And thus the pendulum swings
  710. Ge0rG The MAM logic for matching reflected own messages is maddening already.
  711. Guus Daniel: > i support 0; because openfire i think Openfire has 0, 1 and 2.
  712. DebXWoody has left
  713. Ge0rG Also I must filter all my local MAM ID lookups on incoming-only
  714. DebXWoody has joined
  715. j.r has left
  716. bear has joined
  717. Jeybe has left
  718. Jeybe has joined
  719. j.r has joined
  720. Ge0rG Also encrypting information into the archive UID might end up with all sorts of bad effects, if done incorrectly
  721. Zash Weren't you the one who disliked long IDs, Ge0rG?
  722. Ge0rG Zash: I still am
  723. Zash MattJ and I discussed / looked at Twitters snowflake (?) id stuff, which is a 64bit integer
  724. lovetox has joined
  725. Jeybe has left
  726. Jeybe has joined
  727. jubalh has left
  728. Jeybe has left
  729. Jeybe has joined
  730. lovetox has left
  731. Jeybe has left
  732. Jeybe has joined
  733. MattJ Ge0rG/all: thanks for the feedback, I've retracted my "ok to merge" on the PR and will prep a new version this week
  734. Mikaela has left
  735. Mikaela has joined
  736. Jeybe has left
  737. Jeybe has joined
  738. Ge0rG MattJ: Re with=account, > Maybe I should reword my question into: "the rationale for this should be added to the XEP"
  739. Ge0rG > Also I'm confused about that custom <flip-page/> element inside a data form. Why not a boolean field?
  740. eevvoor has joined
  741. MattJ I think both of those were answered, and now I'm on a mobile keyboard
  742. MattJ The latter isn't a filter
  743. Ge0rG MattJ: it's a kind of a filter.
  744. MattJ It's not part of the criteria
  745. lovetox has joined
  746. Ge0rG MattJ: well yeah, I just wondered if it wouldn't be easier to re-use existing protocol
  747. MattJ For with, the reason is given in the XEP
  748. lovetox Ge0rG, that flip page thing is a bit inbetween worlds
  749. lovetox the dataform in MAM represents the filter you request from the database
  750. Ge0rG MattJ: the sentence for with doesn't even end in a full stop. I'm sure it's missing more
  751. lovetox afterwards you specify with RSM the page settings
  752. Ge0rG also "as otherwise every message in the archive would match" is not the rationale, it's just a technical explanation which doesn't enlighten why you need the feature
  753. lovetox now flip page is not part of rsm but its also not a filter
  754. MattJ It's the rationale
  755. lovetox actually in a perfect world flip-page would be in the RSM XEP, but sadly its not
  756. MattJ It's not technical, it could have not been added, and then there would be no way to search for messages with yourself
  757. Ge0rG MattJ: the rationale would be "To allow querying for messages the user sent to themselves, the client needs to set the 'with' attribute to the account JID. In that case, the server MUST only return results where both the 'to' and 'from' match the bare JID (either as bare or by ignoring the resource), as otherwise every message in the archive would match."
  758. Ge0rG "the bare JID of the archive" is weird at least for a MUC archive
  759. MattJ Potentially, yeah
  760. Ge0rG MattJ: feel free to quote that in the new XEP
  761. MattJ "the bare JID of the archive" is weird at least for a MUC archive"
  762. MattJ Ok ;)
  763. Ge0rG :P
  764. j.r has left
  765. Mikaela has left
  766. Mikaela has joined
  767. Jeybe has left
  768. Zash has left
  769. Jeybe has joined
  770. Zash has joined
  771. Jeybe has left
  772. Jeybe has joined
  773. Mikaela has left
  774. Mikaela has joined
  775. Mikaela has left
  776. Mikaela has joined
  777. Mikaela has left
  778. Mikaela has joined
  779. Jeybe has left
  780. Jeybe has joined
  781. karoshi has left
  782. karoshi has joined
  783. Nekit has joined
  784. j.r has joined
  785. Jeybe has left
  786. Jeybe has joined
  787. Jeybe has left
  788. Jeybe has joined
  789. Mikaela has left
  790. Mikaela has joined
  791. Jeybe has left
  792. Jeybe has joined
  793. Mikaela has left
  794. Mikaela has joined
  795. Jeybe has left
  796. Jeybe has joined
  797. Jeybe has left
  798. Jeybe has joined
  799. jubalh has joined
  800. lovetox has left
  801. Jeybe has left
  802. Jeybe has joined
  803. Jeybe has left
  804. Jeybe has joined
  805. Jeybe has left
  806. Jeybe has joined
  807. lorddavidiii has left
  808. Jeybe has left
  809. Jeybe has joined
  810. lovetox has joined
  811. Jeybe has left
  812. Jeybe has joined
  813. alexis has left
  814. mukt2 has left
  815. !XSF_Martin has left
  816. !XSF_Martin has joined
  817. Jeybe has left
  818. Jeybe has joined
  819. Max has left
  820. Max has joined
  821. lovetox has left
  822. pdurbin has joined
  823. goffi has left
  824. Jeybe has left
  825. Jeybe has joined
  826. pdurbin has left
  827. mukt2 has joined
  828. alexis has joined
  829. alexis has left
  830. alexis has joined
  831. marc has left
  832. marc has joined
  833. Maranda has left
  834. Maranda has joined
  835. Maranda has left
  836. Maranda has joined
  837. mukt2 has left
  838. serge90 has joined
  839. Maranda has left
  840. Jeybe has left
  841. Jeybe has joined
  842. serge90 has left
  843. serge90 has joined
  844. serge90 has left
  845. serge90 has joined
  846. Maranda has joined
  847. mukt2 has joined
  848. Maranda has left
  849. Maranda has joined
  850. Maranda has left
  851. werdan has joined
  852. Maranda has joined
  853. serge90 has left
  854. serge90 has joined
  855. dhtgh has joined
  856. dhtgh 11:28:00 PM [mysql] Attempting to start MySQL app... 11:28:00 PM [mysql] Status change detected: running 11:28:02 PM [mysql] Status change detected: stopped 11:28:02 PM [mysql] Error: MySQL shutdown unexpectedly. 11:28:02 PM [mysql] This may be due to a blocked port, missing dependencies, 11:28:02 PM [mysql] improper privileges, a crash, or a shutdown by another method. 11:28:02 PM [mysql] Press the Logs button to view error logs and check 11:28:02 PM [mysql] the Windows Event Viewer for more clues 11:28:02 PM [mysql] If you need more help, copy and post this 11:28:02 PM [mysql] entire log window on the forums
  857. dhtgh how can i solve it?
  858. Jeybe has left
  859. Jeybe has joined
  860. serge90 has left
  861. serge90 has joined
  862. mukt2 has left
  863. mukt2 has joined
  864. serge90 has left
  865. Zash Hey. I'm not sure that this is the right place for that. More context needed.
  866. serge90 has joined
  867. dhtgh has left
  868. Jeybe has left
  869. Jeybe has joined
  870. jubalh has left
  871. mukt2 has left
  872. lovetox has joined
  873. serge90 has left
  874. serge90 has joined
  875. Jeybe has left
  876. serge90 has left
  877. Jeybe has joined
  878. serge90 has joined
  879. mukt2 has joined
  880. debacle has joined
  881. SamWhited has joined
  882. Syndace Can someone refresh my memory, I remember discussion regarding "messages with UI elements", like having buttons appear in the chat and sending a predefined result when clicking one of those buttons. What was the result of that discussion? Not required? Already possible with data forms?
  883. Zash https://xmpp.org/extensions/inbox/buttons.html ?
  884. serge90 has left
  885. Zash Syndace, basically, the result was those exact questions, to which I haven't had the energy to XEP up an answer yet.
  886. jubalh has joined
  887. Syndace Ah yes, exactly that
  888. serge90 has joined
  889. Syndace Alright thanks
  890. Zash There's precedent for sending dataforms in messages, tho awkward for what I was aiming for
  891. Zash Help getting that back on track would be appreciated
  892. Zash Either by figuring out if we can just shove ad-hoc commands in messages or dataforms or continue with that
  893. !XSF_Martin has left
  894. !XSF_Martin has joined
  895. Syndace continue with "that"?
  896. Syndace I'm afraid I have to read a few XEPs before I can be of use here
  897. Syndace Will do though, I'd really like to see that being specified
  898. Zash Syndace: with that protoxep*
  899. serge90 has left
  900. mukt2 has left
  901. serge90 has joined
  902. typikol has joined
  903. mukt2 has joined
  904. typikol has left
  905. waqas has joined
  906. Jeybe has left
  907. Jeybe has joined
  908. serge90 has left
  909. serge90 has joined
  910. werdan has left
  911. Jeybe has left
  912. Marc has left
  913. Jeybe has joined
  914. jubalh has left
  915. serge90 has left
  916. MattJ I no longer work on the implementation I wanted that spec for
  917. serge90 has joined
  918. Zash Find an excuse to do it in Snikket?
  919. Syndace isn't there also some movement regarding a (http based) bot API?
  920. Syndace I think those two things go together well
  921. MattJ Yes
  922. werdan has joined
  923. moparisthebest has left
  924. Zash 🤖️> The build of *thing* failed. [abort] [retry] [send angry message to author of latest change]
  925. serge90 has left
  926. marc has left
  927. serge90 has joined
  928. jubalh has joined
  929. !XSF_Martin Threaten the author to not use their software!!!!elf!!eleventy
  930. Zash What you think you said. ↑ What unpaid volonteer developer hears: I will decrease your support load!!!!
  931. marc has joined
  932. !XSF_Martin Win-Win. You're not getting angry about the software anymore and happy dev can program on a flower meadow enjoying life instead of doing hated support.
  933. serge90 has left
  934. serge90 has joined
  935. marc has left
  936. marc has joined
  937. serge90 has left
  938. serge90 has joined
  939. serge90 has left
  940. serge90 has joined
  941. karoshi has left
  942. karoshi has joined
  943. serge90 has left
  944. serge90 has joined
  945. alexis has left
  946. Jeybe has left
  947. serge90 has left
  948. Jeybe has joined
  949. serge90 has joined
  950. serge90 has left
  951. serge90 has joined
  952. Jeybe has left
  953. Jeybe has joined
  954. serge90 has left
  955. serge90 has joined
  956. Syndace After reading ad-hoc commands I feel like those are one level too high for XEP-buttons. ad-hoc works "synchronously" with IQs and specifies a full bidirectional interaction between an entity that offers a command and an entity that wants to use the command. I think for XEP-buttons we neither have fixed commands that entities could offer, nor should the button requests/responses be synchronous with IQs aka requiring both parties to be online at the same time.
  957. Syndace I'd rather have a way to say "please display the data form in this message somewhere inline"
  958. emus has left
  959. emus has joined
  960. serge90 has left
  961. serge90 has joined
  962. Zash Syndace, study this: https://xmpp.org/extensions/xep-0045.html#requestvoice
  963. pdurbin has joined
  964. lovetox Syndace, just put a form into a message
  965. lovetox if a client supports showing forms he can display them
  966. lovetox for example Gajim has a plugin that shows forms in the chat
  967. Syndace well there must be a gotcha with that, otherwise Zash's protoxep wouldn't exist?
  968. Zash Tho the buttons protoxep was more about having a list of buttons
  969. Zash Syndace, yes, how do you represent a simple button with a form?
  970. Syndace ah right, that
  971. lovetox the question is why would you need to show more than one button?
  972. flow Zash, simple button? like only one choice?
  973. Zash form's don't have any actions or such attached
  974. lovetox if you want to choose, you can show radio buttons
  975. Zash even in ad-hoc those are separate
  976. lovetox it would also trivial to add something to a form, so a client shows buttons instead of radio buttons, for single-list type
  977. Zash I had some text about this somewhere
  978. lovetox hm but that makes no sense .. you have to send the form
  979. Syndace so one challenge is buttons with forms
  980. flow I am sorry, but I don't get the issue here with forms? Are we talking about yes/no buttons?
  981. Syndace and the other challenge is specifying how the client reacts to such a form, like how the selection is responded back to the sender?
  982. serge90 has left
  983. krauq has left
  984. krauq has joined
  985. flow i'd say that is specified in the data form xep
  986. serge90 has joined
  987. flow i.e., you send the submit form back
  988. lovetox Syndace, this is already all specified
  989. lovetox we use forms everyday
  990. Syndace then please rephrase > form's don't have any actions or such attached
  991. Zash flow, do or don't forms rather
  992. flow hmm, "do or don't forms"?
  993. flow can you give an example?
  994. Zash flow, I offer you a button. You click it, or you don't.
  995. flow Zash, wouldn't that be just to submit the form or not?
  996. flow potentially with a single boolean or text-single field?
  997. j.r has left
  998. Zash a single FORM_TYPE
  999. Jeybe has left
  1000. Jeybe has joined
  1001. Zash + you can have title, description
  1002. flow not sure if that would work. isn't FORM_TYPE just the "namespace" of forms?
  1003. flow ahh ok, with more textual content, then yes
  1004. Zash How about: A form with only hidden fields
  1005. serge90 has left
  1006. serge90 has joined
  1007. Zash And you want to support more than one per message
  1008. Zash so a bot can say [abort] [retry] [cancel]
  1009. adiaholic_ has left
  1010. adiaholic_ has joined
  1011. Zash `<x xmlns="jabber:x:data" type="form"><title>Click me</title></x>`
  1012. Zash If there are fields other than hidden you'd render it as a form and like have a Submit button on it
  1013. MattJ Oh no, not this discussion again
  1014. serge90 has left
  1015. lorddavidiii has joined
  1016. serge90 has joined
  1017. MattJ Data forms don't support buttons, and clients will never implement them, and it will be a usability nightmare
  1018. Syndace okay so that's why the protoxep doesn't just use data forms
  1019. lovetox MattJ, i dont know what you mean by "Buttons"
  1020. MattJ I know people here probably don't use other messengers much, but many of them have this feature (Facebook Messenger and Telegram for example)
  1021. Zash Syndace, there was an idea about using dataforms (or anything) as payload
  1022. MattJ The idea is that it's easier to send a quick predefined response to a message by tapping a button
  1023. Zash Syndace, basically you get a bunch of <button>s, any xml content in those get sent back in a <click> container when clicked
  1024. Maranda has left
  1025. Zash then you use dataforms or json or whatever
  1026. MattJ The use case is bots, where the possible responses are generally limited/fixed
  1027. lovetox MattJ why cant i choose my response from a radiobutton selection and press send?
  1028. MattJ Because clients don't (and won't) implement that
  1029. MattJ and it becomes ambiguous if a client doesn't implement forms
  1030. lovetox But they would implement buttons?
  1031. bear has left
  1032. Zash lovetox, how do you know it's a set of distinct buttons and not a form with a select dropdown?
  1033. MattJ Yes, because it's far simpler
  1034. Syndace > basically you get a bunch of <button>s, any xml content in those get sent back in a <click> container when clicked wouldn't that be enough already?
  1035. Syndace no need for data forms if we're at that point?
  1036. Zash Syndace, for what?
  1037. Syndace To make a client display buttons and get a response when one is clicked
  1038. MattJ lovetox, are you really going to add inline data form rendering? and do you think other clients will? To this day none of the mobile clients support data forms
  1039. Zash xep rejected by council, I've no energy to spend on that, ???, nothing
  1040. lovetox The problem im having with this is, thats is very very simple XEP that people want to extend, and then you basically add to it and add to it, until you have dataforms
  1041. MattJ Adding a list of buttons above the text entry is relatively easy compared to an arbitrary sized form containing any kind of possible widgets
  1042. Syndace agreed, I think data forms is "too flexible" here
  1043. pdurbin has left
  1044. MattJ This won't be added to, because it does just one very simple well-defined thing
  1045. serge90 has left
  1046. lovetox until one wants to add something really simple to it
  1047. MattJ Then we reject *that*
  1048. lovetox like a multi-text field above the buttons to send text
  1049. MattJ Why reject the initial proposal?
  1050. serge90 has joined
  1051. MattJ Yes, multi-text would indeed be crazy
  1052. lovetox its perfect reasonable, why cant i type a comment before i press the button and send that with?
  1053. MattJ Another argument against forms :)
  1054. Shell has joined
  1055. Zash MattJ, I think someone asked for a protoxep that described the form approach, as comparison, and that's not been submitted and probably won't be unless someone (not me) does it
  1056. Syndace Even if a very simple use-case emerges that is later added to the buttons-only XEP, that's still much better than forms and all the confusion that comes with forms edge cases
  1057. Zash `<button><{my-special-protocol}payload/></button>`
  1058. Zash there you go
  1059. MattJ I think the people who rejected it probably have no experience of other messengers or why this feature is useful
  1060. MattJ Data forms would be pointless bloat
  1061. Zash MattJ, even if you specified a restricted subset to be treated as a simple button?
  1062. MattJ If I ever do need to implement this feature, I just intend to implement the protoXEP
  1063. MattJ If you did do that... *why?**
  1064. MattJ It's 100% pointless, and makes more work
  1065. Zash Dunno, reuse of namespaces
  1066. SamWhited marc: are you still maintaining XEP-0401? Can you ping me (JID/email as your prefer: sam@samwhited.com) if so? I'd like to chat about integrating it with IBR2
  1067. lovetox because i already have a dataforms impl
  1068. MattJ The point of the buttons is that they map to plaintext user responses
  1069. Syndace (or xml)
  1070. MattJ lovetox, you already have a pubsub impl too, so... let's use that!
  1071. Zash And an ad-hoc iml!
  1072. Zash How about we ship a disco#items ad-hoc command list in a message?
  1073. MattJ SamWhited, as an active user of a "variant" of XEP-0401, I'm interested in such discussions
  1074. Zash If all commands are single-step and form-less then they're equivalent to buttons
  1075. serge90 has left
  1076. serge90 has joined
  1077. SamWhited MattJ, Zash: I just submitted a revamp of 0389 which I would appreciate feedback on (it's a little messy and hard to follow right now, so I may make a few changes before it gets merged): https://github.com/xsf/xeps/pull/929
  1078. SamWhited If marc and I chat I'll CC you into any discussions
  1079. Zash Ge0rG might also be interested (and now mentioned)
  1080. SamWhited Was just chatting with him too :)
  1081. Zash 👍️
  1082. SamWhited I want to figure out the maintenance status of XEP-0401 first and if we can get the existing PRs merged, then maybe we can start a discussion about adding an IBR2 challenge type into it
  1083. lovetox i already see the horror, people write bots that send you buttons to lead you step by step through some process
  1084. Zash lovetox, like memberbot? :)
  1085. Zash Imagine getting buttons for quick answers instead of typing yes / no
  1086. lovetox im not question that there is a good use case for the button xep
  1087. lovetox voting is definitly one
  1088. jubalh has left
  1089. lovetox i just fear, because all clients implement it, for what people abuse it then
  1090. Ge0rG It will be awesome!
  1091. Syndace how do forms prevent abuse?
  1092. Zash How do you prevent *any* abuse?
  1093. serge90 has left
  1094. Ge0rG SamWhited: you've seen https://yaxim.org/blog/2020/01/31/yaxim-0-dot-9-9-fosdem-edition/ and the video in it?
  1095. serge90 has joined
  1096. lovetox Syndace, forms are made so you can make .. Forms of any size and kind
  1097. lovetox so i dont see how you can abuse such a non specific use case
  1098. SamWhited Ge0rG: TL;D(Watch)?
  1099. Ge0rG SamWhited: live demo of cross client 0401 with ASCII art QR code
  1100. serge90 has left
  1101. serge90 has joined
  1102. Jeybe has left
  1103. waqas has left
  1104. Jeybe has joined
  1105. werdan has left
  1106. Syndace wait can you not search the mail archives
  1107. Zash inpossiburu
  1108. serge90 has left
  1109. serge90 has joined
  1110. Mikaela has left
  1111. Mikaela has joined
  1112. Ge0rG Syndace: download the mbox file and search locally
  1113. Ge0rG Maybe we should kindly ask gmane. Is that still a thing?
  1114. Syndace found it by checking the dates surrounding the protoxep last update date
  1115. Syndace but meh 😀
  1116. Zash Hm
  1117. Zash https://logs.xmpp.org/council/ is also a good resource
  1118. Syndace love how the presence spam is logged
  1119. Zash Hysterical raisins.
  1120. Zash You should see the stuff logged by the original MUC logger implementation.
  1121. xecks has left
  1122. xecks has joined
  1123. pep. > lovetox> i already see the horror, people write bots that send you buttons to lead you step by step through some process yeah imagine people doing ad-hoc (bot commands) with buttons! just like they're doing bot commands with messages atm :p not sure if it'd be an improvement.
  1124. goffi has joined
  1125. serge90 has left
  1126. Zash Syndace, there's a checkbox somewhere that lets you hide joins and parts
  1127. waqas has joined
  1128. serge90 has joined
  1129. lovetox Also everyone can see in a MUC what you voted
  1130. Nekit has left
  1131. Nekit has joined
  1132. Syndace joins and parts? 😀 oh boy, my internet language is lacking behind
  1133. Syndace like, thread joins/parts?
  1134. Syndace like, mail thread joins/parts?
  1135. Syndace oooh joins as in presence spam, sorry
  1136. pep. yeah it has to be pretty clear that votes are public, otherwise we're gonna get more users complaining we're not respecting their privacy!!
  1137. lovetox Maybe one can send the answer as PM
  1138. Zash Syndace, https://logs.xmpp.org/council/2018-12-12?p=h#2018-12-12-f53055662532f142
  1139. Jeybe has left
  1140. Syndace thanks, still busy with the mails tho
  1141. Jeybe has joined
  1142. Syndace the feedback on the mailing list seems to mainly be "but then people want more features and we end up with data forms!!11!!"
  1143. Syndace tedd had some actual feedback regarding details about the behaviour but that's really just missing because the protoxep is minimal and could be added without a lot of discussion
  1144. pep. Zash: I also take advice for representing buttons in my terminal
  1145. pep. Syndace: ^
  1146. Syndace don't
  1147. Syndace buttons are just a more convenient way to send a fixed string
  1148. pep. :P
  1149. Syndace not supposed to be funny 😀
  1150. serge90 has left
  1151. Zash tab completion
  1152. Syndace that's what the spec is currently
  1153. Zash there, done
  1154. Syndace true
  1155. pep. Zash: that's meh
  1156. serge90 has joined
  1157. Syndace 1: yes 2: no 3: maybe >
  1158. pep. you'd need to indicate first that you're doing buttons somehow (which one of the 3 last buttons messages that were sent?)
  1159. Yagiza has left
  1160. Syndace that's one of the behavioural details that are missing. but that's not a reason to reject the protoXEP, the rule would probably be as simple as "only do button stuff for the most recent message"
  1161. pep. though i give you it's a common issue in terminal stuff. So tab won't fix it
  1162. Zash [yes] [no] [abstain] [maybe] [nuke it from orbit]
  1163. pep. Syndace: why?
  1164. Syndace simplicity and telegram 😀
  1165. Syndace you also don't have to worry then to which button-message an answer corresponds
  1166. pep. ah so we're Inn the business of reproducing telegram now? :)
  1167. Syndace yep!
  1168. pep. I thought it was WhatsApp and Slack until today
  1169. Zash Are we not in the business of absorbing everything from every communications protocol?
  1170. pep. in*
  1171. serge90 has left
  1172. serge90 has joined
  1173. bear has joined
  1174. Syndace > do we wanrt to open the can of worms what the "last message" is again? 🙂 is "last message" an issue for XMPP?
  1175. DebXWoody has left
  1176. Nekit has left
  1177. pep. is it the one I sent with this device or any device? maybe? even though that's been specified iirc?
  1178. serge90 has left
  1179. serge90 has joined
  1180. Syndace also for buttons only incoming messages are relevant
  1181. Mikaela has left
  1182. pep. sure, m'y message above was just answering yours directly
  1183. j.r has joined
  1184. pep. sure, my message above was just answering yours directly
  1185. Syndace ok, that was a quote from the discussion on buttons
  1186. pep. ah ok
  1187. Maranda has joined
  1188. Syndace Done reading. I think most of the feedback is fine and can be fixed/clarified in the protoXEP. The question of Simple Buttons vs. data forms is obviously the biggest issue, but I think by clarifying that the buttons are just shortcuts to send quick fixed-string responses that question can also be answered.
  1189. alexis has joined
  1190. alexis has left
  1191. alexis has joined
  1192. serge90 has left
  1193. Jeybe has left
  1194. serge90 has joined
  1195. Jeybe has joined
  1196. alexis has left
  1197. vanitasvitae has left
  1198. vanitasvitae has joined
  1199. alexis has joined
  1200. bear has left
  1201. MattJ I'd dearly love to see this pushed through
  1202. serge90 has left
  1203. werdan has joined
  1204. serge90 has joined
  1205. MattJ I'm starting to realise that a big problem is people not understanding the use case
  1206. goffi has left
  1207. Zash As council member and author of that protoxep, I would be happy to see that move forward as well.
  1208. lovetox So in a MUC i press the yes button and then i see my "yes" appear as reflection in the MUC
  1209. lovetox does that work this way also in Telegram?
  1210. SamWhited Maybe rename it "Quick Replies" and then the use case will be more obvious?
  1211. Zash Sure. Probably wasn't smart to imply some specific UI for it.
  1212. Jeybe has left
  1213. Jeybe has joined
  1214. SamWhited Android has this as a feature. It's some AI driven nonsense that tries to predict what you might say based on the context of the message, but if they have an API to manually manipulate them I can see Conversations or something setting them to use ones included in the messgae instead.
  1215. pep. MattJ: that's not impossible. I wouldn't be surprised though if somebody proposed something slightly more advanced such as "send reply and attached justification" (dumb exemple) and it got refused because "you can already do 90% of this via xxx"
  1216. Zash FWIW I was also studiying the stuff in Slack which is somewhat more advanced than just quick replies.
  1217. pep. SamWhited: yeah that's quite annoying
  1218. serge90 has left
  1219. Zash pep., arbitrary text string reactions?
  1220. Zash suggested reactions?
  1221. serge90 has joined
  1222. pep. Zash: suggested replies
  1223. SamWhited pep. I really like the idea, it just never has any useful replies for me
  1224. MattJ A rename sounds sensible
  1225. pep. often I fear I'm gonna hit them instead of what I want to do
  1226. Syndace the question how this works in muc is justified though
  1227. MattJ What's the question?
  1228. Zash Is the answer Hats?
  1229. MattJ Usually
  1230. pep. no
  1231. MattJ Hats XEP is nearing the top of my XEP to do queue!
  1232. pep. everyone can see your "votes" lovetox noted
  1233. Zash (THREAD: Hats) Hats + Security labels + filtering. Get to it!
  1234. SamWhited I feel like I've asked this before, but "Hats"?
  1235. Jeybe has left
  1236. MattJ Yes, like they can see anything you type
  1237. Jeybe has joined
  1238. Syndace yeah probably no question here actually
  1239. MattJ SamWhited: maybe known as "badges" in other systems?
  1240. pep. MattJ: yes but "votes are private!!" something
  1241. Zash SamWhited, https://xmpp.org/extensions/xep-0317.html
  1242. SamWhited ahh, right
  1243. alexis has left
  1244. SamWhited Thanks
  1245. MattJ SamWhited: but we've had them way longer, just nobody really cared until now to implement and finish the XEP
  1246. lovetox has left
  1247. MattJ pep.: I really don't understand
  1248. Syndace yeah no, private votes are not covered by this and that's it
  1249. Zash So would you really do that kind of quick reply thing in MUCs then?
  1250. MattJ Why not?
  1251. Zash It Depends™
  1252. serge90 has left
  1253. Zash If you do voting, then closed voting would need to work differently.
  1254. serge90 has joined
  1255. pep. is this really supposed to be quick replies? is the string actually sent as a message or what?
  1256. MattJ Yes
  1257. pep. uh
  1258. Zash Unless you wanna replace the response with some XML blob
  1259. MattJ See? Nobody understands
  1260. SamWhited Please don't replace the response with some XML blob. I also didn't understand before, but now that I do I really like the idea and want to use it :)
  1261. MattJ Zash, maybe it would be worth sticking some in-reply-to stanza-id just because?
  1262. Syndace but clients that don't support buttons wouldn't set in-reply-to
  1263. pep. MattJ: just that I don't see the use-case at all
  1264. Zash (Hat: Council) Can someone please write a XEP about `<in-reply-to by="jid" id="stanza-id"/>` ?
  1265. SamWhited If there were some in-reply-to stanza-id or <thread> or attach-to or something clients could special case it to just show a counter on the original message or something if they support it, which would be nice
  1266. pep. votes made a bit more sense
  1267. MattJ Syndace, there is the Slack-like use-case which is also interesting, where you maybe don't want/need to send a text message, but perform some action
  1268. Zash Adhoc/forms might work better for that
  1269. MattJ so a simple "this button was clicked" payload is enough to trigger the bot to do something
  1270. MattJ Zash, too many taps
  1271. MattJ You can't ad-hoc on a message
  1272. SamWhited Also this has a nice fallback behavior for clients that don't support adhoc/forms (which I suspect is almost none). In Mcabber I can happily type "yes" or whatever.
  1273. Zash MattJ: Offer of ad-hoc commands in a message?
  1274. MattJ SamWhited, exactly
  1275. Zash OR A MUD
  1276. Ge0rG Just use Emoji reactions for voting
  1277. Zash GO WEST
  1278. MattJ Zash, and then it gets way more complicated, and what if the command is multi-step? Ugh.
  1279. eta Zash, YES
  1280. eta MUD in XMPP when
  1281. MattJ eta, over a decade ago
  1282. MattJ You had to be there
  1283. Zash You were eaten by a grue.
  1284. serge90 has left
  1285. Zash (the heck is a grue?)
  1286. MattJ I made a MUC^Hd component, it was great
  1287. serge90 has joined
  1288. eta MattJ, is the source somewhere
  1289. eta MattJ, I will run this
  1290. MattJ It's around, but likely too embarrassing to point you to
  1291. Syndace I kind of lost track, MattJ do you want the slack-like use-case to be covered or did you just note that it exists?
  1292. eta MattJ, I have a low tolerance
  1293. eta or a high one
  1294. Zash Syndace, should probably be separate from the quick reply thing
  1295. eta whichever it is :P
  1296. MattJ I think it was hosted on some forge that no longer exists
  1297. eta ah
  1298. mukt2 has left
  1299. MattJ But I think I have it in backups
  1300. Syndace Zash agreed
  1301. MattJ Syndace, Zash: but it's the same UI...
  1302. MattJ and essentially all the same business rules
  1303. MattJ Just one sends a body, and one does not
  1304. Zash MattJ: Not quite, not if you wanna clone it. Slack lets you do full on forms IIRc.
  1305. MattJ I don't particularly want to clone it
  1306. Syndace hmm, one needs client support that probably has to be discovered, the other is just plain text
  1307. MattJ No, it doesn't have to be discovered if you're fine with it being optional
  1308. MattJ and discovery in a MUC would be a nightmare
  1309. MattJ So this is an optional shortcut thing
  1310. Nekit has joined
  1311. MattJ (and that's exactly how it gets used in Slack)
  1312. eevvoor has left
  1313. Syndace okay I'm not farmiliar with the slack buttons, can you give an example please?
  1314. MattJ e.g. a PR notification in a MUC has a merge button. But you could also open the link and click the merge button
  1315. Zash `<action>[ <body/> | <{jabber:x:data}/> | the json xep </>`
  1316. pep. I guess I can just not implement it in poezio then, that simplifies UX issues.
  1317. Syndace ah, so quick link-click in addition to quick response? 😀
  1318. pep. unless now you add a different meaning to it
  1319. Syndace or wait, merging is quite specific and probably needs slack to "understand" git?
  1320. arc has left
  1321. arc has joined
  1322. MattJ Syndace, it's just handled by bots
  1323. MattJ Slack doesn't understand any of this
  1324. MattJ The bot posts a message in a Slack room, when a user clicks a button, the bot gets informed about that
  1325. MattJ (there is some fancier stuff too, but my goal is not to fully clone Slack)
  1326. Syndace you could define the quick response button to send /merge or !merge on click, if the bot understands that?
  1327. MattJ This is a really simple feature that would make such a nice UX improvement
  1328. MattJ Yes, you could
  1329. MattJ I would just rather keep the body optional, so I can make the decision as a bot author
  1330. mukt2 has joined
  1331. Zash MattJ, specify reply payload as either text or Some XML Stuff™, bot decides, click sends that.
  1332. serge90 has left
  1333. Zash Cry in i18n for a while, done.
  1334. serge90 has joined
  1335. MattJ I don't even care (much) about arbitrary XML stuff, just include <button-clicked id="id-of-button"/>, and if there was a body associated with that button, include that too
  1336. MattJ But I should stop talking about buttons
  1337. pep. and now that you've mentioned hats, I'm also curious what UI for that would look like in a terminal..
  1338. waqas has left
  1339. Zash pep., mouse support exists :P
  1340. pep. Zash: what about it (and no!)
  1341. MattJ <quick-response id="id-of-response"/>
  1342. Zash whatabouti18n?
  1343. MattJ What about?
  1344. Syndace I'm sorry I still don't get the difference 😕 You want to notify the bot about the click directly instead of sending a plaintext message to the chat?
  1345. MattJ Isn't all this in the XEP already?
  1346. Zash Yes
  1347. MattJ The XEP is what I want
  1348. MattJ The end
  1349. MattJ I don't see what's so complicated
  1350. MattJ Client receives a message with a list of associated shortcuts/actions/quick-replies. Client renders them potentially as buttons. Each button has an id, and an optional body text.
  1351. serge90 has left
  1352. serge90 has joined
  1353. Ge0rG You could respond as a PM.
  1354. MattJ If the client supports rendering these, and the user selects one of them, then a message is generated containing the response's body text (if any) and <quick-response id="id-of-selected-response"/>
  1355. MattJ Why?
  1356. MattJ Why complicate things?
  1357. Ge0rG Also your MAM implementation will drop the responses with no body
  1358. MattJ You're in a chat, it's a response to a message in that chat, why would you send it elsewhere?
  1359. Ge0rG Because O(n²)
  1360. MattJ ?
  1361. Ge0rG When everyone responds to everyone
  1362. MattJ What?
  1363. Zash Same problem as with reactions?
  1364. MattJ That's an argument against group chats of any kind?
  1365. MattJ I'm responding to you right now, is that O(n²)?
  1366. mukt2 has left
  1367. Syndace both an id and a payload in the click response probably doesn't make sense: either you listen for the id, then the payload is pointless, or you listen for the payload, then the id is pointless
  1368. MattJ By "payload" you mean a text body, right?
  1369. Syndace yeah
  1370. Ge0rG Syndace: it's useful if you share the room with legacy clients
  1371. MattJ It serves as a fallback for legacy clients at that point, or bots implementations that don't care for id tracking (which may be many)
  1372. mukt2 has joined
  1373. MattJ If you had a voting bot for example in a meeting in a MUC, you would totally want +1/-1 to appear in the chat logs
  1374. MattJ But there are more ephemeral actions that you wouldn't care so much about
  1375. Syndace ah okay so just to have clients supporting the XEP not spam plaintext
  1376. Syndace sounds good
  1377. MattJ Yes
  1378. goffi has joined
  1379. pep. where is the written "+1" if your support the xep
  1380. MattJ pep., ?
  1381. pep. implemented and understood by the log writer?
  1382. MattJ It's in <body>, it's understood by everyone (I hope)
  1383. serge90 has left
  1384. pep. not sure I understand the following then > ah okay so just to have clients supporting the XEP not spam plaintext
  1385. serge90 has joined
  1386. pdurbin has joined
  1387. MattJ That's for the case where there is no plaintext equivalent
  1388. MattJ The +1/-1 example was a case where you do want it to go in the logs and include a <body>
  1389. Syndace oh okay, then my initial question still stands: why would you want _both_ and id and plaintext?
  1390. pep. so if there's a body a client must always include it?
  1391. MattJ I don't see it's as entirely necessary, it just feels like a neater protocol/implementation
  1392. MattJ pep., yes
  1393. Syndace it's like you send "+1" and there is an XML element that says "this is a +1!"
  1394. MattJ Syndace, an example would be if there were multiple messages and the id can be used to resolve ambiguity. But that's a stretch (because you'd need to handle non-button responses anyway)
  1395. bear has joined
  1396. MattJ But it seems sensible to have some machine-readable semantics underneath if it's known, rather than throwing that context away
  1397. serge90 has left
  1398. serge90 has joined
  1399. Syndace To me it would feel weird if the same visible message has different effects under the hood
  1400. jubalh has joined
  1401. Syndace as in, a message that has both the plaintext and the id is treated differently then a message that only has the plaintext
  1402. mukt2 has left
  1403. Syndace anyway, I'm happy that we have consensus on where this XEP should be going and I'd like to see it revived with the results of that discussion
  1404. xsf has joined
  1405. adiaholic_ has left
  1406. adiaholic_ has joined
  1407. MattJ What exactly needs to change from what was previously submitted?
  1408. Jeybe has left
  1409. Jeybe has joined
  1410. MattJ If we can identity that, and who is going to write it up, we're good
  1411. MattJ And don't have to revisit these discussions yet again in another year :)
  1412. werdan has left
  1413. mukt2 has joined
  1414. xecks has left
  1415. xecks has joined
  1416. Syndace it should be renamed and the use case should be clarified, the id added and maybe clarification regarding i18n and when exactly to show buttons
  1417. pdurbin has left
  1418. serge90 has left
  1419. serge90 has joined
  1420. MattJ Sounds good. You/Zash want to tackle it? Or I'm happy to otherwise. I'm currently in a spec-writing sprint so I can tack it onto my queue if necessary
  1421. Syndace Maybe it's time for my first XEP, also as training for Master Key (tm)
  1422. Syndace If Zash doesn't want it, I would do it
  1423. Zash Feel free to take over or add yourself as co-author :)
  1424. Syndace cool 🙂
  1425. MattJ Excellent :)
  1426. Tobias has left
  1427. Zash <hat:council> I'll review it for you tho ;)
  1428. Zash MattJ, hats!
  1429. MattJ Coming soon
  1430. MattJ After I finish MAM
  1431. Jeybe has left
  1432. Jeybe has joined
  1433. serge90 has left
  1434. Guest has joined
  1435. serge90 has joined
  1436. adiaholic_ has left
  1437. adiaholic_ has joined
  1438. Guest has left
  1439. Shell has left
  1440. serge90 has left
  1441. Jeybe has left
  1442. Jeybe has joined
  1443. serge90 has joined
  1444. Maranda I'm not sure what I did change that made Movim merrily start doing 0215 queries
  1445. pep. Maranda, https://github.com/movim/movim/commit/ce299e038c321c932441722885746efc3b3cedd2 ?
  1446. pep. Maybe you haven't changed anything
  1447. Maranda pep., huhu and edhelas put it live on NL right away :O?
  1448. pep. Sure
  1449. edhelas :3
  1450. serge90 has left
  1451. Maranda :D
  1452. edhelas too fast 4 u
  1453. serge90 has joined
  1454. Maranda still I'm not sure why the call fails from my laptop to the other one, but not viceversa
  1455. Maranda (using two different account)
  1456. robertooo has left
  1457. adiaholic_ has left
  1458. adiaholic_ has joined
  1459. Maranda would be interesting to know what it does trample on
  1460. lorddavidiii has left
  1461. serge90 has left
  1462. serge90 has joined
  1463. jubalh has left
  1464. mukt2 has left
  1465. Jeybe has left
  1466. mukt2 has joined
  1467. Jeybe has joined
  1468. serge90 has left
  1469. serge90 has joined
  1470. Zash has left
  1471. Zash has joined
  1472. mukt2 has left
  1473. mukt2 has joined
  1474. goffi has left
  1475. Jeybe has left
  1476. Jeybe has joined
  1477. Jeybe has left
  1478. Jeybe has joined
  1479. serge90 has left
  1480. serge90 has joined
  1481. Jeybe has left
  1482. Jeybe has joined
  1483. serge90 has left
  1484. serge90 has joined
  1485. serge90 has left
  1486. serge90 has joined
  1487. Shell has joined
  1488. arc has left
  1489. arc has joined
  1490. Shell has left
  1491. Shell has joined
  1492. serge90 has left
  1493. serge90 has joined
  1494. Shell has left
  1495. pep. has left
  1496. paul has left
  1497. pep. has joined
  1498. serge90 has left
  1499. serge90 has joined
  1500. Jeybe has left
  1501. Jeybe has joined
  1502. arc has left
  1503. arc has joined
  1504. Jeybe has left
  1505. Jeybe has joined
  1506. xecks has left
  1507. serge90 has left
  1508. serge90 has joined
  1509. serge90 has left
  1510. serge90 has joined
  1511. Jeybe has left
  1512. serge90 has left
  1513. serge90 has joined
  1514. serge90 has left
  1515. serge90 has joined
  1516. Shell has joined
  1517. andy has left
  1518. mimi89999 has left
  1519. mimi89999 has joined
  1520. serge90 has left
  1521. serge90 has joined
  1522. aj has joined
  1523. serge90 has left
  1524. serge90 has joined
  1525. serge90 has left
  1526. serge90 has joined
  1527. pdurbin has joined
  1528. serge90 has left
  1529. serge90 has joined
  1530. mukt2 has left
  1531. Shell has left
  1532. arc has left
  1533. arc has joined
  1534. karoshi has left
  1535. aj has left
  1536. mukt2 has joined
  1537. pdurbin has left
  1538. serge90 has left
  1539. serge90 has joined
  1540. wurstsalat has left
  1541. mimi89999 has left
  1542. mimi89999 has joined
  1543. mukt2 has left
  1544. mukt2 has joined
  1545. serge90 has left
  1546. serge90 has joined
  1547. serge90 has left
  1548. Nekit has left
  1549. serge90 has joined
  1550. mimi89999 has left
  1551. mimi89999 has joined
  1552. debacle has left
  1553. serge90 has left
  1554. serge90 has joined
  1555. serge90 has left
  1556. serge90 has joined
  1557. serge90 has left
  1558. serge90 has joined
  1559. arc has left
  1560. arc has joined
  1561. arc has left
  1562. arc has joined
  1563. arc has left
  1564. arc has joined
  1565. serge90 has left
  1566. serge90 has joined
  1567. serge90 has left
  1568. serge90 has joined
  1569. emus has left