XSF Discussion - 2020-04-19


  1. jonas’

    just get snikket listed there

  2. 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"

  3. !XSF_Martin

    And afaik it is stored forever.

  4. Daniel

    They have to please their investors somehow

  5. Maranda

    Erm didn't Riot.im stop using Matrix? Or am I confusing with something else?

  6. !XSF_Martin

    I guess you are. It is their main client.

  7. Zash

    The flagship Matrix client even.

  8. Maranda

    Zash, oh sorry confused with disroot

  9. Maranda

    And I can't find a client which actually uses either xep 215 or 278 to fetch sturn/turn data for A/V

  10. Maranda

    Jitsi which supposedly should use Jingle Relay Nodes, does SRV look ups.

  11. jonas’

    Jitsi Meet does '215

  12. jonas’

    but I haven’t gotten it to actually use the results…

  13. Maranda

    jonas’, Jitsi Meet is a bit too much OOB for my likings.

  14. Maranda

    Movim uses a hardcoded list of stun services which almost never work...

  15. Neustradamus

    Holger: https://github.com/processone/ejabberd/issues/3229

  16. Holger

    Neustradamus: Do you have a client that would use this?

  17. Holger

    Neustradamus: E.g. the WebRTC spec explicitly doesn't support this.

  18. Holger

    > Jitsi Meet does '215 Only extdisco:1 though. (Dunno whether Maranda uses Prosody's mod_turncredentials which supports that.)

  19. Neustradamus

    Holger: I will search...

  20. Neustradamus

    Holger: STUN ejabberd works with IPv6?

  21. Holger

    Neustradamus: No.

  22. Neustradamus

    A ticket is needed too :/

  23. Neustradamus

    https://github.com/jselbie/stunserver

  24. Holger

    Neustradamus: Someone having time to implement such stuff is needed 🙂

  25. Maranda

    Holger, Metronome has mod_extdisco which supports both 1 and 2 fully (aka has support for <credentials /> queries)

  26. Neustradamus

    Holger: Can you move my ticket in the good repository?

  27. Maranda

    at least in the latest commits, also I implemented jingle relay nodes tonite.

  28. 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 …

  29. 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

  30. Maranda

    which tells much about the UX there

  31. jonas’

    Maranda, yeah, the UX is pretty amazing

  32. jonas’

    you only need the URL to the meeting

  33. Holger

    Maranda: Well it's all XMPP but without roster, yes. Different use case.

  34. Holger

    The XMPP account is usually an anon account.

  35. 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

  36. 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.

  37. Holger

    Neustradamus: If you have a link to any STUN/TURN client dev making such a statement I'd be interested.

  38. Neustradamus

    Holger: coturn supports it :) - https://github.com/coturn/coturn/blob/master/README.md

  39. Holger

    Neustradamus: I know that. That's good, no? Client devs interested in it could just use that.

  40. Holger

    Neustradamus: And ejabberd admins interested in offering that could just set up coturn.

  41. 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.

  42. Guus

    It's an older spec that we know has at least one fairly popular user. Who knows what we don't know about.

  43. Guus

    Apologies if my drive-by reading of this caused a misinterpretation of what you actually mean.

  44. Zash

    Come to think of it, why wasn't http upload made on this?

  45. MattJ

    Nice thought

  46. Zash

    Not an exact fit tho

  47. Holger

    Guus: https://github.com/jitsi/jitsi-meet/issues/5786

  48. 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.

  49. 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.

  50. 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?

  51. 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.

  52. Holger

    Guus: Ah, no not at all.

  53. Guus

    My bad, carry on. 😁

  54. 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.

  55. Guus

    Openfire has a dead simple plugin that supported what Meet needed a couple of years ago.

  56. Guus

    Nothing after that

  57. Guus

    Iirx

  58. 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)

  59. Guus

    We publish standards. People using them must be able to rely on some form of stability.

  60. flow

    pep., could you clarify with what exactly you disagree with?

  61. pep.

    keeping backwards compat forever and never deprecating anything because !!!

  62. pep.

    "some implementations might.."

  63. 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

  64. 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.

  65. Zash

    I got the impression that they had a fork of the Prosody plugin

  66. Kev

    It's fine to deprecate support for X.Y, but any X.Y implementations should interop

  67. 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

  68. pep.

    Kev: well that's the point, if you always keep backwards compat then the protocol never evolves

  69. Kev

    A given version of the protocol doesn't evole, that's kinda the point.

  70. flow

    what Kev says

  71. Guus

    I'm fine with breaking changes, but not without a new namespace to ensure that the old version remains unchanged/compatible

  72. Kev

    If you want to do new backwards-incompatible things, you signal that.

  73. pep.

    then you get things like "we should do bind2 / im-next"

  74. Kev

    Guus: Actually, usually a feature flag is preferable to a ns bump, IMNSHO.

  75. pep.

    there's still a migration in between that's required

  76. Guus

    Kev: sure. Some kind of identifying thing suffices

  77. 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.

  78. 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)

  79. flow

    Holger, so its about changing the code to match the xep, and not bumping the xep to match the code, right?

  80. Holger

    flow: Yes.

  81. flow

    pep., obviously a namespace bumped xep protoocl is (typically) not compatible with the previous namespace protocl version

  82. flow

    if that's includes what you are expressing with x.y+1

  83. flow

    so I somehow think we me be all on the same page of the same book but written in different languages ;)

  84. Guus

    I'm thinking we're all pretty much mean the same

  85. Holger

    It's Sunday so we're all procrastinating to avoid family things?

  86. MattJ

    I think some things changed when we introduced namespace versioning

  87. flow

    so I somehow think we may be all on the same page of the same book but written in different languages ;)

  88. flow

    Holger, already did my obligatory bike ride with two kids in the trailer!

  89. MattJ

    In the olden days, an experimental XEP just changed

  90. flow

    I guess there was a reason why this is no longer the case

  91. Holger

    flow: 👍

  92. jonas’

    MattJ, <3

  93. flow

    I guess there is a reason why this is no longer the case

  94. 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

  95. MattJ

    and possibly even contributed to the laziness about advancing them

  96. flow

    MattJ, part of the problem is that we have to staging area for breaking changes

  97. MattJ

    That used to be experimental, is basically what I'm saying

  98. MattJ

    which is why it's called experimental, and that status has the description text it has

  99. 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

  100. MattJ

    I think in hindsight (which nobody had back then), introducing namespace versioning should have been bundled with other changes

  101. flow

    there is no reason we can't have stable namespaces (urn:xmpp:foo:1) and staging namespaces (urn:xmpp:foo:2-snapshot)

  102. 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.

  103. 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)

  104. jonas’

    flow, but then you can’t promote 2-snapshot to 2 without touching all pieces of software, see above

  105. MattJ

    jonas’, shorthand for "namespace-based versioning", i.e. versioning the protocol by bumping the namespace

  106. jonas’

    MattJ, that makes much more sense, thanks

  107. flow

    MattJ, true, but that doesn't mean that it suddenly does not make sense to have that disclaimer for experimental

  108. flow

    jonas’, I think a sed would be sufficient

  109. MattJ

    Jitsi Meet is successful software using an experimental XEP in a production setting

  110. jonas’

    flow, go and sed all existing debian packages of $client then.

  111. flow

    jonas’, that would make no sense

  112. 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

  113. MattJ

    and if we're going to protect implementations of experimental XEPs from breaking changes, we needn't have that disclaimer

  114. 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.

  115. MattJ

    Yes, namespace bumps hurt - another thing that wasn't clear at the time, without implementation experience

  116. 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

  117. jonas’

    flow, that’s not how it works

  118. jonas’

    otherwise, software wouldn’t implement and ship Experimental XEPs by default

  119. flow

    because a -snapshot is for experimenting in an agile way with unstable protocol extensions

  120. Zash

    End users don't care about Experimental or not

  121. 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

  122. jonas’

    and then it gets promoted to :2

  123. flow

    you'd never would want them to be available for end-users. otherwise you would risks XMPP reputation

  124. jonas’

    and we can only learn that it works by deploying it

  125. 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

  126. 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

  127. 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

  128. flow

    jonas’, experimental xeps a bump namespace on breaking changes are very different to -snapshot namespaces

  129. 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.

  130. flow

    jonas’, experimental xeps with a bump namespace on breaking changes policy are very different to -snapshot namespaces

  131. flow

    as other said, nobody cares about if it's called experimental or not

  132. flow

    what matters is that the protocol identified by its namespace is interoperable.

  133. flow

    and that is not true for -snapshot namespaces

  134. 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.

  135. Kev

    It's all somewhat more nuanced than the stages suggest.

  136. 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

  137. flow

    but we are obviously very bad at preparing new backwards-incomptabile versions of XEPs

  138. jonas’

    flow, you did by saying that -snapshot should not be delivered

  139. jonas’

    or do you honestly think that carbons in its current state wouldn’t be -snapshot?

  140. flow

    jonas’, I think you are reading more into it than I actually said

  141. 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?

  142. flow

    jonas’, I think there could be an upper bind in time after which -snapshot gets into a stable namesapce

  143. flow

    then everyone would know how long he has to get his favorite change into the new xep version

  144. flow

    jonas’, proposed and "accepted" changes are staged in a -snapshot namespace for x time, after that it becomes the stable namespace

  145. jonas’

    what if another change happens in x time?

  146. jonas’

    does that delay the propagation of the first change to stable?

  147. flow

    details we could discuss, but this basically mimics certain software development models

  148. flow

    but it is obvious that it should not be possible to delay a new stable namespace forever

  149. jonas’

    I’m not so sure that you can simply transfer software development models to standards/protocol development models

  150. flow

    I think you can do, we already do namespace versioning

  151. flow

    (obviously you can not do everything from one domain into another)

  152. flow

    (obviously you can not transfer everything from one domain into another)

  153. flow

    but aren't xeps managed in a source code control system?

  154. pep.

    I think any solution based on time is naïve. We know all too well the "volunteer effect"

  155. flow

    pep., I am always happer to hear different better ideas

  156. flow

    pep., I am always happy to hear better ideas

  157. 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

  158. 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

  159. 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

  160. 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

  161. flow

    right, we could do that too. but it is not really an argument against what I suggested

  162. pep.

    Sure

  163. pep.

    Anyway I still think people are always afraid to break anything even if that would make things better and that annoys me

  164. 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

  165. 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

  166. lovetox

    hm can someone stop MattJ from bumping the namespace of the MAM XEP?

  167. lovetox

    just in theory

  168. Daniel

    everyone has a price

  169. lovetox

    i thought experimental XEPs are totally in the hands of the Author

  170. lovetox

    if he doesnt change the nature of the XEP

  171. jonas’

    lovetox, council can take authorship away

  172. jonas’

    and then they could either roll back or instruct the editor to hold the PR

  173. Zash

    Wasn't it to be an additional feature?

  174. lovetox

    i wonder because it seems all very subjective and council members seem only to really care about XEPs they care about

  175. 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

  176. lovetox

    Daniel but nobody forces you to support these, really if you support :1 and :2 this is already very good

  177. lovetox

    i hope you dont support :0 and :tmp

  178. Zash

    This is the price you pay for deploying Experimental XEPs :)

  179. pep.

    I guess paid work incentives people to support ancient tech forever

  180. Daniel

    i support 0; because openfire i think

  181. Zash

    Mmm, deployment stats would be handy

  182. Zash

    Current stable Prosody does only :2 unless you go for 3rd party MAM module. Similar with Carbons.

  183. lovetox

    yeah next Gajim version will only support :2

  184. pep.

    For what poezio support it's only :2

  185. lovetox

    :2 is already years old

  186. pep.

    For what poezio supports it's only :2

  187. 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?

  188. Ge0rG

    Was that for PubSub still?

  189. 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.

  190. Ge0rG

    On a personal archive that makes sense. What about on a semi anonymous MUC?

  191. Zash

    Is 'with' even used in MUCs?

  192. Zash

    The Prosody implementation just ignores that field on MUCs

  193. Zash

    (actually because the internal field is overloaded and used for something else there)

  194. 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.

  195. Ge0rG

    Kev: that makes sense

  196. Ge0rG

    Maybe I should reword my question into: "the rationale for this should be added to the XEP"

  197. Ge0rG

    Also I'm confused about that custom <flip-page/> element inside a data form. Why not a boolean field?

  198. Zash

    Wait, inside?

  199. Ge0rG

    Cc MattJ

  200. Zash

    Not as a sibling to?

  201. Ge0rG

    Oh, maybe yes. I'm reading the diff by flow

  202. Ge0rG

    Still, my question remains

  203. Zash

    Because it's related to the result page, not the query?

  204. Ge0rG

    Also what's the benefit of defining the gone error condition over just item-not-found?

  205. Zash

    Huh

  206. MattJ

    Ge0rG, isn't the rationale for that in the XEP?

  207. MattJ

    :)

  208. Zash

    before-/after-id selects an exclusive (excluding? words?) range?

  209. 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.

  210. Ge0rG

    MattJ: the rationale for with=account? I must have missed it

  211. MattJ

    The rationale of <gone/>

  212. Ge0rG

    MattJ: yes, there is one. But is it really useful to have?

  213. Zash

    Doesn't gone mean the JID (you're talking to) has gone away?

  214. Ge0rG

    Is there any additional information for the client in it?

  215. MattJ

    Yes

  216. Ge0rG

    Threads, where are you?

  217. Zash

    Seems a stretch to use 'gone' for items when there's an 'item-not-found'?

  218. 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.

  219. 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.

  220. MattJ

    <item-not-found/> is ambiguous, e.g. if the archive was restored from a backup

  221. MattJ

    so with item-not-found you can't assume that the id was ever known to the server

  222. Zash

    Why not a custom error condition?

  223. Ge0rG

    MattJ: but what does that knowledge give me?

  224. MattJ

    Ge0rG, that resyncing the archive would potentially be a very wrong thing to do

  225. Ge0rG

    MattJ: and that I should do what instead?

  226. MattJ

    Because you'll just refetch an entire archive of messages you already have

  227. MattJ

    You're the client dev, you decide :)

  228. Ge0rG

    So I have to re-fetch the whole archive to see where the server has new data.

  229. MattJ

    You can page backwards instead, or do something time-based, etc.

  230. Ge0rG

    MattJ: but that's also what I'd do on gone.

  231. 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.

  232. Ge0rG

    MattJ: because you can't guarantee that I'll actually get gone as a dedicated error at all

  233. MattJ

    You're right that <gone/> may be misinterpreted, so a custom condition probably does make sense

  234. Ge0rG

    MattJ: you could help me by returning me the timestamps and IDs around the gap

  235. 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

  236. MattJ

    Missing messages in-between are forbidden by the XEP

  237. MattJ

    So if something is missing it's missing at either the start or the end

  238. Ge0rG

    MattJ: you can only solve that by demanding that I request an ID and the respective timestamp

  239. Ge0rG

    MattJ: but you just said restored from archive

  240. Ge0rG

    That implies there are missing messages in the middle

  241. Zash

    This reminds me of what I've heard of how version control things do sync

  242. Ge0rG

    MattJ: because after the restore there will be new messages added

  243. MattJ

    At some point, yes

  244. Ge0rG

    MattJ: yes, so I don't see the point.

  245. MattJ

    Well, better suggestions welcome

  246. MattJ

    Otherwise I can nuke any attempt at trying to provide the client some useful information about what might be going on

  247. 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

  248. 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

  249. MattJ

    differently to...? What would you do today?

  250. Ge0rG

    Which makes backups useless

  251. Zash mumbles something about pointer to previous message something something linked list

  252. Ge0rG

    MattJ: a full sync for 7 days or some such

  253. MattJ

    So you may still download 6.9d of messages you already have

  254. Ge0rG

    MattJ: so you suggest that I go backwards from $NOW until I encounter a known message?

  255. Zash

    Ask for the last message in the archive, ???, do something with that

  256. MattJ

    (the last message id/timestamp could be included in the error, as Ge0rG suggested)

  257. Ge0rG

    Zash: the last message in the archive will be from just five minutes ago

  258. MattJ

    (last and first?)

  259. Ge0rG

    The first message in the archive will be either before or after the last message the client knows about

  260. Ge0rG

    And that would be somehow actionable for me

  261. 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

  262. Ge0rG

    If it's before, then there is a hole in the archive

  263. MattJ

    FWIW my plan for bind-ng was to include the id of the first/last message in the archive already

  264. 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.

  265. Ge0rG

    There is no way to resync that with an archive that has unknown holes.

  266. MattJ

    I agree, unknown holes are the enemy and are what I'm trying to prevent (as well as useless full resyncs)

  267. MattJ

    So I'm trying to give the client information that it can use, because a simple "it's not here" is not enough

  268. Ge0rG

    And a client that doesn't need to store in chronological order will just page backwards in any case

  269. Ge0rG

    MattJ: why not?

  270. MattJ

    Because it could mean you didn't sync soon enough and you missed some messages, the archive was purged, or it was restored

  271. Ge0rG

    Especially given that most implementations won't actually be able to tell me "your ID is too old and got wiped" anyway

  272. MattJ

    Ok, so I'll remove it I guess

  273. MattJ

    Maybe bind-ng can fill the gap instead

  274. Ge0rG

    MattJ: you could make it mandatory to store all IDs forever, that would make the feature useful

  275. Zash

    Or blockchain!!!!

  276. Ge0rG

    What Zash said

  277. MattJ

    I'm not going to make that mandatory, but there are other ways to implement this

  278. MattJ

    (ordered ids, for example)

  279. Ge0rG

    MattJ: a bloom filter?

  280. Ge0rG

    Ordered and encrypted?

  281. Ge0rG

    Timestamp plus random salt encrypted with a private key, so that the server can reverse it?

  282. MattJ

    Exactly

  283. Ge0rG

    See, it's so easy. Make it mandatory!

  284. Ge0rG

    Oh, also renumber all existing archives!

  285. Zash

    Oh glob

  286. jonas’

    Ge0rG, no, renumbering would be too invasive

  287. MattJ

    That's exactly why I didn't make it mandatory

  288. jonas’

    let’s just introduce another ID :)

  289. Ge0rG

    Also all client copies, synchronously!

  290. Zash

    High precision timestamp

  291. Ge0rG

    MattJ: just add a way to query the size of the archive

  292. MattJ

    The size doesn't really help

  293. MattJ

    unless you mean time period

  294. MattJ

    But I hesitate to do anything much based on timestamps

  295. Ge0rG

    The size can be measured in days as well

  296. Ge0rG

    Yeah, I understand that

  297. Ge0rG

    I understand the rationale now and see how you could pull it off. But would you actually do that in prosody?

  298. MattJ

    Potentially, yes, if it can be done in a sane way

  299. MattJ

    But now it may just be better to replace this all with a query that returns some metadata about the archive

  300. MattJ

    The first/last ids and timestamps

  301. MattJ

    Even more info in the hands of clients

  302. Zash

    Summary thing?

  303. MattJ

    Summary!

  304. Ge0rG

    Or have a multi query where the client sends its last known ID and timestamp and the server just fills up

  305. Ge0rG

    Smart servers, dumb clients!

  306. Zash

    And thus the pendulum swings

  307. Ge0rG

    The MAM logic for matching reflected own messages is maddening already.

  308. Guus

    Daniel: > i support 0; because openfire i think Openfire has 0, 1 and 2.

  309. Ge0rG

    Also I must filter all my local MAM ID lookups on incoming-only

  310. Ge0rG

    Also encrypting information into the archive UID might end up with all sorts of bad effects, if done incorrectly

  311. Zash

    Weren't you the one who disliked long IDs, Ge0rG?

  312. Ge0rG

    Zash: I still am

  313. Zash

    MattJ and I discussed / looked at Twitters snowflake (?) id stuff, which is a 64bit integer

  314. 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

  315. Ge0rG

    MattJ: Re with=account, > Maybe I should reword my question into: "the rationale for this should be added to the XEP"

  316. Ge0rG

    > Also I'm confused about that custom <flip-page/> element inside a data form. Why not a boolean field?

  317. MattJ

    I think both of those were answered, and now I'm on a mobile keyboard

  318. MattJ

    The latter isn't a filter

  319. Ge0rG

    MattJ: it's a kind of a filter.

  320. MattJ

    It's not part of the criteria

  321. Ge0rG

    MattJ: well yeah, I just wondered if it wouldn't be easier to re-use existing protocol

  322. MattJ

    For with, the reason is given in the XEP

  323. lovetox

    Ge0rG, that flip page thing is a bit inbetween worlds

  324. lovetox

    the dataform in MAM represents the filter you request from the database

  325. Ge0rG

    MattJ: the sentence for with doesn't even end in a full stop. I'm sure it's missing more

  326. lovetox

    afterwards you specify with RSM the page settings

  327. 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

  328. lovetox

    now flip page is not part of rsm but its also not a filter

  329. MattJ

    It's the rationale

  330. lovetox

    actually in a perfect world flip-page would be in the RSM XEP, but sadly its not

  331. MattJ

    It's not technical, it could have not been added, and then there would be no way to search for messages with yourself

  332. 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."

  333. Ge0rG

    "the bare JID of the archive" is weird at least for a MUC archive

  334. MattJ

    Potentially, yeah

  335. Ge0rG

    MattJ: feel free to quote that in the new XEP

  336. MattJ

    "the bare JID of the archive" is weird at least for a MUC archive"

  337. MattJ

    Ok ;)

  338. Ge0rG

    :P

  339. 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

  340. dhtgh

    how can i solve it?

  341. Zash

    Hey. I'm not sure that this is the right place for that. More context needed.

  342. 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?

  343. Zash

    https://xmpp.org/extensions/inbox/buttons.html ?

  344. Zash

    Syndace, basically, the result was those exact questions, to which I haven't had the energy to XEP up an answer yet.

  345. Syndace

    Ah yes, exactly that

  346. Syndace

    Alright thanks

  347. Zash

    There's precedent for sending dataforms in messages, tho awkward for what I was aiming for

  348. Zash

    Help getting that back on track would be appreciated

  349. Zash

    Either by figuring out if we can just shove ad-hoc commands in messages or dataforms or continue with that

  350. Syndace

    continue with "that"?

  351. Syndace

    I'm afraid I have to read a few XEPs before I can be of use here

  352. Syndace

    Will do though, I'd really like to see that being specified

  353. Zash

    Syndace: with that protoxep*

  354. MattJ

    I no longer work on the implementation I wanted that spec for

  355. Zash

    Find an excuse to do it in Snikket?

  356. Syndace

    isn't there also some movement regarding a (http based) bot API?

  357. Syndace

    I think those two things go together well

  358. MattJ

    Yes

  359. Zash

    🤖️> The build of *thing* failed. [abort] [retry] [send angry message to author of latest change]

  360. !XSF_Martin

    Threaten the author to not use their software!!!!elf!!eleventy

  361. Zash

    What you think you said. ↑ What unpaid volonteer developer hears: I will decrease your support load!!!!

  362. !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.

  363. 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.

  364. Syndace

    I'd rather have a way to say "please display the data form in this message somewhere inline"

  365. Zash

    Syndace, study this: https://xmpp.org/extensions/xep-0045.html#requestvoice

  366. lovetox

    Syndace, just put a form into a message

  367. lovetox

    if a client supports showing forms he can display them

  368. lovetox

    for example Gajim has a plugin that shows forms in the chat

  369. Syndace

    well there must be a gotcha with that, otherwise Zash's protoxep wouldn't exist?

  370. Zash

    Tho the buttons protoxep was more about having a list of buttons

  371. Zash

    Syndace, yes, how do you represent a simple button with a form?

  372. Syndace

    ah right, that

  373. lovetox

    the question is why would you need to show more than one button?

  374. flow

    Zash, simple button? like only one choice?

  375. Zash

    form's don't have any actions or such attached

  376. lovetox

    if you want to choose, you can show radio buttons

  377. Zash

    even in ad-hoc those are separate

  378. lovetox

    it would also trivial to add something to a form, so a client shows buttons instead of radio buttons, for single-list type

  379. Zash

    I had some text about this somewhere

  380. lovetox

    hm but that makes no sense .. you have to send the form

  381. Syndace

    so one challenge is buttons with forms

  382. flow

    I am sorry, but I don't get the issue here with forms? Are we talking about yes/no buttons?

  383. 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?

  384. flow

    i'd say that is specified in the data form xep

  385. flow

    i.e., you send the submit form back

  386. lovetox

    Syndace, this is already all specified

  387. lovetox

    we use forms everyday

  388. Syndace

    then please rephrase > form's don't have any actions or such attached

  389. Zash

    flow, do or don't forms rather

  390. flow

    hmm, "do or don't forms"?

  391. flow

    can you give an example?

  392. Zash

    flow, I offer you a button. You click it, or you don't.

  393. flow

    Zash, wouldn't that be just to submit the form or not?

  394. flow

    potentially with a single boolean or text-single field?

  395. Zash

    a single FORM_TYPE

  396. Zash

    + you can have title, description

  397. flow

    not sure if that would work. isn't FORM_TYPE just the "namespace" of forms?

  398. flow

    ahh ok, with more textual content, then yes

  399. Zash

    How about: A form with only hidden fields

  400. Zash

    And you want to support more than one per message

  401. Zash

    so a bot can say [abort] [retry] [cancel]

  402. Zash

    `<x xmlns="jabber:x:data" type="form"><title>Click me</title></x>`

  403. Zash

    If there are fields other than hidden you'd render it as a form and like have a Submit button on it

  404. MattJ

    Oh no, not this discussion again

  405. MattJ

    Data forms don't support buttons, and clients will never implement them, and it will be a usability nightmare

  406. Syndace

    okay so that's why the protoxep doesn't just use data forms

  407. lovetox

    MattJ, i dont know what you mean by "Buttons"

  408. 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)

  409. Zash

    Syndace, there was an idea about using dataforms (or anything) as payload

  410. MattJ

    The idea is that it's easier to send a quick predefined response to a message by tapping a button

  411. Zash

    Syndace, basically you get a bunch of <button>s, any xml content in those get sent back in a <click> container when clicked

  412. Zash

    then you use dataforms or json or whatever

  413. MattJ

    The use case is bots, where the possible responses are generally limited/fixed

  414. lovetox

    MattJ why cant i choose my response from a radiobutton selection and press send?

  415. MattJ

    Because clients don't (and won't) implement that

  416. MattJ

    and it becomes ambiguous if a client doesn't implement forms

  417. lovetox

    But they would implement buttons?

  418. Zash

    lovetox, how do you know it's a set of distinct buttons and not a form with a select dropdown?

  419. MattJ

    Yes, because it's far simpler

  420. 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?

  421. Syndace

    no need for data forms if we're at that point?

  422. Zash

    Syndace, for what?

  423. Syndace

    To make a client display buttons and get a response when one is clicked

  424. 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

  425. Zash

    xep rejected by council, I've no energy to spend on that, ???, nothing

  426. 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

  427. 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

  428. Syndace

    agreed, I think data forms is "too flexible" here

  429. MattJ

    This won't be added to, because it does just one very simple well-defined thing

  430. lovetox

    until one wants to add something really simple to it

  431. MattJ

    Then we reject *that*

  432. lovetox

    like a multi-text field above the buttons to send text

  433. MattJ

    Why reject the initial proposal?

  434. MattJ

    Yes, multi-text would indeed be crazy

  435. lovetox

    its perfect reasonable, why cant i type a comment before i press the button and send that with?

  436. MattJ

    Another argument against forms :)

  437. 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

  438. 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

  439. Zash

    `<button><{my-special-protocol}payload/></button>`

  440. Zash

    there you go

  441. MattJ

    I think the people who rejected it probably have no experience of other messengers or why this feature is useful

  442. MattJ

    Data forms would be pointless bloat

  443. Zash

    MattJ, even if you specified a restricted subset to be treated as a simple button?

  444. MattJ

    If I ever do need to implement this feature, I just intend to implement the protoXEP

  445. MattJ

    If you did do that... *why?**

  446. MattJ

    It's 100% pointless, and makes more work

  447. Zash

    Dunno, reuse of namespaces

  448. 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

  449. lovetox

    because i already have a dataforms impl

  450. MattJ

    The point of the buttons is that they map to plaintext user responses

  451. Syndace

    (or xml)

  452. MattJ

    lovetox, you already have a pubsub impl too, so... let's use that!

  453. Zash

    And an ad-hoc iml!

  454. Zash

    How about we ship a disco#items ad-hoc command list in a message?

  455. MattJ

    SamWhited, as an active user of a "variant" of XEP-0401, I'm interested in such discussions

  456. Zash

    If all commands are single-step and form-less then they're equivalent to buttons

  457. 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

  458. SamWhited

    If marc and I chat I'll CC you into any discussions

  459. Zash

    Ge0rG might also be interested (and now mentioned)

  460. SamWhited

    Was just chatting with him too :)

  461. Zash

    👍️

  462. 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

  463. lovetox

    i already see the horror, people write bots that send you buttons to lead you step by step through some process

  464. Zash

    lovetox, like memberbot? :)

  465. Zash

    Imagine getting buttons for quick answers instead of typing yes / no

  466. lovetox

    im not question that there is a good use case for the button xep

  467. lovetox

    voting is definitly one

  468. lovetox

    i just fear, because all clients implement it, for what people abuse it then

  469. Ge0rG

    It will be awesome!

  470. Syndace

    how do forms prevent abuse?

  471. Zash

    How do you prevent *any* abuse?

  472. Ge0rG

    SamWhited: you've seen https://yaxim.org/blog/2020/01/31/yaxim-0-dot-9-9-fosdem-edition/ and the video in it?

  473. lovetox

    Syndace, forms are made so you can make .. Forms of any size and kind

  474. lovetox

    so i dont see how you can abuse such a non specific use case

  475. SamWhited

    Ge0rG: TL;D(Watch)?

  476. Ge0rG

    SamWhited: live demo of cross client 0401 with ASCII art QR code

  477. Syndace

    wait can you not search the mail archives

  478. Zash

    inpossiburu

  479. Ge0rG

    Syndace: download the mbox file and search locally

  480. Ge0rG

    Maybe we should kindly ask gmane. Is that still a thing?

  481. Syndace

    found it by checking the dates surrounding the protoxep last update date

  482. Syndace

    but meh 😀

  483. Zash

    Hm

  484. Zash

    https://logs.xmpp.org/council/ is also a good resource

  485. Syndace

    love how the presence spam is logged

  486. Zash

    Hysterical raisins.

  487. Zash

    You should see the stuff logged by the original MUC logger implementation.

  488. 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.

  489. Zash

    Syndace, there's a checkbox somewhere that lets you hide joins and parts

  490. lovetox

    Also everyone can see in a MUC what you voted

  491. Syndace

    joins and parts? 😀 oh boy, my internet language is lacking behind

  492. Syndace

    like, thread joins/parts?

  493. Syndace

    like, mail thread joins/parts?

  494. Syndace

    oooh joins as in presence spam, sorry

  495. 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!!

  496. lovetox

    Maybe one can send the answer as PM

  497. Zash

    Syndace, https://logs.xmpp.org/council/2018-12-12?p=h#2018-12-12-f53055662532f142

  498. Syndace

    thanks, still busy with the mails tho

  499. 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!!"

  500. 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

  501. pep.

    Zash: I also take advice for representing buttons in my terminal

  502. pep.

    Syndace: ^

  503. Syndace

    don't

  504. Syndace

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

  505. pep.

    :P

  506. Syndace

    not supposed to be funny 😀

  507. Zash

    tab completion

  508. Syndace

    that's what the spec is currently

  509. Zash

    there, done

  510. Syndace

    true

  511. pep.

    Zash: that's meh

  512. Syndace

    1: yes 2: no 3: maybe >

  513. pep.

    you'd need to indicate first that you're doing buttons somehow (which one of the 3 last buttons messages that were sent?)

  514. 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"

  515. pep.

    though i give you it's a common issue in terminal stuff. So tab won't fix it

  516. Zash

    [yes] [no] [abstain] [maybe] [nuke it from orbit]

  517. pep.

    Syndace: why?

  518. Syndace

    simplicity and telegram 😀

  519. Syndace

    you also don't have to worry then to which button-message an answer corresponds

  520. pep.

    ah so we're Inn the business of reproducing telegram now? :)

  521. Syndace

    yep!

  522. pep.

    I thought it was WhatsApp and Slack until today

  523. Zash

    Are we not in the business of absorbing everything from every communications protocol?

  524. pep.

    in*

  525. Syndace

    > do we wanrt to open the can of worms what the "last message" is again? 🙂 is "last message" an issue for XMPP?

  526. pep.

    is it the one I sent with this device or any device? maybe? even though that's been specified iirc?

  527. Syndace

    also for buttons only incoming messages are relevant

  528. pep.

    sure, m'y message above was just answering yours directly

  529. pep.

    sure, my message above was just answering yours directly

  530. Syndace

    ok, that was a quote from the discussion on buttons

  531. pep.

    ah ok

  532. 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.

  533. MattJ

    I'd dearly love to see this pushed through

  534. MattJ

    I'm starting to realise that a big problem is people not understanding the use case

  535. Zash

    As council member and author of that protoxep, I would be happy to see that move forward as well.

  536. lovetox

    So in a MUC i press the yes button and then i see my "yes" appear as reflection in the MUC

  537. lovetox

    does that work this way also in Telegram?

  538. SamWhited

    Maybe rename it "Quick Replies" and then the use case will be more obvious?

  539. Zash

    Sure. Probably wasn't smart to imply some specific UI for it.

  540. 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.

  541. 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"

  542. Zash

    FWIW I was also studiying the stuff in Slack which is somewhat more advanced than just quick replies.

  543. pep.

    SamWhited: yeah that's quite annoying

  544. Zash

    pep., arbitrary text string reactions?

  545. Zash

    suggested reactions?

  546. pep.

    Zash: suggested replies

  547. SamWhited

    pep. I really like the idea, it just never has any useful replies for me

  548. MattJ

    A rename sounds sensible

  549. pep.

    often I fear I'm gonna hit them instead of what I want to do

  550. Syndace

    the question how this works in muc is justified though

  551. MattJ

    What's the question?

  552. Zash

    Is the answer Hats?

  553. MattJ

    Usually

  554. pep.

    no

  555. MattJ

    Hats XEP is nearing the top of my XEP to do queue!

  556. pep.

    everyone can see your "votes" lovetox noted

  557. Zash

    (THREAD: Hats) Hats + Security labels + filtering. Get to it!

  558. SamWhited

    I feel like I've asked this before, but "Hats"?

  559. MattJ

    Yes, like they can see anything you type

  560. Syndace

    yeah probably no question here actually

  561. MattJ

    SamWhited: maybe known as "badges" in other systems?

  562. pep.

    MattJ: yes but "votes are private!!" something

  563. Zash

    SamWhited, https://xmpp.org/extensions/xep-0317.html

  564. SamWhited

    ahh, right

  565. SamWhited

    Thanks

  566. MattJ

    SamWhited: but we've had them way longer, just nobody really cared until now to implement and finish the XEP

  567. MattJ

    pep.: I really don't understand

  568. Syndace

    yeah no, private votes are not covered by this and that's it

  569. Zash

    So would you really do that kind of quick reply thing in MUCs then?

  570. MattJ

    Why not?

  571. Zash

    It Depends™

  572. Zash

    If you do voting, then closed voting would need to work differently.

  573. pep.

    is this really supposed to be quick replies? is the string actually sent as a message or what?

  574. MattJ

    Yes

  575. pep.

    uh

  576. Zash

    Unless you wanna replace the response with some XML blob

  577. MattJ

    See? Nobody understands

  578. 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 :)

  579. MattJ

    Zash, maybe it would be worth sticking some in-reply-to stanza-id just because?

  580. Syndace

    but clients that don't support buttons wouldn't set in-reply-to

  581. pep.

    MattJ: just that I don't see the use-case at all

  582. Zash

    (Hat: Council) Can someone please write a XEP about `<in-reply-to by="jid" id="stanza-id"/>` ?

  583. 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

  584. pep.

    votes made a bit more sense

  585. 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

  586. Zash

    Adhoc/forms might work better for that

  587. MattJ

    so a simple "this button was clicked" payload is enough to trigger the bot to do something

  588. MattJ

    Zash, too many taps

  589. MattJ

    You can't ad-hoc on a message

  590. 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.

  591. Zash

    MattJ: Offer of ad-hoc commands in a message?

  592. MattJ

    SamWhited, exactly

  593. Zash

    OR A MUD

  594. Ge0rG

    Just use Emoji reactions for voting

  595. Zash

    GO WEST

  596. MattJ

    Zash, and then it gets way more complicated, and what if the command is multi-step? Ugh.

  597. eta

    Zash, YES

  598. eta

    MUD in XMPP when

  599. MattJ

    eta, over a decade ago

  600. MattJ

    You had to be there

  601. Zash

    You were eaten by a grue.

  602. Zash

    (the heck is a grue?)

  603. MattJ

    I made a MUC^Hd component, it was great

  604. eta

    MattJ, is the source somewhere

  605. eta

    MattJ, I will run this

  606. MattJ

    It's around, but likely too embarrassing to point you to

  607. 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?

  608. eta

    MattJ, I have a low tolerance

  609. eta

    or a high one

  610. Zash

    Syndace, should probably be separate from the quick reply thing

  611. eta

    whichever it is :P

  612. MattJ

    I think it was hosted on some forge that no longer exists

  613. eta

    ah

  614. MattJ

    But I think I have it in backups

  615. Syndace

    Zash agreed

  616. MattJ

    Syndace, Zash: but it's the same UI...

  617. MattJ

    and essentially all the same business rules

  618. MattJ

    Just one sends a body, and one does not

  619. Zash

    MattJ: Not quite, not if you wanna clone it. Slack lets you do full on forms IIRc.

  620. MattJ

    I don't particularly want to clone it

  621. Syndace

    hmm, one needs client support that probably has to be discovered, the other is just plain text

  622. MattJ

    No, it doesn't have to be discovered if you're fine with it being optional

  623. MattJ

    and discovery in a MUC would be a nightmare

  624. MattJ

    So this is an optional shortcut thing

  625. MattJ

    (and that's exactly how it gets used in Slack)

  626. Syndace

    okay I'm not farmiliar with the slack buttons, can you give an example please?

  627. 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

  628. Zash

    `<action>[ <body/> | <{jabber:x:data}/> | the json xep </>`

  629. pep.

    I guess I can just not implement it in poezio then, that simplifies UX issues.

  630. Syndace

    ah, so quick link-click in addition to quick response? 😀

  631. pep.

    unless now you add a different meaning to it

  632. Syndace

    or wait, merging is quite specific and probably needs slack to "understand" git?

  633. MattJ

    Syndace, it's just handled by bots

  634. MattJ

    Slack doesn't understand any of this

  635. MattJ

    The bot posts a message in a Slack room, when a user clicks a button, the bot gets informed about that

  636. MattJ

    (there is some fancier stuff too, but my goal is not to fully clone Slack)

  637. Syndace

    you could define the quick response button to send /merge or !merge on click, if the bot understands that?

  638. MattJ

    This is a really simple feature that would make such a nice UX improvement

  639. MattJ

    Yes, you could

  640. MattJ

    I would just rather keep the body optional, so I can make the decision as a bot author

  641. Zash

    MattJ, specify reply payload as either text or Some XML Stuff™, bot decides, click sends that.

  642. Zash

    Cry in i18n for a while, done.

  643. 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

  644. MattJ

    But I should stop talking about buttons

  645. pep.

    and now that you've mentioned hats, I'm also curious what UI for that would look like in a terminal..

  646. Zash

    pep., mouse support exists :P

  647. pep.

    Zash: what about it (and no!)

  648. MattJ

    <quick-response id="id-of-response"/>

  649. Zash

    whatabouti18n?

  650. MattJ

    What about?

  651. 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?

  652. MattJ

    Isn't all this in the XEP already?

  653. Zash

    Yes

  654. MattJ

    The XEP is what I want

  655. MattJ

    The end

  656. MattJ

    I don't see what's so complicated

  657. 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.

  658. Ge0rG

    You could respond as a PM.

  659. 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"/>

  660. MattJ

    Why?

  661. MattJ

    Why complicate things?

  662. Ge0rG

    Also your MAM implementation will drop the responses with no body

  663. MattJ

    You're in a chat, it's a response to a message in that chat, why would you send it elsewhere?

  664. Ge0rG

    Because O(n²)

  665. MattJ

    ?

  666. Ge0rG

    When everyone responds to everyone

  667. MattJ

    What?

  668. Zash

    Same problem as with reactions?

  669. MattJ

    That's an argument against group chats of any kind?

  670. MattJ

    I'm responding to you right now, is that O(n²)?

  671. 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

  672. MattJ

    By "payload" you mean a text body, right?

  673. Syndace

    yeah

  674. Ge0rG

    Syndace: it's useful if you share the room with legacy clients

  675. 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)

  676. 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

  677. MattJ

    But there are more ephemeral actions that you wouldn't care so much about

  678. Syndace

    ah okay so just to have clients supporting the XEP not spam plaintext

  679. Syndace

    sounds good

  680. MattJ

    Yes

  681. pep.

    where is the written "+1" if your support the xep

  682. MattJ

    pep., ?

  683. pep.

    implemented and understood by the log writer?

  684. MattJ

    It's in <body>, it's understood by everyone (I hope)

  685. pep.

    not sure I understand the following then > ah okay so just to have clients supporting the XEP not spam plaintext

  686. MattJ

    That's for the case where there is no plaintext equivalent

  687. MattJ

    The +1/-1 example was a case where you do want it to go in the logs and include a <body>

  688. Syndace

    oh okay, then my initial question still stands: why would you want _both_ and id and plaintext?

  689. pep.

    so if there's a body a client must always include it?

  690. MattJ

    I don't see it's as entirely necessary, it just feels like a neater protocol/implementation

  691. MattJ

    pep., yes

  692. Syndace

    it's like you send "+1" and there is an XML element that says "this is a +1!"

  693. 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)

  694. MattJ

    But it seems sensible to have some machine-readable semantics underneath if it's known, rather than throwing that context away

  695. Syndace

    To me it would feel weird if the same visible message has different effects under the hood

  696. Syndace

    as in, a message that has both the plaintext and the id is treated differently then a message that only has the plaintext

  697. 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

  698. MattJ

    What exactly needs to change from what was previously submitted?

  699. MattJ

    If we can identity that, and who is going to write it up, we're good

  700. MattJ

    And don't have to revisit these discussions yet again in another year :)

  701. 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

  702. 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

  703. Syndace

    Maybe it's time for my first XEP, also as training for Master Key (tm)

  704. Syndace

    If Zash doesn't want it, I would do it

  705. Zash

    Feel free to take over or add yourself as co-author :)

  706. Syndace

    cool 🙂

  707. MattJ

    Excellent :)

  708. Zash

    <hat:council> I'll review it for you tho ;)

  709. Zash

    MattJ, hats!

  710. MattJ

    Coming soon

  711. MattJ

    After I finish MAM

  712. Maranda

    I'm not sure what I did change that made Movim merrily start doing 0215 queries

  713. pep.

    Maranda, https://github.com/movim/movim/commit/ce299e038c321c932441722885746efc3b3cedd2 ?

  714. pep.

    Maybe you haven't changed anything

  715. Maranda

    pep., huhu and edhelas put it live on NL right away :O?

  716. pep.

    Sure

  717. edhelas

    :3

  718. Maranda

    :D

  719. edhelas

    too fast 4 u

  720. Maranda

    still I'm not sure why the call fails from my laptop to the other one, but not viceversa

  721. Maranda

    (using two different account)

  722. Maranda

    would be interesting to know what it does trample on