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