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


  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


  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.


  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


  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


  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


  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


  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


  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


  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


  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


  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


  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


  1147. Syndace

    buttons are just a more convenient way to send a fixed string

  1148. pep.


  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


  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


  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.


  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


  1230. pep.


  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


  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


  1257. pep.


  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


  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


  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


  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


  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


  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


  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


  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


  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.


  1449. edhelas


  1450. serge90 has left

  1451. Maranda


  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