XSF Discussion - 2022-03-11


  1. moparisthebest

    Any thoughts on best practices re: .onion XMPP servers? I'm planning on actually writing this down in a xep I'm thinking for outgoing connections, do starttls on the regular ports or direct TLS on 443 and accept literally any certificate on incoming s2s just make an outgoing connection and validate that the certificate is the same, then offer sasl external Thoughts, good, bad, whatever?

  2. TheCoffeMaker

    moparisthebest: It would be great, this can also be applied to other VPNs ... Some friemd of mine have some large networks made with tinc and they are exchanging and maintaining root CAs

  3. TheCoffeMaker

    moparisthebest: It would be great, this can also be applied to other VPNs ... Some friend of mine have some large networks made with tinc and they are exchanging and maintaining root CAs

  4. moparisthebest

    I think in other places where transport security and authentication isn't guaranteed like it is with .onion sharing a CA is the right thing to do and just works

  5. TheCoffeMaker

    Yes, but is hard to maintain updated and coordinated

  6. moparisthebest

    MattJ, I vaguely recall you mentioning you didn't like the SRV weight algorithm and did something else?

  7. MattJ

    moparisthebest: I don't like it, but I didn't do much else

  8. MattJ

    I have a patch for Prosody I'm sitting on for now (needs further testing)

  9. moparisthebest

    MattJ: what did you do differently and/or care to share the code?

  10. MattJ

    https://matthewwild.co.uk/uploads/prosody-srv-weighting.diff

  11. MattJ

    IIRC I'm following the RFC pretty closely with this implementation. My main complaint is the inefficiency of it, but every optimization suggested so far hasn't produced the same outputs as the RFC would in every case

  12. MattJ

    We did discuss putting a limit on the number of records we would attempt to process

  13. mjk

    moparisthebest: > Any thoughts on best practices re: .onion XMPP servers? I'm planning on actually writing this down in a xep > ::: Mentioning http client behavior would be nice as well, I think. As in, allow any cert. Btw, relaxing the requirement to do specifically TLS in the http upload xep (instead, only require _some_ equivalently secure form of transport security) would be nice as well, but oos, it seems :)

  14. mjk

    emus: > i want to occasionally post about e.g. new XEPs > "XEP-1234 has been proposed! > Short description > Author" > Image ^ May I suggest adding to this info the essential effects of the xep addition/change for end users? ("Products, not protocols", etc.)

  15. emus

    mjk: Well, XSF is protocols

  16. emus

    and its not that I will post this very frequentlt

  17. mjk

    Well yeah, what I suggest is more like "products + protocols", so that non-tech audience isn't completely left out

  18. Link Mauve

    “22:13:08 moparisthebest> writing specs is annoying, writing code is fun...”, absolutely completely untrue!!!

  19. jonas’

    +1

  20. Zash

    producolts

  21. Ge0rG

    writing code is fun. Debugging code... less so

  22. mjk

    Debugging specs that has no running code is...

  23. Ge0rG

    mjk: ...a hobby of mine

  24. Ge0rG

    finding underspecified parts and race conditions just from reading the text and thinking "what might go wrong" is exciting

  25. mjk

    Right... Exciting... /me still healing the trauma of running a mathy algorithm partly in head, partly on paper because printf would be too verbose

  26. mjk

    Or too much effort writing the formatting code

  27. jonas’

    .oO(#[derive(Debug)])

  28. mjk

    jonas’: Is that some Wolfram vodoo?

  29. mjk

    jonas’: Is that some Wolfram voodoo?

  30. jonas’

    no, rust

  31. mjk

    Oh

  32. jonas’

    applied to a struct, it generates the code necessary to use it with the {:?} placeholder, dumping all of its contents.

  33. jonas’

    applied to a struct, enum or tuple declaration, it generates the code necessary to use it with the {:?} placeholder, dumping all of its contents.

  34. emus

    Again said I tend to troll without intention^^

  35. emus

    This what I want (example) as a tweet:

  36. mjk

    jonas’: Ah, I thought it processes a function to generate debugging instrumentation :)) But there are debuggers for that, I guess. In my case I was lazy to research step-by-step debugging of Lua, _and_ wanted to visualze the data in a fancy manner...

  37. emus

    A new XEP has been proposed *XEP-0461: Message Replies* *Abstract* This document defines a way to indicate that a message is a reply to a previous message. *Authors* Natalie WirthMarvin Wissfeld https://xmpp.org/extensions/xep-0461.html

  38. emus

    https://jabbers.one:5281/upload/F4f6DxRCgcfJMNN5/20220310_221533585_7bc5.png

  39. emus

    now I killed the discussion? 😅

  40. mjk

    Or it's just _that_ perfect that nobody has anything to sdd ;p

  41. mjk

    Or it's just _that_ perfect that nobody has anything to add ;p

  42. emus

    Ah cool - I just go ahead 🎉😉

  43. emus

    But I hope its clear what I wanted to discuss. I think I spread some confusion

  44. mjk

    But I have! > *Abstract* > This document defines a way to indicate that a message is a reply to a previous message. "(Allows clients to have nice quotation UI.)". or something

  45. mjk

    But I have! > *Abstract* > This document defines a way to indicate that a message is a reply to a previous message. "(Allows clients to have nice quotation UI.)" or something

  46. emus

    That is also fine to restate the abstract for non-techs

  47. mjk nods

  48. emus

    I always wou'd like to start saying: > This specification standardizes ...

  49. emus

    I always would like to start saying: > This specification standardizes ...

  50. emus

    because this is key. It works for "everyone"

  51. Ge0rG

    Isn't every standard specification meant to standardize something?

  52. Ge0rG

    State the obvious with too many words, lose readers on the way

  53. msavoritias

    But maybe it helps devs from othes ecosystems realize how more democratic things work around here ;)

  54. Ge0rG

    Doing this right is really hard, maybe we should hire a competent technical writer.

  55. emus

    > Ge0rG escribió: > State the obvious with too many words, lose readers on the way I think it clarifies that this was the intention. Noone has officially standardises this yet, we do

  56. emus

    And also said: Yes, and we standardized THIS

  57. emus

    I will move this to editors muc

  58. moparisthebest

    mjk: good call about specifically documenting https behavior on onions too

  59. moparisthebest

    MattJ: thanks I'll have a look, fwiw I don't think producing the same output as the SRV RFC is that valuable, vs just maximizing connection attempts

  60. emus

    guus, just ignore

  61. emus

    @all please remind to set labels if you merge PRs - that would be very helpful

  62. xnamed

    > Thank you Alex! Welcome, Ali! Thank you Guus > Welcome Ali! Thank you emus > Congrats to all, welcome Ali, and thanks for your support! Thank you Neustradamus Thank you all for accepting my application 😊

  63. moparisthebest

    Quick rundown of encrypted client hello https://guardianproject.info/2021/11/30/implementing-tls-encrypted-client-hello/

  64. moparisthebest

    This will allow connecting to XMPP servers while hiding ALPN and SNI

  65. emus

    The circumstance "nobody" care about protocols the posts just crossed the 1700 followers 😌️ https://twitter.com/xmpp/status/1502364409020268544 https://fosstodon.org/web/@xmpp/107939539350756647

  66. Menel

    Wow

  67. emus

    6 retweets in 1 minute at Friday night ^^

  68. emus

    10

  69. moparisthebest

    Not "nobody" just not "normal people"

  70. Zash

    We're all "nobody" here.

  71. moparisthebest

    100% of the people in this channel or that follow that account care :)

  72. emus

    Good --> retweet etc 😉

  73. emus

    Zash - you did already I saw that 🙂 good job!

  74. Zash

    Marketing goes brrrrr

  75. emus

    🕺️

  76. emus

    Lol, we have almost the same retweets as the latest newsletter ^^

  77. emus

    on Fost.

  78. moparisthebest

    https://burtrum.org/up/34510860-cae4-467d-811f-5e16d01f9e71/9wqjWU9CQtKgpDow7mfH8Q.jpg

  79. moparisthebest

    The way husky crops that image is... Less than ideal lol

  80. emus

    Its all weirdly cropped. I made a better version already for the next time

  81. Zash

    P SPEC

  82. Zash

    https://cerdale.zash.se/s/T7K4K8gd8cZn3k6Lp0hR5PTz/0e2e3788-89a5-44ba-bd5e-9a41a189f57f.png

  83. moparisthebest

    Looks fine in mobile Firefox:

  84. moparisthebest

    https://burtrum.org/up/60b68a4f-0890-4ca9-bb4a-8275a536130a/yiLtel7ASnuC91V1Ga5x5A.jpg

  85. emus

    Guys, I raised this today and yesterday several times, but apart from almost 95% offtopic comments nothing, so please come with proposals next time -.-

  86. Zash

    https://cerdale.zash.se/s/G1gOfXkSfZ8BIuWyMYvilWlQ/25c1c82f-f6cc-40b7-a8e7-1c4af01d1036.png

  87. emus

    The last link is what I intended

  88. moparisthebest

    This kind of thing makes me so glad I'm not a UI developer

  89. emus

    from morap

  90. Zash

    emus, it's late on a friday, feel free to ignore everything until tomorrow 😉

  91. emus

    Yes^^

  92. moparisthebest

    To be clear I don't think there is anything you could do about this

  93. emus

    I can

  94. emus

    https://jabbers.one:5281/upload/Z32YMVzVzhVlVHKa/bd4445f3-603e-4550-90a8-c8ad2af8dfdd.png

  95. Zash

    Isn't there some optimal resolution documented somewhere?

  96. moparisthebest

    Nifty

  97. emus

    larma said I should ask for some volunteers on corporate design. So please go crazy. But I would like to keep it in its own design (thats why I made it grey mode)

  98. emus

    MattJ, no that I disagree with your "products, not protocols" - but I see lots of retoots already ;)

  99. larma

    https://larma.de:5281/upload/ph8N3K_FGl-sNAQw/852eb62e-2bf2-4e2f-a643-5ca8a175b8c8.png

  100. larma

    So apparently, they should be 16:9

  101. emus

    but what happens if I remove this?

  102. emus

    is it then native?

  103. larma

    this is a display setting, it doesn't affect what is send

  104. emus

    oh yes

  105. emus

    I was already amused

  106. larma

    and it's enabled by default, so most users will have it enabled

  107. emus

    yeah

  108. larma

    thus you should assume things to be cropped 16:9, and thus best way to make sure it looks good is to also send 16:9 😉

  109. emus

    Yes, I just cropped it accordingly

  110. mjk

    > https://cerdale.zash.se/s/G1gOfXkSfZ8BIuWyMYvilWlQ/25c1c82f-f6cc-40b7-a8e7-1c4af01d1036.png The specificat appurroves

  111. emus

    ...

  112. moparisthebest

    Interesting https://prav.app/ cc Daniel , also maybe newsletter material?