jdev - 2022-01-04


  1. me9 has left
  2. edhelas has left
  3. edhelas has joined
  4. marmistrz has left
  5. atomicwatch has joined
  6. kikuchiyo has joined
  7. thomaslewis has joined
  8. lovetox has joined
  9. thomaslewis has left
  10. thomaslewis has joined
  11. thomaslewis has left
  12. suohua has joined
  13. suohua has left
  14. suohua has joined
  15. admin has joined
  16. sonny has left
  17. sonny has joined
  18. suohua has left
  19. sonny has left
  20. thomaslewis has joined
  21. thomaslewis has left
  22. 9lakes has joined
  23. thomaslewis has joined
  24. Pete has left
  25. Pete has joined
  26. jgart has joined
  27. jgart has left
  28. admin I would like to apply for membership and need to obtain a wiki account Username in CamelCase: xnamed Email: xnamedx@gmail.com Real name: if not necessary I prefer not to make it public in the wiki or web logs
  29. mac has left
  30. qy The awful thing about matrix is that its really easy to do x-over-matrix but near impossible to do matrix-over-x without just being a homeserver
  31. qy So it kinda spreads by basic nature
  32. admin has left
  33. lovetox has left
  34. wurstsalat has left
  35. xnamed has left
  36. Pete has left
  37. Pete has joined
  38. doge > The awful thing about matrix is that its really easy to do x-over-matrix but near impossible to do matrix-over-x without just being a homeserver Why's that
  39. 9lakes has left
  40. 9lakes has joined
  41. debacle has left
  42. Pete has left
  43. Pete has joined
  44. lovetox has joined
  45. moparisthebest has left
  46. qy Because of the requirement to maintain the full room state for anything to make sense
  47. qy Or, at least the auth chain
  48. qy Once youre doing that, you're already basically a homeserver, so there's no half-assing it really
  49. 9lakes has left
  50. thomaslewis So many bad decisions in Matrix…
  51. doge > Because of the requirement to maintain the full room state for anything to make sense That's how it makes sure no messages are lost isn't it
  52. doge On jabber lost messages are common in my experience. One wrong circumstance and it starts failing
  53. jgart has joined
  54. SouL has joined
  55. atomicwatch has left
  56. atomicwatch has joined
  57. msavoritias has joined
  58. dezant has left
  59. serge90 has left
  60. jgart has left
  61. emus has joined
  62. serge90 has joined
  63. pasdesushi has joined
  64. 9lakes has joined
  65. dezant has joined
  66. atomicwatch has left
  67. atomicwatch has joined
  68. atomicwatch has left
  69. atomicwatch has joined
  70. atomicwatch has left
  71. Yagizа has joined
  72. wurstsalat has joined
  73. Vaulor has left
  74. qy Yup
  75. serge90 has left
  76. serge90 has joined
  77. dezant has left
  78. emus Dear Jabber / XMPP Devs, please take a look at this site and consider to make an entry for yourselve: https://xmpp.work/all-listings/
  79. Vaulor has joined
  80. sonny has joined
  81. marmistrz has joined
  82. Ingolf has left
  83. Ingolf has joined
  84. Alex has joined
  85. dezant has joined
  86. huhn has joined
  87. serge90 has left
  88. serge90 has joined
  89. doge has left
  90. doge has joined
  91. dezant has left
  92. goffi has joined
  93. homebeach has left
  94. Matrix Traveler (bot) has left
  95. Matrix Traveler (bot) has joined
  96. homebeach has joined
  97. Neustradamus has left
  98. larma has joined
  99. suohua has joined
  100. suohua has left
  101. suohua has joined
  102. marmistrz has left
  103. marmistrz has joined
  104. rafasaurus has left
  105. Dele Olajide has joined
  106. suohua has left
  107. marmistrz has left
  108. dezant has joined
  109. rafasaurus has joined
  110. marc0s has left
  111. marc0s has joined
  112. doge has left
  113. doge has joined
  114. Dele Olajide has left
  115. marc0s has left
  116. marc0s has joined
  117. Dele Olajide has joined
  118. Dele Olajide has left
  119. Dele Olajide has joined
  120. marc0s has left
  121. marc0s has joined
  122. Dele Olajide has left
  123. marc0s has left
  124. marc0s has joined
  125. Dele Olajide has joined
  126. nephele has joined
  127. doge has left
  128. marc0s has left
  129. marc0s has joined
  130. nephele doge: Yes it makes sure messages aren't lost, in a sense. But i talso means that if your homeserver has a tiny difference in any validation alghorythm to any other homeserver that one of you will get effectively kicked out of any rooms you share, because the roomstate will be forked one that validation detail is triggered
  131. nephele You could add lua tables with a depth of like 1000 i think and then construct would defederate the room :D, there was also instances synapse would defederate and others would stay... it's all very finicky, either you have everything correct or it inevitably blows up
  132. nephele json tables... not lua
  133. doge has joined
  134. doge "Fail fast" It's preferrable to know something's failed. Unlike in xmpp where when there's a failure you get some messages, lose some, get some duplicates and whatnot, you end up having to ask your interlocutor what they received and what they didn't receive, so basically do the acking yourself
  135. xecks has left
  136. Dele Olajide has left
  137. junaid has left
  138. junaid has joined
  139. MattJ XMPP does its own acking... once your server acknowledges your message, messages get delivered or you get a delivery error. We also have positive delivery receipts.
  140. nephele doge: This isn't failing fast, it is more like an inherent design flaw, it means that every time one part of the federation can't handle a single message that the entire federation then kicks that part out
  141. xecks has joined
  142. doge MattJ: > XMPP does its own acking... once your server acknowledges your message, messages get delivered or you get a delivery error. We also have positive delivery receipts. Still losing messages is almost the norm here unfortunately nephele: > doge: This isn't failing fast, it is more like an inherent design flaw, it means that every time one part of the federation can't handle a single message that the entire federation then kicks that part out Well what else would they do? Tolerate an error?
  143. nephele Are you asking me "How would this design be fixed" or "How would you propose to handle this in the current design"?
  144. nephele As for my part: I've never had any messages be lost in xmpp
  145. MattJ doge, what server/clients are you using? Pidgin? :)
  146. nephele (I did however manage to make sure people lost messages they wrote to me in matrix :D)
  147. doge MattJ: conversations, gajim
  148. MattJ and do you get delivery receipts for the missing messages?
  149. nephele Matrix told me the joys of "message based html injection", that was quite fun to discover... the riot or element or vector client or whatever was absolutely horrible when dealing with their fancy formated html messages
  150. doge MattJ: yeah I also sometimes get duplicates, although that's gone now I think
  151. edhelas failled message delivery on XMPP ? which is also based on TCP ? 🤔
  152. MattJ doge, in which direction are messages getting lost? From you to your contacts, or contacts to you?
  153. doge MattJ: > doge, in which direction are messages getting lost? From you to your contacts, or contacts to you? Both
  154. MattJ Do you or your contacts use multiple devices?
  155. nephele edhelas: It's possible of course, the transport protocol is not the only thing to touch the message ;)
  156. doge MattJ: > Do you or your contacts use multiple devices? They do, so do I
  157. edhelas nephele yes, it is possible, but I actually want to know how
  158. doge Although I had messages lost even with a cobtact who didnt use multiple devs
  159. MattJ Does your server have MAM and Carbons support enabled?
  160. nephele Heh... Renga still needs to implement MAM
  161. nephele edhelas: yes, it would be interesting to figure out
  162. doge MattJ: mam perhaps. Although I've tried more than one server. Creep.im, draugr.de and then some. I found I actually had to have two accounts for when one server was down
  163. MattJ doge, both are necessarily if you want a decent experience, and they are supported and enabled by default on practically all servers these days ( https://compliance.conversations.im/test/xep0313/ )
  164. emus Dear Jabber / XMPP Devs, please take a look at this site and consider to make an entry for yourself: https://xmpp.work/all-listings/
  165. sonny has left
  166. sonny has joined
  167. MattJ If you see a delivery receipt, it means the recipient's client received the message. If it's acknowledging messages and not displaying them, that's a bad client bug, not a protocol issue
  168. MattJ Also for it to reach that point, the message would be stored in the MAM archive, so cannot be lost
  169. doge All clients I've used happend to be buggy then
  170. edhelas all XMPP are buggy for sure
  171. MattJ I've not heard of anyone experiencing this issue, so the common factor seems to be you, your clients or your server
  172. doge MattJ: and my contacts'
  173. MattJ As I explained, losing messages is pretty difficult to achieve
  174. MattJ Right, all your contacts have you as a common factor :)
  175. doge MattJ: ok shoyld I be using smth different than conversations? I think it's about the most popular client, would be strange if it was also the most buggy one
  176. MattJ No, Conversations should be fine. I and many others use it all the time without such issues.
  177. jonas’ what are the chances this is some obscure OMEMO issue?
  178. MattJ But it does require the server to be up to date with modern requirements (you can check this in the 'server info' section of the account details in the app, or at https://compliance.conversations.im/ )
  179. doge MattJ: > No, Conversations should be fine. I and many others use it all the time without such issues. Do you talk to many people with direct messages? Omemo?
  180. Wojtek has joined
  181. jonas’ oh also creep.im has been added to some banlists, so some loss of connectivity is to be expected between creep.im and non-creep.im accounts.
  182. doge jonas’: creep.im is dead now, yeah
  183. doge So it was a good idea to have two accounts for that additional reason :)
  184. MattJ doge, yes to both, my whole family use Snikket (the Android app is 99.9% Conversations)
  185. doge MattJ: which server?
  186. MattJ A self-hosted Snikket server (which is Prosody)
  187. doge Oh, that may have been the reason
  188. doge For good experience
  189. Dele Olajide has joined
  190. suohua has joined
  191. Dele Olajide has left
  192. msavoritias I havent had a single message bieg lost here either. Multiple servers and applications. Thanks for the heads up about creep btw.
  193. Dele Olajide has joined
  194. nephele I'm wondering for MAM, the specification sais that a server for it may not be an XMPP server, sounds like there could be a specific MAM suplying server next to the client for local history storage or so? Does something like that exist?
  195. Dele Olajide has left
  196. debacle has joined
  197. MattJ nephele, an example I see is for clients to exchange history between each other, e.g. if you add a new client to your account and want to migrate past history to that new client
  198. MattJ But I don't know of anyone actually implementing that, it would have some issues
  199. nephele That could be a possible case, I was wondering if someone made something that stores history locally /next to/ an existing client, in the client I could probably fairly easily querry this local store then and only ask the server for newer messages
  200. sonny has left
  201. sonny has joined
  202. MattJ You could, but 1) why? 2) it falls apart with E2EE
  203. nephele As a bit of background context: Renga did have local storing of chat history, but it was extremely messy (basically when the UI would get a new message and add it to the backlog it would also append it in the same manner to the local chatlog)
  204. Martin It falls apart with OMEMO, PGP or Ox should be fine. :)
  205. nephele Why would it fall apart with E2EE?
  206. Martin nephele: OMEMO uses forward secrecy so each message could be only decrypted once per key.
  207. nephele I don't really understand how that would be affected, is there something inherently which would prevent MAM working with OMEMO?
  208. nephele I haven't really looked at it much, but as i understand it if you have a session key to decrypt messages that key will work fine in the future to decrypt the same message again, so supposedly my client would have to store this key to decrypt backlog messages in the future anyway, I don't see how a local history store would conflict with that (as opposed to the history stored on the server)
  209. Link Mauve nephele, storing every single key expecting to download the messages again, is pretty much equivalent to just storing every single message.
  210. Link Mauve As you usually advance the key with each message (approximately).
  211. Link Mauve Plus, your MAM server could be configured to have a short retention time, and then you won’t be able to go back in time any longer.
  212. Link Mauve At JabberFR we keep personal archives for only two weeks, for instance.
  213. nephele As for my why: It seems like a much easier way to implement local message archiving and cut down on latency for backlog messages that I already have locally. (Would be the exact same codepath as MAM already would have anyhow :3)
  214. nephele Link Mauve: I don't know about you but i don't want to loose my backlog messages, ever. But that is also why I am on a personal server that can be configured as such
  215. MattJ Cut down on latency... you imply making a direct connection to the archive?
  216. nephele What do you mean by direct?
  217. MattJ I mean not via your normal XMPP connection
  218. Link Mauve nephele, then relying on MAM on any random server storing messages forever is not what you want in your client.
  219. nephele My idea would rather be to have a server running on the same machine as the client that basically /only/ does MAM, as a provider for the local cache of the client
  220. Link Mauve So storing the per-message decryption key without the message is a bit useless.
  221. Link Mauve nephele, most clients use a sqlite database or a (bunch of) text file for that.
  222. Link Mauve That way they don’t need to spawn a server.
  223. msavoritias has left
  224. msavoritias has joined
  225. nephele What the on-disk store is is a bit beside the point, It seems to me to be an easy way to have the local history backed up without needing to have severall code paths in the client to deal with that.
  226. nephele Since basically: XMPP has specified a way I can get the backlog consistently, and I have to implement that anyway, it seems to make sense to use that for local backlog aswell, that way if the client ever displays for example more stuff about messages in the future it would also be visible from the local backlog stored messages.
  227. bung has joined
  228. xnamed has joined
  229. mac has joined
  230. bung has left
  231. al has joined
  232. Wojtek has left
  233. atomicwatch has joined
  234. marc0s has left
  235. marc0s has joined
  236. xnamed has left
  237. thomaslewis has left
  238. thomaslewis has joined
  239. al has left
  240. xnamed has joined
  241. mac has left
  242. mac has joined
  243. pep. Re http upload, the Expires header, what is it for? Is it also something the client has to pass in the PUT request? Or is it for the client to know when it expires, or both? And if the client doesn't pass it, what happens? Servers store that indefinitely? :P
  244. pep. (We worry about servers but do we worry about clients!)
  245. jonas’ pep., the headers are to be opaque for the client
  246. jonas’ pass them on, don't interpret tem
  247. jonas’ pass them on, don't interpret them
  248. jonas’ if you don't pass it on, the HTTP server may refuse your request
  249. pep. Ok well that isn't specified either iirc :/
  250. jonas’ why?
  251. jonas’ which part is missing?
  252. pep. why what
  253. pep. That the HTTP server may refuse the request, and that I have to pass the headers
  254. pep. It's implied, and yeah of course I see an Authorization header I get an idea, but it's not actually mentioned
  255. jonas’ hah
  256. jonas’ you're right
  257. jonas’ there's no word in the XEP which says that you have to pass on the headers
  258. jonas’ only that they exist, that you must validate them and do things with them, but not that you have to pass them on
  259. jonas’ pep., mind making a patch?
  260. pep. Sure
  261. pep. It's implied when it says I shouldn't pass other headers
  262. pep. But that's a weird way of saying I have to pass these
  263. jonas’ yep
  264. jonas’ needs better wording
  265. Martin > In addition to the Content-Length and Content-Type header the client MUST include all allowed headers that came with the slot assignment. Not this?
  266. jonas’ uh
  267. jonas’ yeah, that'd be it
  268. pep. The "headers are opaque to the clients", is that also commonly accepted?
  269. Martin In 6.
  270. pep. Can I also put that in there?
  271. Martin https://xmpp.org/extensions/xep-0363.html#upload
  272. jonas’ pep., you can add that to 7. (as a SHOULD NOT, I guess)
  273. pep. I'm actually curious why Expires goes through the client tbh :/
  274. jonas’ pep., probably S3
  275. pep. Really we worry about servers but not about clients at all
  276. jonas’ what is your concern with that regarding clients?
  277. pep. They can just skip that
  278. pep. Or extend it or..
  279. jonas’ skip what?
  280. pep. The header
  281. Alex has left
  282. jonas’ that's their problem then
  283. pep. It's the receiving server's problem. They don't know what the XMPP server said
  284. jonas’ it's the HTTP server's problem
  285. pep. Then why is that header even sent from the XMPP server
  286. jonas’ to allow schemes where the XMPP and the HTTP server cannot or should not talk directly to one another
  287. pep. Trusting the client to relay
  288. jonas’ no
  289. jonas’ you'd not blindly trust the client
  290. jonas’ you'd sign the headers, obviously
  291. jonas’ using an HMAC or somesuch
  292. pep. Ah ok. What would that look like? More or less
  293. jonas’ (like the "http_upload_external" protocol from prosody does, though it doesn't use headers)
  294. jonas’ http_upload_external has a verification key which is (in version two) hmac(filename || content_type || size)
  295. jonas’ this is part of the URL
  296. pep. That's also specified somewhere?
  297. jonas’ here: https://modules.prosody.im/mod_http_upload_external.html
  298. pep. Ok
  299. jonas’ but it doesn't matter for the client
  300. pep. Sure
  301. jonas’ because it works within the boudnaries of '363
  302. pep. Thanks
  303. jonas’ if you wanted / needed to pass on headers like Expires, those would also need to be signed, e.g. by including them in an HMAC you pass through the Authorization header
  304. jonas’ but stuff like this allows the XMPP server to securely control parameters of the upload, such as lifetime, used content-type or even check the quota. and have the HTTP service be really dumb
  305. jonas’ ("you" being the server side conglomerate in this case)
  306. jonas’ but all of this are implementation details of the server side. adding "you should sign your headers because clients are evil" to the implementation/security notes makes total sense though
  307. pep. I mean if we start considering servers evil we might want to do so for clients as well
  308. jonas’ we generally do ;)
  309. pep. Dunno. I feel like there's part of the community who has make a shift from considering clients evil to the opposite, and now I feel it's either one or the other :P
  310. pep. Dunno. I feel like there's part of the community who has made a shift from considering clients evil to the opposite, and now I feel it's either one or the other :P
  311. jonas’ right
  312. jonas’ I do not share that viewpoint, but YMMV and in the end, it doesn't matter. if you see something, fix something.
  313. mac has left
  314. xnamed has left
  315. xnamed has joined
  316. pep. Here, pushed https://github.com/xsf/xeps/pull/1140
  317. marc0s has left
  318. marc0s has joined
  319. pep. Ah linkmauve has already added a thing for multiple headers
  320. pep. I guess that shouldn't conflict (spec-wise) with my changes. But I can rebase on top of that if necessary
  321. Alex has joined
  322. marc0s has left
  323. marc0s has joined
  324. xnamed has left
  325. x51 has joined
  326. Wojtek has joined
  327. emus has left
  328. larma has left
  329. huhn has left
  330. emus has joined
  331. serge90 has left
  332. suohua has left
  333. suohua has joined
  334. Wojtek has left
  335. Wojtek has joined
  336. xnamed has joined
  337. suohua has left
  338. PapaTutuWawa has joined
  339. PapaTutuWawa has left
  340. PapaTutuWawa has joined
  341. qy > edhelas wrote: > all XMPP are buggy for sure All xmpp devs are entemologists
  342. edhelas That's why we like to leave bugs everywhere
  343. qy Exactly
  344. Wojtek has left
  345. Wojtek has joined
  346. larma has joined
  347. xnamed Alex, Ge0rG, sysops, have you read my message?
  348. Wojtek has left
  349. jgart has joined
  350. Ge0rG xnamed: sorry, say what?
  351. xnamed > I would like to apply for membership and need to obtain a wiki account > Username in CamelCase: xnamed > Email: xnamedx@gmail.com > Real name: if not necessary I prefer not to make it public in the wiki or web logs
  352. Wojtek has joined
  353. Ge0rG xnamed: xnamed is not camelcase, it will become Xnamed
  354. xnamed It's ok
  355. Ge0rG > The user account for Xnamed (talk) has been created. Please check your email
  356. xnamed Ge0rG: thank you
  357. larma has left
  358. atomicwatch has left
  359. emus xnamed: I think its mandatory to place your real name. However, you can do most things here without being a XSF member ralphm:
  360. xnamed emus: I'm planning to change my real name in the future
  361. pulkomandy has left
  362. pulkomandy has joined
  363. Ge0rG emus: the real name is only mandatory for XSF membership, not for editing the wiki
  364. emus yes, but it was stated to plan to apply
  365. xnamed Ge0rG: I asked for a wiki account because I want to become XSF member
  366. emus xnamed: If you prefer to stay anonymous you can still do many things incl. xep development, right?
  367. pep. And nobody ever confirmed the realname was actually required for membership. Board just decided so
  368. jonas’ xnamed, fwiw, changing the real name associated with the account is trivial
  369. pep. And nobody ever confirmed the realname was actually required legally for membership. Board just decided so
  370. jonas’ been there had that done
  371. xnamed It's not a big problem, I will use my real but in case I changed it in the future I will request changing it on the wiki too, is it okay?
  372. emus Alex:
  373. jonas’ xnamed, back then I sent an email to the members@ list and made the corresponding pull requests myself, but you can also ask one of the sysops to help you with that, yes
  374. Sam That's fine; note that you don't have to use your real name for your wiki account, you just have to put it on your application each year
  375. Sam So you won't have to change anything. If you change your name, just put the new one on next years application.
  376. xnamed > xnamed: If you prefer to stay anonymous you can still do many things incl. xep development, right? I'm already doing this
  377. nephele has left
  378. nephele has joined
  379. xnamed Thank you all 👍
  380. Alex Also the real name will be listed on our XSF website. There is a list of members with real names
  381. pulkomandy has left
  382. pulkomandy has joined
  383. larma has joined
  384. larma has left
  385. xnamed Ok
  386. doge has left
  387. larma has joined
  388. pep. And maybe someday there's be a rationale for why this is required
  389. emus I guess because how you can have a legal entity for donations with anonymous people
  390. pep. The entity isn't anonymous
  391. pep. Board isn't anonymous
  392. emus But why have a anonymous organsiation actually?
  393. pep. Why require fullnames?
  394. emus I don't understand why we should build an anonymous organisation. Especially if we do communication. In that aspect it should be open. but we are getting offtopic
  395. pep. Open doesn't mean not private
  396. pep. Open doesn't mean we should get rid of privacy
  397. pep. Open doesn't actually mean much anyway.
  398. pep. (or it means too much)
  399. emus but if its a organisation that is also a legal instance
  400. pep. You seem to be throwing random words in the air in hope that I catch them
  401. emus yes but as an organisation it is also a legal instance
  402. pep. And also going in circles. I've already answered this
  403. Wojtek has left
  404. emus I dont think so
  405. emus I think its impirtant to have transparency because otherwise random members can join and vote
  406. pep. The day the XSF gets there maybe they can start worrying about it. So far it's only idling members
  407. pulkomandy some people are known only by their nickname here, and having their realname wouldn't help you at all
  408. pep. And no check is actually done whether the name is legal
  409. pulkomandy making sure each member is who they pretend they are is useful. But that doesn't necessarily means "real" name
  410. Zash Like when bear was voted out because nobody knew them by their afk name.
  411. nephele It feels really wierd to be called by my real name in the context of programming in english, it's just always my nickname normally :D
  412. pep. So no I don't think it's justified to require fullnames. There's no legal basis for members (and is there for board? Maybe the chair?), or at least my question was never answered. (Because yes I asked and nobody cared)
  413. Zash xsf@ might be a more appropriate place to discuss the legal stuff of the XSF than jdev@
  414. pep. Sure, it just popped up in here.
  415. pep. But why do I care anyway, I'm no member anymore.
  416. Zash https://logs.xmpp.org/xsf/2021-11-04?p=h#2021-11-04-1345a93abcf14a57 (and surrounding discussion)
  417. emus > pep. escribió: > So no I don't think it's justified to require fullnames. There's no legal basis for members (and is there for board? Maybe the chair?), or at least my question was never answered. (Because yes I asked and nobody cared) sorry, but this is just your perception. I also dont like to place my name, but I am still not an anarchist
  418. Sam Most of this doesn't matter. The state of Deleware allows anonymous members, but does not allow anonymous directors, so if we don't go ahead and get the names of members it becomes confusing if they decide to run for board later (you have to keep track of who can and can't run for board because they don't have their name on the membership list). It also doesn't matter if the XSF doesn't check if the name is legal or not. If the secretary of state in Deleware tries to revoke our non-profit status we could say "we required the name, but the person lied to us" and then it's their problem. It's just doing the minimal thing to make sure the XSF can retain its tax exempt status, which is good. As far as I know having names does not avoid multiple votes, we have other mechanisms (voting / the application where you'd need to list work you've done) for that.
  419. Sam "voting for members initially" I mean, obviously general voting does not avoid multiple votes :)
  420. pep. Yeah so.. only board is required to have fullnames public then.
  421. Sam By law, yes.
  422. Sam However, the board is able to decide the rules for membership and though I can't say exactly why they chose to require full names, I suspect it's because it makes it much easier to sort things out later if there are any conflicts.
  423. pep. > but I am still not an anarchist lolwat
  424. jonas’ Sam, fwiw, board membership doesn't even require XSF membership, hence the argument w.r.t. full names is kind of moot anyway -- you need to collect the information for prospect board members separately, in theory at least, anyway.
  425. pep. Sam, yeah and I am sure this is excluding potential members. I wasn't aware of the discussion Zash linked but that's yet another case
  426. pep. If the XSF doesn't care then that's that. But that's a good step backwards wrt inclusivity
  427. jonas’ it's not a step backwards, it's not a step at all ;)
  428. pep. Right, it was already there
  429. pep. But the multiple chats and refusals to change this isn't setting the track record nicely
  430. jonas’ aside: this is off-topic for this room, and unless you (general, not second person) actually works toward improving/fixing things, please avoid wasting the bandwidth of everyone here. Just saying "this is bad but nobody cares" isn't going to help anyone.
  431. emus > pep. escribió: > If the XSF doesn't care then that's that. But that's a good step backwards wrt inclusivity Well, if not all agree to it doesnt mean "we" dont care. I think its a harsh statement
  432. jonas’ names
  433. pep. emus, afaict board says what the XSF says
  434. jonas’ End Of Topic.
  435. goffi has left
  436. pep. emus, afaict board sets what the XSF says
  437. jonas’ xmpp:xsf@muc.xmpp.org?join would be the right place to discuss this and move toward progress. The room is also accessible for non-members, so those of you who don't already happen to be in there can join there.
  438. pep. jonas’, I merged #1135 and #1130 (from linkmauve and me respectively) into #1140 btw
  439. pep. Re 363
  440. pep. These should all be editorial changes
  441. jonas’ uh-uh
  442. pep. Maybe.
  443. me9 has joined
  444. xecks has left
  445. xecks has joined
  446. mac has joined
  447. jonas’ pep., https://github.com/xsf/xeps/pull/1140#pullrequestreview-843840558
  448. pep. Should I split it?
  449. pep. So that the rest goes in quickly
  450. jonas’ only the "in bytes" and the signing of headers I could be convinced to let go without passing by council
  451. jonas’ so I don't see value in splitting this
  452. jonas’ and it creates more work for me
  453. pep. Ok. I'll update the revision block then
  454. jonas’ thanks
  455. raghavgururajan has left
  456. raghavgururajan has joined
  457. marc0s has left
  458. marc0s has joined
  459. marc0s has left
  460. marc0s has joined
  461. larma has left
  462. larma has joined
  463. emus has left
  464. marmistrz has joined
  465. goffi has joined
  466. atomicwatch has joined
  467. COM8 has joined
  468. COM8 has left
  469. COM8 has joined
  470. COM8 has left
  471. xnamed has left
  472. mac has left
  473. huhn has joined
  474. huhn has left
  475. 9lakes has left
  476. nephele has left
  477. stpeter has joined
  478. x51 has left
  479. nephele has joined
  480. me9 has left
  481. 9lakes has joined
  482. huhn has joined
  483. huhn has left
  484. xnamed has joined
  485. 9lakes has left
  486. bung has joined
  487. huhn has joined
  488. 9lakes has joined
  489. mac has joined
  490. 9lakes has left
  491. 9lakes has joined
  492. dezant has left
  493. raghavgururajan has left
  494. huhn has left
  495. huhn has joined
  496. huhn has left
  497. huhn has joined
  498. huhn has left
  499. huhn has joined
  500. me9 has joined
  501. huhn has left
  502. huhn has joined
  503. atomicwatch has left
  504. spectrum has left
  505. atomicwatch has joined
  506. huhn has left
  507. huhn has joined
  508. huhn has left
  509. nephele has left
  510. nephele has joined
  511. goffi has left
  512. nephele has left
  513. mac has left
  514. marc0s has left
  515. marc0s has joined
  516. nephele has joined
  517. marc has left
  518. nephele has left
  519. nephele has joined
  520. huhn has joined
  521. huhn has left
  522. huhn has joined
  523. goffi has joined
  524. nephele has left
  525. Yagizа has left
  526. spectrum has joined
  527. xnamed has left
  528. xnamed has joined
  529. emus has joined
  530. jubalh has left
  531. huhn has left
  532. huhn has joined
  533. huhn has left
  534. SouL has left
  535. spectrum has left
  536. spectrum has joined
  537. SouL has joined
  538. xnamed has left
  539. Sam has left
  540. Sam has joined
  541. xecks has left
  542. msavoritias has left
  543. huhn has joined
  544. huhn has left
  545. huhn has joined
  546. huhn has left
  547. huhn has joined
  548. huhn has left
  549. xecks has joined
  550. huhn has joined
  551. huhn has left
  552. paul has left
  553. atomicwatch has left
  554. huhn has joined
  555. huhn has left
  556. pasdesushi has left
  557. stpeter has left
  558. larma has left
  559. larma has joined
  560. larma has left
  561. larma has joined
  562. huhn has joined
  563. huhn has left
  564. huhn has joined
  565. huhn has left
  566. marc0s has left
  567. marc0s has joined
  568. larma has left
  569. larma has joined
  570. goffi has left
  571. larma has left
  572. larma has joined
  573. larma has left
  574. larma has joined
  575. Martin has left
  576. xecks has left
  577. larma has left
  578. larma has joined
  579. xecks has joined
  580. me9 has left
  581. wurstsalat has left
  582. larma has left
  583. larma has joined
  584. larma has left
  585. larma has joined