XSF Discussion - 2020-10-07


  1. mimi89999 has left

  2. mimi89999 has joined

  3. emus has left

  4. Andrzej has left

  5. j.r has left

  6. j.r has joined

  7. Andrzej has joined

  8. eta has left

  9. Lance has left

  10. Lance has joined

  11. intosi has left

  12. intosi has joined

  13. lskdjf has left

  14. Andrzej has left

  15. intosi has left

  16. Lance has left

  17. alameyo has left

  18. alameyo has joined

  19. Lance has joined

  20. matkor has left

  21. Shell has left

  22. Andrzej has joined

  23. alameyo has left

  24. alameyo has joined

  25. peetah has left

  26. peetah has joined

  27. Andrzej has left

  28. neshtaxmpp has joined

  29. arc has left

  30. arc has joined

  31. krauq has left

  32. krauq has joined

  33. Andrzej has joined

  34. krauq has left

  35. krauq has joined

  36. Andrzej has left

  37. arc has left

  38. arc has joined

  39. krauq has left

  40. krauq has joined

  41. neshtaxmpp has left

  42. mukt2 has left

  43. Yagiza has joined

  44. Lance has left

  45. papatutuwawa has left

  46. arc has left

  47. arc has joined

  48. papatutuwawa has joined

  49. Lance has joined

  50. Lance has left

  51. Lance has joined

  52. DebXWoody has joined

  53. papatutuwawa has left

  54. papatutuwawa has joined

  55. Alex has joined

  56. mukt2 has joined

  57. Lance has left

  58. krauq has left

  59. krauq has joined

  60. Lance has joined

  61. mimi89999 has left

  62. mimi89999 has joined

  63. Andrzej has joined

  64. arc has left

  65. arc has joined

  66. krauq has left

  67. krauq has joined

  68. Shell has joined

  69. adityaborikar has left

  70. adityaborikar has joined

  71. lovetox has joined

  72. paul has joined

  73. Andrzej has left

  74. mukt2 has left

  75. lovetox has left

  76. sonny has left

  77. Mikaela has joined

  78. Andrzej has joined

  79. sonny has joined

  80. emus has joined

  81. sonny has left

  82. adityaborikar has left

  83. adityaborikar has joined

  84. sonny has joined

  85. arc has left

  86. arc has joined

  87. arc has left

  88. arc has joined

  89. arc has left

  90. arc has joined

  91. arc has left

  92. arc has joined

  93. karoshi has joined

  94. mukt2 has joined

  95. sonny has left

  96. mukt2 has left

  97. mukt2 has joined

  98. arc has left

  99. arc has joined

  100. sonny has joined

  101. sonny has left

  102. sonny has joined

  103. sonny has left

  104. sonny has joined

  105. Andrzej has left

  106. arc has left

  107. arc has joined

  108. arc has left

  109. arc has joined

  110. sonny has left

  111. arc has left

  112. arc has joined

  113. sonny has joined

  114. intosi has joined

  115. sonny has left

  116. mukt2 has left

  117. mukt2 has joined

  118. dwd

    They are issues. But they're issues that apply to any generic approach, and the argument is therefore that he doesn't want to solve this problem, which I agree with.

  119. dwd

    I mean, the argument essentially is that given any generic approach, it is possible to find a case where the generic solution does not apply. That is perfectly true. But the alternative is to have every case hard coded into the server, which I contend isn't viable as a solution.

  120. sonny has joined

  121. sonny has left

  122. dwd

    What I haven't said is that the arguments are badly written or written solely as an attack on me, or that the author has no idea about the problem domain.

  123. eevvoor has joined

  124. winfried has left

  125. winfried has joined

  126. sonny has joined

  127. jcbrand has joined

  128. Andrzej has joined

  129. LNJ has joined

  130. mukt2 has left

  131. winfried has left

  132. winfried has joined

  133. mukt2 has joined

  134. alex-a-soto has left

  135. alex-a-soto has joined

  136. winfried has left

  137. winfried has joined

  138. LNJ has left

  139. goffi has joined

  140. mukt2 has left

  141. alameyo has left

  142. alameyo has joined

  143. LNJ has joined

  144. mukt2 has joined

  145. sonny has left

  146. Lance has left

  147. Lance has joined

  148. sonny has joined

  149. sonny has left

  150. rion has joined

  151. debacle has joined

  152. sonny has joined

  153. wurstsalat

    Maybe a small voice conference meeting with you three could resolve most of these issues? At the moment it's a lot 'talk about talk'.

  154. sonny has left

  155. Lance has left

  156. Zash

    Bring back AFK Summit

  157. dwd

    Why? It's pointless. There's literally no interest in solving the problem outside of me and Kev.

  158. jonas’

    dwd, larma seems to be interested, too.

  159. dwd

    jonas’, No, he's explicitly not interested in any kind of generic solution.

  160. dwd

    jonas’, That's abundantly clear, and explicitly stated.

  161. jonas’

    right, however, they’re interested in a solution for reactions

  162. Lance has joined

  163. mukt2 has left

  164. larma

    dwd, my problem is not that the generic solution has some issues, but that the generic solution that was proposed doesn't work for the few use cases we already have in mind

  165. dwd

    larma, Sure.

  166. Kev

    Maybe it would be interesting to see what a specialised solution would look like, and try to extract the generic from there, if starting with the generic is generating too much heat.

  167. larma

    And had you read my gist you might have spotted that I wrote about one way I could imagine to solve this while staying generic

  168. Zash

    I'm not entirely convinced that a generic solution is the best place to start.

  169. dwd

    larma, Neither of your proposals works.

  170. dwd

    larma, But I'm just out of energy to solve the problem within the XSF now. There's other problems I can work on that might yield more useful results.

  171. matkor has joined

  172. larma

    funny, because one of the main reasons this topic had become an active discussion within the XSF (again) is that it was decided that we can't move forward with some other, mostly unrelated parts of the protocol before solving this issue

  173. vanitasvitae has left

  174. dwd

    larma, As I say, I have exhausted my energy here.

  175. pep.

    so should council finally accept reactions?

  176. dwd

    I honestly don't know. Fundamentally, the problems the last Council highlighted with the general pattern still exist and remain unaddressed, and nobody wants to solve them in the XSF.

  177. jonas’

    then move ahead with it as experimental and treat it as experimental

  178. jonas’

    in the sense that it’ll be broken when it needs to be broken

  179. dwd

    jonas’, You argued in the Council meeting when MAM-FC came up a couple of weeks back that I should not implement MAM-FC as it would form a de-facto standard while Experimental. I take it Reactions would not fall into that same argument, then?

  180. mukt2 has joined

  181. Kev

    Ah, and I left the room at that point.

  182. rion has left

  183. Kev

    Maybe if larma is saying that he *does* want to work on a generic solution (i.e. one that doesn't require per-protocol support or rules on the server) a sensible step would be to see what that looks like.

  184. Kev

    e.g. what an update to 427 looked like that resolved his issues with it, without introducing per-protocol rules.

  185. Zash

    As a server dev, I don't like keeping track of per-protocol rules, but it seems we can't avoid it.

  186. pep.

    Zash: as any dev :p

  187. Zash

    Heh

  188. dwd

    pep., No, there's two issues that are key for servers here. One is that the server would have to do "deep stanza inspection", for want of a better phrase, and actually understand the semantics of various cases such as reactions, receipts, and so on.

  189. dwd

    pep., That has an effect both on maintenance, which as you have alluded affects any developer, and also scalability.

  190. larma

    Kev, I proposed two ways in the gist. One is fully generic but restricted in what it can summarize (but less than the current approach), the other one is generic but with _optional_ per-protocol summary rules (and if there is no such rule for a protocol or the server doesn't support it, it still works just not as good as it could with specialized rules)

  191. Zash

    Prosodys MAM, Carbons and CSI modules contain loooong chains of rules now, so doing the same for MAM-FC etc does not seem unlikely

  192. sonny has joined

  193. winfried has left

  194. winfried has joined

  195. dwd

    pep., But there's also the problem that with each new collation pattern, the server developer may have to introduce a new data model within the MAM archive, and that concerns me much more - I have several million rows in my archive, and I need to access those efficiently. Migrating from one data model to another takes days, currently.

  196. larma

    Zash, the current MAM-FC proposal already contains special handling for some protocols anyway ("pseudo fastenings"), so I guess this is going to happen anyway, no matter how generic the approach 😉

  197. pep.

    what larma says

  198. dwd

    pep., What larma says is that the first problem I mentioned may be with us to stay, but says nothing about the second.

  199. dwd

    But as I say, no further energy for this.

  200. pep.

    Well unless you find the perfectly generic solution right away there's no escaping from this

  201. dwd

    von Clausevitz.

  202. vanitasvitae has joined

  203. pep.

    Seems like some lesser form of solutionism to me

  204. dwd

    Besides, my escape is to not bother trying to standardize a solution.

  205. dwd

    And before anyone criticises me for that - nor is anyone else.

  206. Lance has left

  207. pep.

    Sure

  208. pep.

    Let us at least use reactions

  209. larma was attempted to open movim just to put a 👍️ reaction on that message, but then realized probably nobody except edhelas will notice

  210. pep.

    tbh I'm not even personally going to use them

  211. dwd

    You say that like I am personally preventing you.

  212. pep.

    Just that I don't understand why that's not experimental yet

  213. pep.

    Just as 393 is experimental

  214. neshtaxmpp has joined

  215. mukt2 has left

  216. jonas’

    larma, I told you, fallback body!!k

  217. arc has left

  218. pep.

    Maybe I'm just being dull in trying to cling onto the few hopes I have to do something with the XSF, dunno. Maybe it's better for everybody to just do stuff on their own after all

  219. arc has joined

  220. sonny has left

  221. pep.

    Which is exactly what I understand from "You say that like I am personally preventing you."

  222. sonny has joined

  223. Zash

    What about rough consensus and running code?

  224. pep.

    Running code is there

  225. Lance has joined

  226. mukt2 has joined

  227. matkor has left

  228. Ge0rG

    > It is expected that clients will not send message corrections to clients that do not support them, as non-supporting clients will render these as duplicate (corrected) messages. How could that slip into 0307, given Carbons and MAM?

  229. Ge0rG

    > It is expected that clients will not send message corrections to clients that do not support them, as non-supporting clients will render these as duplicate (corrected) messages. How could that slip into 0308, given Carbons and MAM?

  230. Ge0rG

    And should a bridge to a protocol that implements message corrections have a <feature var='urn:xmpp:message-correct:0'/>?

  231. dwd

    pep., I didn't veto Reactions the first time. I did the second, because I didn't think a re-submission was the right thing to do or to encourage at that time - and all of Council agreed (Daniel didn't veto but stated he agreed, everyone else vetoed). Instead, I've actively worked on a solution meeting the criteria of the first rejection, acting in good faith to find a consensus position.

  232. dwd

    pep., From the minutes, this still stands: "The whole situation irritates Dave enormously - who originally voted in favour of Reactions. Dave is willing to give a holding vote, and dig into this further - would really love to have Reactions, and a generic method of 'fastening' would be even better."

  233. sonny has left

  234. pep.

    Well I don't agree with that and I don't see why I wouldn't revert a dumb decision in the first place. We already live with enough dumb decisions that if I have the power to change one I would

  235. intosi has left

  236. floretta has left

  237. Seve has left

  238. Vaulor has left

  239. floretta has joined

  240. Seve has joined

  241. Vaulor has joined

  242. sonny has joined

  243. Kev

    > One is fully generic but restricted in what it can summarize Ah, your 'option 1'. I was thinking you intended to send that with the fastening, but reading it again did you instead intend the collation types to be requested by the client at mam-fc time?

  244. pep.

    dwd, fwiw it's not against you personally, you just seem to be fairly defensive of the idea of respecting last term's decision for reasons I don't understand (as per my last statement)

  245. Half-Shot has left

  246. uhoreg has left

  247. Rixon 👁🗨 has left

  248. Half-Shot has joined

  249. Rixon 👁🗨 has joined

  250. uhoreg has joined

  251. dwd

    pep., OK, you don't agree. Everyone on the current Council agreed, four of them vetoed on that basis, one did not. You're on the Board, I'm sure we'd all welcome some clarificaiton on how Council should feel bound or not to decisions of previous Councils. But you're also suggesting the original decision was "dumb", which is simply unnecessary.

  252. Kev

    > How could that slip into 0308, given Carbons and MAM? I think at the time of 308 Carbons wasn't much of a thing, and MAM was entirely not a thing. But, indeed, if we (I) were doing 308 now it would possibly take an entirely different form.

  253. Kev

    > And should a bridge to a protocol that implements message corrections have a <feature var='urn:xmpp:message-correct:0'/> Presumably so, unless I'm being dense (and I'm again not firing on all cylinders, so quite possible).

  254. Ge0rG

    Kev: I'd say it should be announced on user JIDs, but I'm not so sure about bridged rooms.

  255. Ge0rG

    IMHO, a client shouldn't require a MUC to have the 0308 feature to send LMC

  256. Ge0rG

    Kev: if you are okay with it, I'd make a PR for that.

  257. Ge0rG

    also that a client shouldn't require the feature on a recipient

  258. Kev

    > dumb decision Do people understand how using Trump-ish language about other people and their behaviours reduces the chance of a reasonable exchange happening?

  259. dwd

    Kev, You are attributing a goal here that there is no evidence to support.

  260. eevvoor has left

  261. pep.

    dwd, so that I can see even more people in board thinking the same way you feel? (because now they'd have to voice an opinion) I'd rather not. And also why I'm not reapplying for board anyway. It just won't bend my way, it's mostly a waste of time for me

  262. Kev

    Ge0rG: I *think* it's not the MUC, but rather the occupants, that advertise support for 308 to trigger someone being able to send corrections there.

  263. j.r has left

  264. dwd

    Kev, I suspect those two mean different things - a MUC advertising support might mean the MUC has some semantic understanding, but we don't specify what that might be.

  265. Kev

    Ge0rG: Ah, yes, so the MUC sentence (which might be badly written) suggests it's the occupants that have to support it (recipients was a poor choice of word for me here, I think). It also says that you can send to a MUC if you want to even when not supported.

  266. Ge0rG

    Kev: what would be the logic here? Send LMC if *at least one* occupant has the feature? Only if *all occupants* do? What if somebody joins or leaves while you are typing the correction?

  267. Kev

    dwd: I would agree with that.

  268. Kev

    Ge0rG: What Swift does is just to pop up a small notice saying that not everyone supports it, so their experiences may vary.

  269. Kev

    Which you might argue is horrible UX, but it was the best I could come up with at the time.

  270. Ge0rG

    Kev: that's not too bad of an UX

  271. Ge0rG

    Kev: but a client telling the user that LMC isn't supported when trying to correct a MUC message is

  272. Kev

    I don't think Swift ever actually prevents you from sending a correction, it just warns you that the target will not/might not understand it as a correction.

  273. j.r has joined

  274. dwd

    pep., Well, that's a shame, on both counts. Even if Board broadly disagrees with you, it's useful to have a contrary voice in any debate, and useful to clarify the situation with Councils binding, or not, future Councils.

  275. adityaborikar has left

  276. adityaborikar has joined

  277. pep.

    I did not apply for board just to play the role of the contrary voice

  278. Kev

    dwd: If I was to send a mail to standards@ with my old Council hat on saying that I would like Council to reconsider Reactions on its own merit with reference to my reasons to -1, but not my -1 itself, would that be in any way useful?

  279. Ge0rG

    Kev: but preventing the user from sending a correction is encouraged by the current 0308 wording.

  280. pep.

    So much process, seriously

  281. Kev

    Ge0rG: If you feel you can make my wording better here (for example by pouring alphabet spaghetti on it and seeing where it lands :) ), I'm entirely open to a PR.

  282. lskdjf has joined

  283. Ge0rG

    Kev: roger

  284. Kev

    308's Draft, but I suspect Council would be amenable to a change that makes things better - there is enough weasel wording in there already to allow this, I think.

  285. Ge0rG

    I think so too.

  286. j.r has left

  287. j.r has joined

  288. dwd

    pep., Board defines process. And process should serve us, not rule us. I mean "us" as in the community - it absolutely has to rule Council, that's kind of the point. I've always found Board limited by time and funding, and not by process. As to being a contrary voice, I think you underestimate the utility and importance of it - and if you didn't join to be a contrary voice, you must have expected either everyone else to agree with you or you to agree with everyone else, neither of which sounds like progress.

  289. Kev

    larma: What would your ideal mechanism for collation of reactions in MAM look like (I assert that collation is required, because not all clients will be always-on full-archive-sync jobs). I want to see a Reactions spec accepted, which is why I put the effort in with Dave on fastening/mamfc.

  290. larma

    > Ah, your 'option 1'. I was thinking you intended to send that with the fastening Kev, that's the way I meant it to be, e.g. `<apply-to xmlns="urn:xmpp:fasten:0" id="origin-id-2" rules="only-self">`. Would also be possible the other way round as you suggested: when requesting MAM-FC I include a list of my supported fastenings and their respective collation rules. Or those go into disco somehow, so I don't have to include them with every MAM request.

  291. Spectator has joined

  292. sonny has left

  293. Lance has left

  294. larma

    I personally prefer the option 2 which IMO will in the end lead to the better results in total, even if that means (optional) additional server-side implementation work for new XEPs.

  295. Zash

    larma: Or do supported collation rules get advertised by the server?

  296. Kev

    So, a mam request would look (heavily pseudocoded) like: <mam> <collations> <edits type=newest filter=authoronly/> <reactions type=count/>

  297. larma

    Zash, well, then there is no need to advertise them and they can just be applied 😉

  298. larma

    Kev, yeah, but then I expect the query is going to be huge at some point

  299. dwd

    larma, In the first case - 1a - a malicious client could probably hide messages from some other clients. In the second, I don't see how an archive data model could be built to support that efficiently - you're asking for GROUP BY semantics in MAM requests.

  300. floretta has left

  301. Kev

    If we got to the point that collation queries were huge, we could probably start saving profiles on the server or something and referencing those. I wonder if we'd ever reach that stage.

  302. Kev

    dwd: Yes, essentially enforcing an SQL pass-through is my concern (although I'm not yet convinced it's as bad as I fear, I need to think further). One thing we could do, though, is have servers only require the official collation for things they understand, and reject queries otherwise. So that you could have a fully-generic server that can do whatever you ask, or if you want to in a specialised environment a server that can only support, say, Reactions and nothing else. We can mandate collation types in the respective XEPs to allow this.

  303. sonny has joined

  304. Kev

    The reason that I think having a fully generic option is useful is it allows forwards-compatibility, and as a server vendor (for generic use) I'm not keen on needing to support every collatable-payload explicitly as they're specced (and respecced, etc.).

  305. Kev

    (Which I know you (dwd) realise, but which I say for completeness)

  306. mukt2 has left

  307. larma

    I am wondering why the option 2 (optional per xep collation) is so off-the-table for you, because to me it seems like the most promising solution

  308. dwd

    Kev, The problem with new collation requirements isn't so much the change in code, but the need to migrate the data model for historical data, to restate.

  309. Kev

    dwd: Well, I think both are an issue for different types of deployment.

  310. j.r has left

  311. j.r has joined

  312. Kev

    larma: It's not *completely* off the table for me to support individually collatable things individually, but I consider it very undesirable(...)

  313. Andrzej

    I've already tried to implement mamfc, and the biggest issue (at least with having no data in storage) is grouping of data in SQL queries as it is very hard to make them efficient and support many grouping conditions

  314. Andrzej

    adding more "collations" will only complicate things even more

  315. Kev

    larma: There's a bunch of reasons for this, and they may not apply if one is in an environment where either servers and clients are deployed in cooperative lockstep, or if servers and clients are both deployed so frequently that it doesn't matter (although the development cost of adding support to the server each time is still not to be ignored, I think - I consider changes to a server to be 'riskier' than to a client, especially when dealing with (important) persistent data) (...)

  316. Andrzej

    and in my case (maybe others as well) will force people to update data storage model

  317. dwd

    Andrzej, Yes, I certainly need to update the storage model. I believe I can manage the MAM-FC case efficiently, but I feel your pain on the effort needed on existing installations.

  318. Kev

    larma: But if one enters an environment where deployments may not be seeing much collaboration between servers and clients, or where e.g. a server has to be deployed once and only receive bugfixes for years, not having a generic solution begins to be a significant barrier to getting features in front of users.

  319. Kev

    Andrzej: Yes, dealing with the data models for all this is hard. I'm not looking forward to when we do that bit.

  320. eevvoor has joined

  321. eevvoor has left

  322. Lance has joined

  323. pep. has left

  324. dwd

    Kev, I do have clients and server developers in the same room - or at least, on the same video call - and even then changing isn't trivial. But a migration of (erm) 20 million message stanzas in an archive is not going to be practical, so I need to do that once only. Fastenings, with the generic summary system we designed, works OK as a join table. If we need to alter summary data per fastening, that would be hard. Adjusting collations given the same summary data s probably easier.

  325. floretta has joined

  326. Kev

    larma: Drawing some (possibly invalid, but I don't think so) parallels from pubsub, if we'd required server support explicitly for storing the different payload types I don't think we would have seen the sorts of unexpected adoptions it's seen (and there are numerous interesting deployments of pubsub, signalling for video conferencing systems, form submissions, etc., as well as the more obvious ones). I feel that a non-generic solution would be tying us into a dead-end. So looking at it from the point of view of trying to produce systems that allow as many people to do as many things as possible with XMPP, I come to the conclusion that a generic system is preferable (other people with the same goal might reach a different conclusion, I do not mean to imply that by reaching a different conclusion one must care less or whatever).

  327. Kev

    dwd: Are you saying that you think per-spec collation requiring server-support would be ok 9

  328. Kev

    (Editing...)

  329. Kev

    dwd: Are you saying that you think per-spec collation requiring server-support would be ok (for your deployment) as long as the per-spec collations were from a set known in advance (e.g. the mam-fc rules as-are)?

  330. Ge0rG

    Kev: https://ge0rg.gitlab.io/-/xeps/-/jobs/777236873/artifacts/rendered-changes/xep-0308.html#disco last paragraph of §2

  331. Kev

    Ge0rG: I think that ends up being an entirely non-normative-non-bumping change, and conveys the right message. Thank you.

  332. dwd

    Kev, Perhaps. :-) I think I'm saying that there are three parts to this: Collation, Summarizing, and Fastening, and they have different impacts. A server needs to know that a stanza is a fastening, and to what it applies. If this is "code knowledge", a change requires a data model migration. It needs to be able to extract the summary during the archival operation, I think, and changing that is a data model migration, so again that really needs to be generic. So far, these are things the Fastening/MAM-FC approach got comfortably right. Then we need to present the results in MAM in a useful collation - and this is where we have the most flexibility, since this is potentially just a code change.

  333. mukt2 has joined

  334. dwd

    But I'm thinking in the abstract - Andrzej, does the above make sense? You're closer to an implementation than I am.

  335. Spectator has left

  336. larma

    Kev, My thinking here is: There is going to be a few XEPs that are very popular and where collation makes sense and is relevant. And we'd want to support collation rules to "best" fit those usecases (because if a certain fastening is only used once in every 10k messages, collation isn't relevant at all). We can certainly guess that edits, markers, reactions are likely to be on that list, but obviously this would never be an exhaustive list and we might as well be wrong about those. I think that no matter which collation rules we come up with today, they will be unsuitable in 5-10 years. They may even hinder further development because it may cause us to make future XEPs fit the collation rules (as was suggested for reactions already) up to the level that desirable features are not possible anymore. Thinking the other direction: When a new XEP is proposed it usually takes several years for large amounts of clients picking them up and then some more time for users to make use of them. And only once a larger number of clients want to use those XEPs, it's relevant if servers support good collation for them or not, so this gives them quite a bunch of time for implementing them. And it's in the natural interest of server operators to update to a server that supports collation for a new XEP that is heavily used on that server, because collation typically means less resource usage on the server.

  337. Ge0rG

    Kev: thank *you*!

  338. Ge0rG

    jonas’: can we get https://gitlab.com/xsf/xeps/-/merge_requests/22 on today's agenda? :D

  339. Andrzej

    dwd, yes it makes sense

  340. jonas’

    Ge0rG, you can agenda-bash on-list :)

  341. jonas’

    .oO("As discussed with Kev on [email protected] MUC today")

  342. Andrzej

    actually I've stopped with implementation of mamfc as I had other things to work on and mamfc was not really a solution in my case

  343. Lance has left

  344. Ge0rG

    jonas’: roger wilco

  345. sonny has left

  346. Kev

    larma: What do you think the way forward should be? ISTM that even if we disagree on the nature of mam-fc specialism, we should be able to agree on a generic fastening format. (I draw some slightly different conclusions from my experiences than you from yours about the ability of server operators to upgrade etc., but I suspect that's partially orthogonal)

  347. arc has left

  348. arc has joined

  349. arc has left

  350. larma

    I'd like the fastening format to be such that the fastened elements do not need to reside in the <apply-to />, i.e. I don't want to require clients to implement a specific version of fastening just to support something that servers may (if they support it) fasten to other messages and make available in MAM-FC.

  351. arc has joined

  352. larma

    And I don't want fastening to define any semantics for messages that are attached to other messages, because this means restricting what can be done

  353. Lance has joined

  354. Kev

    > I'd like the fastening format to be such that the fastened elements do not need to reside in the <apply-to />, i.e. I don't want to require clients to implement a specific version of fastening just to support something that servers may (if they support it) fasten to other messages and make available in MAM-FC. I understand the first part, I don't understand the i.e.

  355. larma

    I meant, a version bump of fastening should not screw everything up (or require to duplicate the full message payload)

  356. Kev

    But it sounds to me like you're saying your ideal fastening spec would be to not have a fastening spec, which I can't see why it would be desirable. Even for client devs I think having a generic fastening makes life easier (altohugh not as much as for servers).

  357. dwd

    larma, I don't think the fastening syntax is as much of a problem as you seem to think - it's not been a problem for, for example, <forwarded/>, or even Carbons. And moving stuff out of Fastenings makes any form of generic support very very much harder, I think.

  358. Kev

    Ok. I agree that a version bump to fastening breaking things would be undesirable. Although I'm not sure I draw the same conclusions from that as you (that we shouldn't have a fastening format at all).

  359. krauq has left

  360. sonny has joined

  361. larma

    dwd, I understand you'd like servers to not store the full message of a fastening but only the part that is inside the <apply-to/>? Otherwise the https://xmpp.org/extensions/xep-0422.html#external-payloads would kind of solve the problem for me, if we agreed on that we don't need (using example there) the <edit> element inside the apply-to.

  362. larma

    generic support though is also still very hard if we don't have strict rules for every fastening, no matter if they are inside the <apply-to/> or not

  363. krauq has joined

  364. larma

    e.g. you IIRC wanted to have each <reaction /> directly inside <apply-to /> instead of the container <reactions /> element the current proposal has, this to me is a very weird restriction applied from the MAM-FC logic to totally unrelated XEPs.

  365. larma

    Beside that, just storing what is in <apply-to> is definitely not enough. We already know that for some usecases (edits) it's important to know who applied that message because only the sender may edit. So add at least the from field there. In MUCs however, it's maybe not the message's from field that's relevant, but might as well be the XEP-0421 occupant-id

  366. dwd

    larma, Not quite; I think servers still need the full stanza, but need to identify the fact it is a fastening, and the type and summary, in a generic manner. That's vastly simpler if the type and summary are derived directly from a child element. If they are inferred from other elements, that becomes a path to an attack based on differential capability I suspect.

  367. dwd

    larma, Also yes, I'd be perfectly happy if the "full fastening" was the entire stanza, in principle. It might be a bit nasty in terms of stanza size, but it's probably practical.

  368. matkor has joined

  369. mukt2 has left

  370. dwd

    larma, If we went that route, we could do away with the <external/> entirely. The "shell" attribute could be done as a dummy fastening (which could be a distinct namespace, if we wanted, and include a correlator attribute, etc if desired). That would mean the <apply-to/> element was really very simple, and the namespace it sits within it somewhat better insulated from other changes, so should remain more stable.

  371. dwd

    "clear" could be moved off the element, too, into a different element with again a different, and therefore independent, namespace.

  372. dwd

    That leaves <apply-to/> itself with a single semantic, which seems more manageable. Would that allay your concerns here?

  373. Lance has left

  374. larma

    I've trouble to understand how your collation of MAM-FC is supposed to work then, because of the way you generate summaries

  375. larma

    (I'd be totally happy though)

  376. larma

    Also, as a work-around, we can have external support paths

  377. larma

    <message> <apply-to xmlns="urn:xmpp:fasten:0" id="foo"> <external path="/{urn:xmpp:reactions:0}:reactions/{urn:xmpp:reactions:0}:reaction" /> </apply-to> <attach xmlns="urn:xmpp:glue:0 id="foo" /> <reactions xmlns="urn:xmpp:reactions:0"> <reaction>👋</reaction> </reactions> </message>

  378. sonny has left

  379. larma

    <message> <apply-to xmlns="urn:xmpp:fasten:0" id="foo"> <external path="/{urn:xmpp:reactions:0}:reactions/{urn:xmpp:reactions:0}:reaction" /> </apply-to> <attach xmlns="urn:xmpp:glue:0 id="foo" /> <reactions xmlns="urn:xmpp:reactions:0"> <reaction emoji="👋" /> </reactions> </message>

  380. dwd

    Right, that's not ideal for me. If we use the full stanza as the "full fastening", then external just becomes redundant I think, and adds complexity for no gain.

  381. larma

    Just saying that how you currently do summaries wouldn't work then anymore, but I'm fine with that

  382. dwd

    I'm not sure I follow.

  383. larma

    well your fastening summary in mam-fc is supposed to be the element and attributes inside the apply-to. If there is nothing inside apply-to, which elements/attributes do you want to use

  384. Lance has joined

  385. Kev

    I'm afraid we've passed the point my addled brain can follow this for the moment.

  386. dwd

    Ah, right. Yeah, I want to keep the thing inside apply-to, and generate the summary the same generic way.

  387. larma

    Then I did not understand what you wanted to propose

  388. dwd

    So: <message> <apply-to id="foo"> <reaction emoji="hand-wavey-thing-i-don't-know-how-to-type"> <some-detail/> </reaction> </apply-to> </message>

  389. dwd

    But then that can become the sole semantic of apply-to, so "clear", "shell", and the <external/> element can all go.

  390. dwd

    (Or rather, move elsewhere).

  391. sonny has joined

  392. Kev

    👋🏻 - you're welcome

  393. larma

    dwd, But then again, a namespace bump to apply-to would invalidate all implementations of reactions

  394. dwd

    The idea being that then, the "urn:xmpp:fasten:0" is made much more stable. (Except obvious we'd need to bump it immediately).

  395. Kev

    larma: That is true (that a bump would invalidate things), but the same is true of other wrapping specs (e.g. pubsub), and we've managed to avoid it there.

  396. dwd

    larma, Yes, I'm trying to mitigate the need to bump that namespace. Eliminating it brings other problems.

  397. larma

    In other XEPs we have the client XEP mandate the parent XEP version (in this case it would mean that reactions XEP mandates a specific fastening version to be used)

  398. larma

    And then again, we do all this because of the model of MAM-FC you are enivisioning, not for any other reason, right?

  399. dwd

    larma, That means: 1) We have a generic way of identifying a message as a fastening, and knowing what it points to. High cost of change. 2) We have a generic way of extracting a summary. High cost of change, but also an impact on design choices for fastenings. 3) Collation strategies are left open. Medium cost of change.

  400. dwd

    larma, No, not really.

  401. xecks has joined

  402. Kev

    Actually, I think there's an auxiliary benefit of letting a client know what the nature of thing it doesn't understand is. Although this might not be a huge motivating factor, I think there is some value - we've had that discussion about fallbacks and about how indicating that a client didn't understand a payload, but having it know that it didn't understand it so it can let the user know would have merit.

  403. adityaborikar has left

  404. adityaborikar has joined

  405. dwd

    larma, So, you'd be able to get each fastening type to both identify and summarize generically, but you could have different types which collate in MAM in broadly different ways.

  406. larma

    I don't agree with 2, because the summary is no longer generic. You are enforcing a certain model for summaries that might not be suitable for all kind of attachings

  407. dwd

    larma, Yes, we are. We also enforce lots of syntactic things. But I don't think this case is onerous - can you see any obvious counter-examples?

  408. larma

    There were discussions to support custom emojis (images) for reactions. The syntax could be something like <reaction><media-sharing /></reaction> The image would thus not be part of the summary but it's required to have it so you can display it, making the summary mostly useless.

  409. dwd

    larma, Excellent. So you'd include a hash of the image in the <reaction/> top level element, wouldn't that solve the issue?

  410. pasis has joined

  411. sonny has left

  412. jonas’

    note: nothing forces us to bump the namespace of the <apply-to/> element unless the semantics of <apply-to/> change

  413. dwd

    larma, Or an cid URI, or whatever. It's all good. I'm not saying this won't impose design constraints, I'm saying they're not difficult to satisfy.

  414. larma

    You're implying that the media has a unique hash, but it could be multiple if multiple file formats are supported (png vs svg for example)

  415. jonas’

    meaning: if there are other elements in fastening which require a bump, we can just bump those

  416. jonas’

    without bumping <apply-to/>

  417. Kev

    jonas’: Yes, I believe that's what Dave is suggesting, but I might have mis-followed.

  418. dwd

    jonas’, Exactly, and my (loose and hastily typed) proposal is that.

  419. jonas’

    we haven’t done such things in the past, but there’s formally and technically nothing stopping us from doing so, as long as stuff is working

  420. Kev

    I think we *have* done that in the past, FWIW.

  421. jonas’

    dwd, I am only loosely follownig and catching up, so I thought I’d throw that in from the side to clarify, without actually reading what you wrote, sorry :)

  422. dwd

    jonas’, I'm actually suggesting we put the other bits into a different namespace from the outset to avoid complications later.

  423. pasdesushi has joined

  424. jonas’

    dwd, even better then

  425. larma

    jonas’, yes, but the issue I see is that fastening seems to be rich in semantics even when those are not described in the XEP itself (but implied from MAM-FC)

  426. jonas’

    larma, sounds as if Fastening and MAM-FC needs to be merged then

  427. jonas’

    but I’ll step out now again

  428. larma

    yes, totally that IMO, they work hand-in-hand

  429. dwd

    larma, We definitely need to collate the semantics in one place, yes.

  430. Kev

    I felt at the time that the motivation to keep them distinct was reasonable and strong. I may have been wrong, and I can't immediately remember why we felt that.

  431. dwd

    larma, I think there's two documents there, but I don't think the split is right.

  432. larma

    The problem is that I don't agree with the implied semantics that are not even properly mentioned anywhere

  433. Kev

    It does still feel to me that how you design something like Reactions based on Fastening is distinct from how you store and query the archive in MAM-FC, but which document text resides in is probably not the biggest issue we face.

  434. larma

    Like <apply-to> <reaction emoji="👋" /> <reaction emoji="👋" /> </apply-to> Being valid and meaning that you reacted with 👋 twice which IMO shouldn't be possible at all.

  435. jonas’

    IMO, if the intent of fastening is to have a unified way to attach things to one another to be able to query stuff from archives efficiently, then the "query things from archive" part is pretty core to that and it belongs in the same document

  436. andrey.g has joined

  437. Kev

    It is not a hill I will wish to die on if I end up in a minority of 1, certainly.

  438. Kev

    All the other issues I feel are much more material than where text resides within the documents.

  439. dwd

    Likewise with cardindality 2. Or even more.

  440. pasdesushi has left

  441. Lance has left

  442. Lance has joined

  443. dwd

    larma, Isn't that a problem with collation rather than the syntax?

  444. dwd

    larma, Or indeed the summarizing. I mean, the same issue exists in the Reactions ProtoXEP, doesn't it?

  445. larma

    The proto XEP has rules for this case

  446. dwd

    larma, Assume, for the moment, that we can collate per-XEP if needs be, so we can eliminate duplicates in the same way.

  447. dwd

    larma, I would *rather* use generic rules for collation, and as few as possible, but as I say that's vastly more practical to compromise on than the identification and summarizing itself.

  448. mukt2 has joined

  449. dwd

    Mild disgression: Back when Surevine where doing Buddycloud stuff (remember *that*?), Lloyd let a bug in which allowed people to like things multiple times if they clicked quick enough or something. "Multilike". It was a hugely popular feature^Wbug.

  450. Zash

    Super-likes!

  451. dwd

    Zash, No, just multilikes. Don't get carried away, now.

  452. Ge0rG

    M-M-M-M-M-MONSTER-LIKE!

  453. Zash

    Ge0rG: I was typing that!

  454. dwd

    I almost instinctively started to type "/giphy" then. Now there's a thing to get specced.

  455. Zash

    Specced?

  456. Ge0rG

    Where are our sticker packs? All we got are 5x sized Unicode codepoints.

  457. dwd

    Zash, "Specified", sorry.

  458. Zash

    dwd: Srsly tho, wouldn't that be all clientside?

  459. Lance has left

  460. dwd

    Zash, ... maybe?

  461. dwd

    Zash, I mean, on Slack etc, it's "workspace" extensions, which corresponds very loosely with a MUC domain in my mind. So maybe that would be an interesting model to explore?

  462. Zash

    Ge0rG: https://xmpp.org/extensions/xep-0038.html ?

  463. Zash

    dwd: "/giphy"?

  464. dwd

    Zash, Yeah. It's a critical business messaging tool.

  465. larma

    dwd: I'd be fine if we'd properly codify the semantics of apply-to. I remember back then that we didn't use message attach-to because its semantic didn't match. Currently MAM-FC applies certain semantics that make reactions not work as intended and thus unsuitable.

  466. larma

    dwd: I'd be fine if we'd properly codify the semantics of apply-to. I remember back then that we didn't use attach-to because its semantic didn't match. Currently MAM-FC applies certain semantics that make reactions not work as intended and thus unsuitable.

  467. dwd

    larma, Can you be a little more specific?

  468. larma

    dwd: I'd be fine if we'd properly codify the semantics of apply-to. I remember back then that we didn't use attach-to because its semantic didn't match. Currently MAM-FC implies certain semantics that make reactions not work as intended and thus unsuitable.

  469. larma

    The multi reactions example, at least

  470. larma

    I think there was more but I don't remember right now

  471. sonny has joined

  472. larma

    (Just writing from phone right now)

  473. Seve

    > I almost instinctively started to type "/giphy" then. I cannot lie I love that feature

  474. dwd

    larma, OK, but as I've said a few times now, I'd like to assume that we can solve multi-reactions etc in collations and not in either identification and summary.

  475. Ge0rG

    How does /giphy work? Is that a Slack feature? A pop-up where you can choose a gif?

  476. krauq has left

  477. krauq has joined

  478. dwd

    Seve, "/giphy high five".

  479. Seve

    Haha yes

  480. Seve

    Ge0rG: Yes to all

  481. Zash

    Local (MUC? Host?) registry of Stuff that can be referenced by OOB/BOB ?

  482. Zash

    And searched

  483. dwd

    Ge0rG, Essentially, yes. Technically it's easy, the trick is that it's a service offered by Giphy (a purveyor of anumated GIFs), that you can apply to your workspace such that everyone gets the ability to send critical business information in a timely manner via animated GIFs.

  484. Ge0rG

    dwd: thanks, I'm aware of giphy, I'm interested in the integration

  485. Seve

    Couldn't have explained better dwd

  486. Ge0rG

    yaxim won't accept animated gifs from the android keyboard because I'm missing some weird flag

  487. Zash

    the android *keyboard*?

  488. sonny has left

  489. jonas’

    just OOB-link to the giphy URL?

  490. dwd

    Ge0rG, In Slack terms, there is an "App" called "giphy", activated by "/giphy", which then guides the user to pick a GIF and then sends it as a message. That App is installed by anyone with the rights to do so, and Apps belong to the workspace not the individual or client.

  491. jonas’

    https://giphy.com/gifs/mHEes6Quf8XK0/html5

  492. dwd

    jonas’, The interesting bit is not the "send a GIF", but the "Provide the facility for everyone".

  493. Ge0rG

    Zash: gboard has a giphy browser built in

  494. Ge0rG

    ...where you can use the keyboard inside the keyboard to search for gifs

  495. Zash

    dwd: That relies on the client beeing integrated in the server/-ice, no?

  496. sonny has joined

  497. dwd

    Zash, I don't think so, in principle. The Slack client has no clue about Giphy, though it does understand generic apps.

  498. Ge0rG

    dwd: so essentially the "spec" would be: 1. choose a gif 2. (optional) make a copy on your http-upload instance 3. share an OOB 0066 link

  499. Ge0rG

    where OOB 0066 for embedding images is also undocumented and stalled in Council.

  500. dwd

    Ge0rG, No. I think the spec would be for an inline chat app you could "install" on a MUC service that your client would know how to speek to.

  501. Zash

    Ge0rG: Is it?

  502. dwd

    Ge0rG, As I say, it's more interesting than just sending the actual GIF.

  503. Ge0rG

    dwd: something something data forms adhoc?

  504. Zash

    dwd: ad-hoc command?

  505. Zash

    Ge0rG: ^

  506. larma

    dwd: I'm not saying we can't fix the semantics of fastening/mam-fc, I'm just saying that the current semantics of fastening are mostly implied from summary and collation rules in mam-fc and those semantics make it unsuitable for reactions. Which implies given the current set of XEPs, reactions can't use fastening

  507. Zash

    Ge0rG: ^5

  508. Lance has joined

  509. winfried has left

  510. winfried has joined

  511. dwd

    larma, OK. I am honestly trying, in good faith, to address your concerns and find a compromise/consensus position here.

  512. dwd

    Zash, "/giphy high five". You know you want to.

  513. dwd

    Zash, Ge0rG : And yes, something ad-hoc-ish mgiht work very well as a base. Might need a few more bits on top to make it polished.

  514. larma

    The alternative would be that we just do reactions as is without fastening and then update reactions and a later time and/or in mam-fc make pseudo fastening rule for reactions once we figured how that could work.

  515. Ge0rG

    dwd: I suppose today you'd rather just open a web view that has some event channel to emit JSON to your client.

  516. larma

    The alternative would be that we just do reactions as is without fastening and then update reactions at a later time and/or in mam-fc make pseudo fastening rule for reactions once we figured how that could work.

  517. dwd

    larma, I would rather we worked to solve the problem rather than ignore it, and pseudo-fastening rules really do suck, speaking from the experience of implementing those already.

  518. dwd

    larma, That is, I would rather that we were *both* working on a consensus position.

  519. dwd

    Ge0rG, That doesn't appear to be how Slack et al operate, though the notion of web-based applets in a messaging context is interesting.

  520. Ge0rG

    Java-based Mobile Code was a huge academic hype... before the base tech got Ellisone.

  521. Ge0rG

    *d

  522. Zash

    dwd: Oh how in Riot^W Element you can just tell it to embed an arbitrary thing in an <iframe> ?

  523. Ge0rG

    can you have porn popups? Server ads from the webshit ad market?

  524. Zash

    dwd: https://xmpp.org/extensions/xep-0088.html

  525. dwd

    Ge0rG, We have porn popups now, weren't you here yesterday? :-)

  526. Ge0rG

    dwd: it wasn't a popup, it was inline

  527. Zash

    This is how you do video conferencing after all, Jitsi Meet in an <iframe>

  528. Ge0rG

    dwd: I'd like to bring it on-par with the mobile surfing experience on Chrome. Redirect the whole page to "You have won! You are the 1.000.000 millionth google user!" with vibration and rewriting of the whole browser history

  529. Ge0rG

    A bot storing *that* into each matrix room's history would be... fun

  530. dwd

    Ge0rG, So you want your porn to pop up, basically. OK. More information than I needed.

  531. Zash

    Your client doesn't do popups for embedded images?

  532. Lance has left

  533. mukt2 has left

  534. Lance has joined

  535. adityaborikar has left

  536. adityaborikar has joined

  537. mukt2 has joined

  538. Lance has left

  539. krauq has left

  540. krauq has joined

  541. Lance has joined

  542. Lance has left

  543. Ge0rG

    Here's another case of implicit resource binding: https://xmpp.org/extensions/xep-0333.html#when

  544. adityaborikar has left

  545. adityaborikar has joined

  546. Kev

    Hopefully the meaning of that mail is clear, underneath all the Kev - if Council wish to still block Reactions I think at this point it should be because they agree with Kev, rather than because they are tied to Kev's decision.

  547. Kev

    I thought we were making progress earlier, but maybe not.

  548. Ge0rG

    Kev: thanks, at least I did understand the message of your message.

  549. Kev

    👍🏻

  550. LNJ has left

  551. mukt2 has left

  552. LNJ has joined

  553. alex-a-soto has left

  554. alex-a-soto has joined

  555. mukt2 has joined

  556. eta has joined

  557. pasis has left

  558. pasis has joined

  559. pasis has left

  560. pasis has joined

  561. Ge0rG

    Kev: is there a DOAP or a list of XEPs supported by Swift? Somebody from the other side of a certain bridge is asking why avatars don't work there.

  562. Kev

    Can we assume that before starting to be helpful, I've already done the usual 'it's the source' and suchlike helpfulnesses? I'm short of energy for my usual snark.

  563. Kev

    I think we have some sort of list, which I'm looking for now.

  564. Kev

    https://www.isode.com/products/swift-open-standards.html is probably incomplete, but is something.

  565. Kev

    It's definitely incomplete, because it doesn't have 308 on there. Hmm.

  566. Zash

    https://code.zash.se/xmpp-features/file/tip/clients/swift.lua is also likely incomplete and outdated

  567. andrey.g has left

  568. Ge0rG

    I don't even know off the top of my head which XEP is responsible for the presence-based occupant avatars.

  569. jonas’

    it’s vcard-temp

  570. Kev

    153

  571. jonas’

    plus 153, yes

  572. Zash

    and the avatar-conversion xep

  573. neshtaxmpp has left

  574. Zash

    in which case it's the servers responsibility

  575. Ge0rG

    the swift-open-standards.html page claims support for 0153

  576. Kev

    Ge0rG: It is correct.

  577. Ge0rG

    will Swift only query for avatars from JIDs that had an vcard-temp❌update in their presence?

  578. Kev

    Without checking the source, I would expect that to be the case, yes.

  579. eta has left

  580. Zash

    Public shaming: Error> swift@rooms.swift.im/Zash: wait: Server-to-server connection failed: Remote server's certificate has expired

  581. mukt2 has left

  582. Zash

    Also advertising the fancy error messages Prosody generates. Just look at them <text>s

  583. eta has joined

  584. eevvoor has joined

  585. eevvoor has left

  586. eevvoor has joined

  587. eevvoor has left

  588. matkor has left

  589. eevvoor has joined

  590. Lance has joined

  591. mukt2 has joined

  592. Lance has left

  593. Lance has joined

  594. eevvoor has left

  595. eevvoor has joined

  596. pasis has left

  597. Lance has left

  598. eevvoor has left

  599. krauq has left

  600. krauq has joined

  601. Lance has joined

  602. pasis has joined

  603. karoshi has left

  604. mukt2 has left

  605. moparisthebest

    is there some official way to get something on board's agenda?

  606. MattJ

    Request it here or on the members list, or poke a board member directly

  607. Lance has left

  608. Lance has joined

  609. karoshi has joined

  610. moparisthebest

    thanks, I'll request here then... if you recall the whole XEP-0001 debacle last year, the resolution was someone who had an idea in their head what XEP-0001's actual goals was would clarify it via PR, and that's still not done, so can someone else be drafted to do it or?

  611. moparisthebest

    sorry for highlight debacle ...

  612. debacle has been summoned

  613. raghavgururajan has left

  614. MattJ

    https://trello.com/c/6hUTQ3WE/407-xep-0001-clarifications

  615. raghavgururajan has joined

  616. antranigv has joined

  617. moparisthebest

    MattJ, thanks! I even was able to find context if you want to also put it there https://logs.xmpp.org/xsf/2020-01-17#2020-01-17-d38f615a033a9159

  618. MattJ

    Very helpful, thanks

  619. MattJ

    Added

  620. Wojtek has joined

  621. sonny has left

  622. sonny has joined

  623. mukt2 has joined

  624. Lance has left

  625. goffi has left

  626. sonny has left

  627. pasis has left

  628. pasis has joined

  629. Daniel

    I'd be willing to 'fix' OOB (66) to document how Conversations and some other client currently use it

  630. Daniel

    for file transfer

  631. Ge0rG

    Daniel, Zash: I really dislike that 0363 is implicitly combined with OOB and the unwritten requirement of body=oob-url

  632. Daniel

    and not for signaling random http links

  633. Daniel

    (which at least one other client is doing)

  634. Daniel

    if that fixes the situation enough for dwd

  635. dwd

    Daniel, Absolutely.

  636. Ge0rG

    Daniel: while you are at it, also add a XEP-0428 tag

  637. Daniel

    there was a thread a while ago I think were I outlined that use

  638. dwd

    And Kev, I wrote XEP-0428 in a hurry, if you've some suggestions there I'd absolutely welcome them.

  639. Ge0rG

    Somehow, I ended up explaining the "right" way to use OOB for inline images to multiple developers over the last years

  640. Daniel

    and maybe or maybe not remove the IQ protocol that literally nobody uses

  641. Daniel

    Conversations has read support

  642. Daniel

    but i don’t think it ever received one

  643. Ge0rG

    Daniel: from a semantically puristic point of view, I think that a discussion of those things would belong into 0363 and not into 0066

  644. Daniel

    i disagree

  645. jonas’

    Daniel, you should put an easteregg into C when it receives such an OOB, something with a firework gif

  646. Daniel

    because http upload is more versatile

  647. Ge0rG

    as both are in Draft, that doesn't even matter procedurally

  648. dwd

    Kev, Re-reading it, there's some odd text - like it says that a client which recognises XEP-0428's fallback tag never displays the <body/>, which seems wrong. It should, though, recognise that a body *is* a fallback and maybe mumble about it darkly.

  649. sonny has joined

  650. Daniel

    i mean we can (once oob is 'fixed') reference 66

  651. dwd

    Daniel, Or a new XEP that says how to do file transfer with '363 and OOB. That'd be fine too, and should be quick procedurally.

  652. jonas’

    Ge0rG, if we’re going semantically pure, it should go into an Informational ("defines best practices for implementation or deployment of an existing protocol") document separate from both

  653. Ge0rG

    Daniel: you could write a new XEP then, "Inline Document Placement"

  654. Daniel

    i think it already does; but we can reference it stronger

  655. jonas’

    dwd, ^5

  656. dwd

    jonas’, '/giphy high five'.

  657. Zash

    Ge0rG: you mean SIMS

  658. Ge0rG

    /giphy high five

  659. Ge0rG

    Zash: why isn't anybody using it?

  660. Daniel

    when I offered to 'fix' oob I meant adding a paragraph. I don’t want to write a new XEP if I can avoid it

  661. Daniel

    also i don’t think that will make it easier to discover

  662. Daniel

    for the 10s of developers Ge0rG had to explain to how to use 66

  663. Zash

    Ge0rG: Raisins and network effects? The examples make it look like bloat and it uses references.

  664. Ge0rG

    what I dislike about 0066+0363 is that to make it secure, you need to ask the user whether to expose their IP to $hosting_domain, then to do an HTTP HEAD to determine content-type and file size, then to let the user decide whether to download things

  665. jonas’

    "secure"

  666. dwd

    Daniel, Yeah, but if the new doc becomes the entry point for file sharing, it'll work. But let's start by documenting it on the mailing list and then we can decide where to put it.

  667. jonas’

    Ge0rG, that isn’t going to go away any time soon

  668. eevvoor has joined

  669. sonny has left

  670. Ge0rG

    jonas’: well, SIMS will solve two of the three problems.

  671. Zash

    Ge0rG: Security considerations doesn't mention this?

  672. Ge0rG

    and if we can somehow stuff a BoB preview in it

  673. jonas’

    Ge0rG, blurhash!

  674. Kev

    dwd: I was thinking that such a client would default to not showing them, but include a marker in some manner that would allow them to be revealed.

  675. Zash

    BLURHASH!

  676. Ge0rG

    Zash: > Up- and downloading files will leak the client’s IP address to the HTTP service. The HTTP service might not be the same service as the XMPP service the client is currently connected to.

  677. Ge0rG

    jonas’: not opposed to that

  678. dwd

    Kev, UX considerations? I think the overarching principle is that the client is now in a position to make that choice, rather than what the choice is.

  679. Kev

    I also thought that the fallback would benefit from a summary of what the fallback's for.

  680. uhoreg has left

  681. Rixon 👁🗨 has left

  682. Half-Shot has left

  683. Kev

    That way a client can ask the user "When a chat contains messages we don't understand of type 'message corrections' would you like to show the fallback text?".

  684. dwd

    Kev, One of the other elements the client doesn't recognise - I wondered about this, but it wasn't clear to me what the client and/or user would do.

  685. Ge0rG

    yeah, the <fallback> element should have an attribute for the namespace that is responsible for the fallback

  686. Ge0rG

    Kev: something something i18n?

  687. Kev

    Ge0rG: I don't think the namespace is interesting to the client, because it doesn't understand it, but a textual representation is.

  688. Half-Shot has joined

  689. Rixon 👁🗨 has joined

  690. uhoreg has joined

  691. Kev

    Ge0rG: sure, something something i18n, but you're already doing a message body as a fallback, so ...

  692. Zash

    What if you did the HTTP request via server-provided proxy?

  693. adityaborikar has left

  694. dwd

    Kev, I mean, I'm not against it, I just wondered whether the need was really there.

  695. Ge0rG

    Zash: how would you prevent your xmpp server from becoming an open http proxy?

  696. Zash

    Ge0rG: Magic

  697. dwd

    Ge0rG, Authentication for the Proxy?

  698. dwd

    Ge0rG, Bearer token, perhaps?

  699. Ge0rG

    dwd: rather pointless with IBR

  700. jonas’

    rewrite URLs in (plaintext) messages

  701. Zash

    Ge0rG: I mean, steal the way http upload works in matrix, with (server, identifier) and replication???

  702. Kev

    dwd: I'm too tired to present (or consider) a cogent argument, I think. You may be right.

  703. Ge0rG

    Kev: if we had a registry of namespaces, a client could do a live lookup ;)

  704. Kev

    Mostly I'm concerned that someone does something horrible like a fallback for a message receipt in a MUC room, or the suchlike. Or for reactions, for that matter.

  705. dwd

    Kev, I admit that part of this may have been the idea of a XEP with a single namespaces element and nothing more.

  706. dwd

    Kev, Ah, knowing whether a client is best off ignoring the message or displaying it might be useful, except that by and large if we don't want to display a message at all, then we should leave out the fallback body.

  707. sonny has joined

  708. Kev

    dwd: I think the (potential) issue is if someone makes a decision we disagree with.

  709. Ge0rG

    Kev: the namespace would give the user a way to opt out from the same kind of messages, regardless of the sending client's wording of what it means

  710. adityaborikar has joined

  711. Kev

    Ge0rG: This is true. You could do "This message is a fallback rendering because we don't understand the format. In future would you like to [Hide] or [Show] this type of fallback?".

  712. Ge0rG

    because if your client sends type="message correction" and my client sends "editierte Nachricht", the recipient is doomed.

  713. Ge0rG

    of course you could add both, one for the machine and one for the human.

  714. Lance has joined

  715. Ge0rG

    and then your client would maintain a map of decisions based on the previously encountered namespaces.

  716. Kev

    That only works if you say what namespace the fallback is for though, as you say.

  717. Ge0rG

    a smart client could even remove trailing numbers from that map.

  718. Ge0rG

    Kev: the frightening thing is when the client will also store the first human-readable name it encounters in the preferences list.

  719. Ge0rG

    so you end up with an auto-populated list with mixed i18n

  720. Kev

    Ge0rG: I buy your argument that namespace is better.

  721. Kev

    At least for now.

  722. pasis has left

  723. Nano4BeingYou has joined

  724. Lance has left

  725. uhoreg has left

  726. Rixon 👁🗨 has left

  727. Half-Shot has left

  728. Half-Shot has joined

  729. Rixon 👁🗨 has joined

  730. uhoreg has joined

  731. xecks has left

  732. xecks has joined

  733. neshtaxmpp has joined

  734. debacle has left

  735. matkor has joined

  736. mukt2 has left

  737. Lance has joined

  738. eevvoor has left

  739. mukt2 has joined

  740. lovetox has joined

  741. Lance has left

  742. Lance has joined

  743. krauq has left

  744. krauq has joined

  745. mukt2 has left

  746. adityaborikar has left

  747. adityaborikar has joined

  748. werdan has joined

  749. emus

    If not in your media feed already: The XMPP Newsletter for September has been published: https://xmpp.org/2020/09/newsletter-09-september/ ☕️📰️

  750. emus

    Thanks to all contributors and supporters!

  751. moparisthebest

    first, thanks for doing this, as always excellent job!

  752. moparisthebest

    second, my monthly rant, who needs annoyed to get you credentials to post it https://fosstodon.org/@xmpp/ ?

  753. moparisthebest

    otherwise stop linking it and/or let's get it deleted, looks bad that the last one posted was in June

  754. emus

    ❤️

  755. emus

    Yes you are right!

  756. moparisthebest

    do you know who might have the credentials?

  757. Seve

    Nyco :)

  758. emus

    I tried conntacting Nyco on this, but he did not reacted to it. As I would prefer to publish there as well, I think you are right to remove it actually

  759. moparisthebest

    who can contact Nyco ?

  760. emus

    I do again

  761. Seve

    I'm trying

  762. emus

    ok

  763. emus

    He said, Mastadon was an experiement, as well as reminded me that account access needs to be shared not passwords

  764. moparisthebest

    I wouldn't get hung up on that, who cares

  765. Seve

    He might be able to post there the newsletter

  766. moparisthebest

    you are the only one doing the newsletters, have him give you the password?

  767. Zash

    or create @realXMPPFoundation

  768. adityaborikar has left

  769. Ge0rG

    Seve: did you have a chance to look at the compliance page?

  770. moparisthebest

    is this another topic for board or ? who manages the official xmpp accounts?

  771. emus

    moparisthebest: I think he created that on his own

  772. moparisthebest

    then why is it on official xmpp newsletters... I assumed he created it when he was on the com team?

  773. moparisthebest

    to an outsider one of these looks more active than the other... https://mastodon.matrix.org/@matrix https://fosstodon.org/@xmpp

  774. emus

    🤷‍♂️ I think he created it with the purpose of using it for that. But no clue. I am happy to create a new mastadon account for XSF. But just not with my but official credidencials

  775. werdan has left

  776. emus

    moparisthebest: guess thats true

  777. lskdjf

    The xmpp mastodon account has 700 followers after just one year. That's 40% of what the twitter account has. A relevant amount of the decentaralization / open source community is on mastodon and there's quite some potential for spreading information about XMPP there. I think calling it an "experiment" is a bad reason for neglecting that opportunity, especially given that there are people who would be happy to actually like to make good use of it.

  778. Zash

    Do you have access to the Twitter account?

  779. Seve

    I think you guys are not being fair with Nyco

  780. Zash

    "you", emus / commteam / someone?

  781. Seve

    He created the account when we were starting with the newsletter amd so on

  782. Zash

    (I was not replying to Seve there)

  783. emus

    lskdjf, agreed, but its not that I dont want or so

  784. emus

    what Seve says ^

  785. Seve

    He created the account when we were starting with the newsletter and so on

  786. Seve

    He might be busy these days and might need help to take care of it. I've got in touch with him to see what can we do

  787. moparisthebest

    Seve, what does that have to do with anything?

  788. Seve

    Now that it has proven valuable

  789. moparisthebest

    it sounded like emus got ahold of him and Nyco said he wouldn't give emus access?

  790. emus

    I suggest to Seve and jcbrand and Nyco (?) that we arrange a meeting and discuss how to proceed

  791. emus

    They would give me only access to an account I already own there. But I dont have and I dont want my own account (at least at the moment)

  792. Seve

    I'll get back with news at the commteam emus 👍

  793. emus

    ok

  794. emus

    Anyway moparist thanks for bringing that up again

  795. moparisthebest

    I hate to be "that guy" but this is month 4 so how soon might something be done

  796. Yagiza has left

  797. guus.der.kinderen has joined

  798. moparisthebest

    now that I'm looking the linked XSF accounts are kinda all over the place: twitter: last newsletter post sept, so mostly up to date linkedin: last newsletter post june facebook: last post ever sept 2019 fosstodon: last newsletter post june reddit: no newsletter posts? not sure how this is supposed to work

  799. Seve

    moparisthebest: thanks for pointing that out, it would be nice if we can at least publish the newsletter on each of them. Writing that down.

  800. moparisthebest

    +1

  801. حفيدةالبغدادي has joined

  802. lskdjf

    a while back, it has been suggested to use a twitter-to-mastodon mirror. Surely such mirror-tools exist also for the other platforms? Such that every post on twitter is also automatically posted to linkedin, facebook, mastodon, etc

  803. حفيدةالبغدادي has left

  804. moparisthebest

    (matrix's twitter says it's bridged to it's mastodon so at least that exists)

  805. nyco has joined

  806. dwd

    I wonder if any of the companies using XMPP have a social media marketing type they could lend some time for? I can certainly ask at Pando if that would be acceptable to the XSF?

  807. karoshi has left

  808. karoshi has joined

  809. guus.der.kinderen

    I think that that'd be good.

  810. guus.der.kinderen

    we've previously discussed the option to hire someone, which met with some resistance. An in-kind donation would be preferable, I think.

  811. neshtaxmpp has left

  812. emus

    I think we should just keep/have an XSF account directly accessible from XSF setups, and nothing through others. Haveing accounts with rights to tweet connected okay, but there should be always offical credidencials registered. And I also against letting any company being the main contact of our media accounts. All of that and as it already is sounds crazy to me

  813. jcbrand has left

  814. moparisthebest

    yea seems like active comms team members being able to actually use the accounts seems like a required first step to anything

  815. Shell

    lskdjf: generally there's things like Hootsuite/Zoho Social/etc for this, although they have a monthly fee.

  816. krauq has left

  817. krauq has joined

  818. moparisthebest

    I mean, with the hopefully-one-post-per-month frequency we are talking is that even needed?

  819. karoshi has left

  820. dwd

    emus, I'm not suggesting the social media is run by a company. I'm suggesting one (or more) of the companies might have social media people who could work for the XSF, either as volunteers or sponsored by their employer. Basically that's the same principle as many of the other people doing XSF stuff.

  821. xecks has left

  822. antranigv has left

  823. xecks has joined

  824. Andrzej has left

  825. moparisthebest

    wouldn't that require someone (the board???) to define what they want that social media presence to look like?

  826. guus.der.kinderen

    I think that's more in commsteam area

  827. guus.der.kinderen

    iirc, board expressed willingness to facilitate comms with how they'd prefer to work: with a hired marketing consultant, or with an in-kind donation of such a person along the lines of what dwd suggested (or, although not discussed, any other suggestion that they might have)

  828. Andrzej has joined

  829. karoshi has joined

  830. mukt2 has joined

  831. krauq has left

  832. krauq has joined

  833. jcbrand has joined

  834. sonny has left

  835. sonny has joined

  836. sonny has left

  837. sonny has joined

  838. raghavgururajan has left

  839. raghavgururajan has joined

  840. mukt2 has left

  841. raghavgururajan has left

  842. karoshi has left

  843. miho has joined

  844. Shell has left

  845. Shell has joined

  846. raghavgururajan has joined

  847. miho has left

  848. DebXWoody has left

  849. raghavgururajan has left

  850. nyco has left

  851. raghavgururajan has joined

  852. emus

    dwd, guus.der.kinderen: I think thats a thing we should be able clear out and organise ourselves. It is not a problem to drop the tweets for mw, its just a matter of access (I dont have, because I dont run an account myself). So, lets wait what Seve comes back with for the moment

  853. guus.der.kinderen

    Commteam members having access to ... comms ... seems like an obvious basic requirement.

  854. emus

    guus.der.kinderen: jc and nyco have. but nyco seems out and Jc has no time

  855. mimi89999 has left

  856. mimi89999 has joined

  857. Andrzej has left

  858. jcbrand

    There's a simple solution to giving emus Twitter access. He just needs to create an account

  859. dwd

    emus, I'm just saying that "ourselves" could usefully include some actual marketing expertise, and companies that already work in/around XMPP might be a place to recruit, and said companies might even let them do it on company time.

  860. jcbrand

    Last I heard, he doesn't want to. There is no other to give him access AFAIK

  861. Alex has left

  862. jcbrand

    Last I heard, he doesn't want to. There is no other way to give him access AFAIK

  863. dwd

    emus, I really don't understand why we'd want to deliberately avoid having professional help here.

  864. Seve will this week create a Twitter account to be able to tweet too

  865. mimi89999 has left

  866. mimi89999 has joined

  867. guus.der.kinderen

    Well, whatever commteams thinks is a good idea. I'm not part of that team for a good reason: I suck at comms, and it does not have my interest much either :)

  868. guus.der.kinderen

    Board has already expressed that if commteam has thoughts on how to improve things, there's willingness to look at how that can be facilitated (budget or otherwise)

  869. Zash

    There's some delicious irony in building communications tools and not being great at communication. (Speaking of myself here.)

  870. guus.der.kinderen

    having another commteam member that, in his/her daytime job works in communications or marketing or somesuch seems like a valuable addition.

  871. Zash

    Tho, helping others communicate is nice.

  872. Nano4BeingYou has left

  873. neshtaxmpp has joined

  874. mukt2 has joined

  875. lskdjf

    emus, I think there might be a misunderstanding between you and dwd. You seem to think that dwd suggested that the professionals take over most of the communication work. You apparently assumed the professional would be the only one with social media access and would be the main contact, but dwd never said so. He only spoke of having them "help". As far as I understand, that help might also consist of giving tips from their experience.

  876. Andrzej has joined

  877. dwd

    lskdjf, Oh, no, I was planning this whole evil cororate takeover thing. Sorry if you misunderstood.

  878. Zash

    dwd: I'm afraid you forgot to put the new cover sheet on your evil corporate takeover progress report.

  879. moparisthebest

    and not even a TPS report

  880. dwd

    And remember, next Friday is Hawaiian shirt day.

  881. Zash

    and Happy New Fiscal Year to all you enterprises out there!

  882. guus.der.kinderen

    I'm going to steal a printer and beat the crap out of it in a field. Anyone care to join.

  883. dwd

    wellyouseethatwasmystapler.

  884. eevvoor has joined

  885. mukt2 has left

  886. pasdesushi has joined

  887. jcbrand has left

  888. Mikaela has left

  889. nyco has joined

  890. karoshi has joined

  891. pasdesushi has left

  892. wurstsalat smells burned office supplies

  893. Zash

    I love the smell of burnt plastic in the evening

  894. mukt2 has joined

  895. pasdesushi has joined

  896. karoshi has left

  897. alameyo has left

  898. alameyo has joined

  899. krauq has left

  900. krauq has joined

  901. jcbrand has joined

  902. karoshi has joined

  903. pasdesushi has left

  904. emus

    dwd: Yeah, agreed to take professional help. Just the critics on the account access. No, there was a misunderstanding that I refuse help I think guus.der.kinderen: Yeah that would be great. > Last I heard, he doesn't want to. There is no other way to give him access AFAIK Yes, that is the case. Furthermore, I would need to do that for mastadon, linkedin, reddit etc. as well 😬 I also think, as of not putting everything on my workload, that this is a good task someone else with at least one of those accounts can take over. And it just feels weird to me to create an account to work with another account 🤷‍♂️ Sorry for that guys.

  905. vanitasvitae has left

  906. vanitasvitae has joined

  907. karoshi has left

  908. debacle has joined

  909. karoshi has joined

  910. Andrzej has left

  911. karoshi has left

  912. karoshi has joined

  913. Alex has joined

  914. karoshi has left

  915. Alex has left

  916. LNJ has left

  917. LNJ has joined

  918. karoshi has joined

  919. Andrzej has joined

  920. jcbrand has left

  921. werdan has joined

  922. karoshi has left

  923. antranigv has joined

  924. karoshi has joined

  925. Lance has left

  926. Andrzej has left

  927. karoshi has left

  928. werdan has left

  929. karoshi has joined

  930. karoshi has left

  931. Andrzej has joined

  932. Wojtek has left

  933. mukt2 has left

  934. karoshi has joined

  935. Wojtek has joined

  936. Wojtek has left

  937. guus.der.kinderen has left

  938. Andrzej has left

  939. ralphm has left

  940. ralphm has joined

  941. arc has left

  942. arc has joined

  943. arc has left

  944. arc has joined

  945. Andrzej has joined

  946. Wojtek has joined

  947. Wojtek has left

  948. j.r has left

  949. j.r has joined

  950. antranigv has left

  951. Andrzej has left

  952. adityaborikar has joined

  953. antranigv has joined

  954. Andrzej has joined

  955. adityaborikar has left

  956. adityaborikar has joined

  957. deuill has joined

  958. alameyo has left

  959. krauq has left

  960. deuill has left

  961. krauq has joined

  962. alameyo has joined

  963. alex-a-soto has left

  964. alex-a-soto has joined

  965. lskdjf has left

  966. Andrzej has left

  967. intosi has joined

  968. peetah has left

  969. peetah has joined

  970. j.r has left

  971. alameyo has left

  972. j.r has joined

  973. LNJ has left

  974. papatutuwawa has left