XSF Discussion - 2023-03-30

  1. MSavoritias (fae,ve)

    Me too

  2. MattJ

    Hi folk, update from iteam: The mail/DNS server is still down, and we've confirmed it's due to a hardware failure and not simply network issues. DNS should be working fine served from our secondary DNS servers (thanks intosi!). The mailing lists will be down for a while longer as we work on setting up a new server and restoring backups. We'll keep everyone posted.

  3. flow

    thanks for working on this everyone :)

  4. emus

    > Peter Waher: > 2023-03-29 06:07 (GMT+02:00) > In May of 2014 (soon 9 years ago) I made a study of the differences (strengths/weaknesses) between XMPP and MQTT, and tried to create interest to improve XMPP with extensions of things lacking in XMPP, but that existed in MQTT. (This includes Quality of Service and queue-ing, for instance, but also other adjacent areas. Let me know if anyone is interested in reading results.) Interest was low from the XSF group, which focused(-s) mainly on IM, rather than viewing XMPP as a more generic transport protocol for multiple use cases (other than IM). (Interest is/was higher in other groups, who wish to stay more agnostic to overlying use cases). feel free to add it to the pad i shared recentlt

  5. emus

    > pep.: > 2023-03-29 06:09 (GMT+02:00) > That's what I've always found sad about the XSF :( I share this to the level that folks could / should work& agree on certain general targets

  6. emus

    > stpeter: > 2023-03-29 08:49 (GMT+02:00) > @emus I’ve created https://wiki.xmpp.org/web/Board-Meeting-2023-04-05 - you and others should feel free to edit it. peter, there was one created by me already with XX as dates :-/

  7. emus

    Many thanks again to wurstsalat getting us a decent overview of the structure: https://xmpp.org/about/xmpp-standards-foundation/ I would recommend to ask everyone to review their role and step back if they have no contributions. it does not make sense to list "stale" persons. we should rather advertise to find others helping then.

  8. Seve

    Looks fantastic on mobile!

  9. emus

    stpeter, updated. maybe lets delete the old one

  10. emus

    Seve: 🍭 its based on the effort I started here a while ago: https://github.com/xsf/xmpp.org/issues/920 if you have more suggestions listing let us know via an issue

  11. Seve

    Subscribed, will check!

  12. emus


  13. nicola

    Great work @wurstsalat for the website

  14. wurstsalat


  15. emus

    We are soon finalizing our next newsletter release. Last late call to add your news: https://pad.nixnet.services/oHnY_ZvLT8SoFyCqIC2ung PRs prefered!

  16. emus

    Another thing I wasn't sure if announced really: https://xmpp.org/software/software-comparison/ one can cross-compare the clients, servers etc doaps now and thanks again to wurstsalat!

  17. Nepptün

    Hi compadres, I have a idea, and I want to with you about it. A lot of rooms (mucs) use other languages then English, and the xmpp stanzas have a part like "xml:lang" could we place in there the language of the muc and/or to make a possibility that a user who want to talk in a different language in the muc to setup his language. This could open the door for translator implementations when in a room somebody not speaking the language of the room could use a translator plugin.

  18. MattJ

    Yes, the protocol already supports language tags on MUCs and language tags on messages

  19. MattJ

    If you want translator plugins, clients would just have to implement that

  20. Peter Waher

    Technically, it would be possible to add a MUC extension that translates messages to desired language

  21. Peter Waher

    regardless of input language

  22. Peter Waher

    and do it on the server

  23. Nepptün

    Peter Waher, that is exactly what I want and to make it more easy, the clients could trasmit in the xml:lang attribute the language they are talking in

  24. Nepptün

    for example I am german, I enter a english room with translation, I could settup my xml:lang="de" so all I write will be translated to english to the room and the server translates me all messages to german

  25. MSavoritias (fae,ve)

    Sounds like a great idea

  26. MSavoritias (fae,ve)

    For both the muc and messages

  27. Nepptün

    there is for example libretranslate .. it has a api

  28. Peter Waher

    choice of library would be implementation-specific

  29. Nepptün

    it works perfect, and it is fast like hell.

  30. Nepptün

    I offer 200 Euro as a donation for somebody who writes such a prosody module that uses the libretranslate api.

  31. Nepptün

    > regardless of input language it must not be regardless, it should only translate for the user who have setup another language then the official room language in their message stanzas. But I think it can be configuration issue if everything or just foreign languages

  32. mdosch

    You'd also need client support. Most clients just hardcore XML lang to en… 🙄

  33. Nepptün

    yes it would be super comfortable to have a select button near the input to select the language the server should translate the messages to you

  34. singpolyma

    Should be based on UI language or system language I expect

  35. mdosch

    Not really, I have my system set to German, but I'd prefer to write in english for english MUCs rather than using a translator.

  36. Peter Waher

    A good translator API would allow you to detect language (now if you’re going to use a languate translation API that is)

  37. mdosch

    It may use system language as default until you manually set avlanguage for that MUC.

  38. Peter Waher

    Annotation using xml:lang can be very misleading, as you’ve pointed out

  39. Nepptün

    I could imagine that the server does nothing until a client demands "translate to me in german" by setting up the xml:lang attribute

  40. Peter Waher

    you have 1 sender, and 1 receiver

  41. Peter Waher

    you might want (as a receiver) to get translated text. But the sender might be completely unaware of all these features, and might also have xml:lang set to en by default

  42. Peter Waher

    Now, if you want that scenario to work, server needs to be able to identify language

  43. Peter Waher

    modern translation APIs support detection of language however

  44. Nepptün

    they have. libretranslate has language detection https://translate.zp1.net/?source=auto&target=de

  45. Menel

    Then it could be a compleatly client side feature without any changes to what servers and clients do currently

  46. Menel

    Sound like likely clients would be gajim or pidgin with their endless plugins

  47. Nepptün

    sure it could be, but i think that as a server module it would have a certain elegance and servitude. you write in your language, we take care.

  48. Nepptün

    the other aspect is that as a server module it would be the work done only once. and client side there are some strange clients like the thunderbird client who don't support plugins.

  49. Nepptün

    or on a phone ... some apis need api keys, and that is not DAU friendly. server solution is more elegant.

  50. Nepptün

    and if a client dont like the server translation nobody stop you to use a client solution.

  51. moparisthebest

    APIs are stupid and not privacy friendly, do it locally or not at all imho

  52. moparisthebest

    https://blog.mozilla.org/en/mozilla/local-translation-add-on-project-bergamot/ is just one example

  53. Nepptün

    yes true. its called a local api ..

  54. Nepptün

    it is very easy to install libretranslate locally next to the server and then you can let them communicate on localhost or on socket. and libretranslte is a offline translator.

  55. Nepptün

    As i said i am not rich, but i would donate 200 buks to the one or to the group that writes such a module.