jdev - 2024-06-23


  1. jjj333_p (any pronouns)

    heya, im considering working on making an xmpp client and im still tossing around which language to use

  2. jjj333_p (any pronouns)

    im absolutely unwilling to use python, but not much else is ruled out

  3. jjj333_p (any pronouns)

    i hear smack is great, but i hear horror stories about javafx.

  4. jjj333_p (any pronouns)

    go would let me use my favorite gui lib but go-xmpp seems to still be in beta

  5. jjj333_p (any pronouns)

    qxmpp (c++) seems good but c++ and qt is rough

  6. jjj333_p (any pronouns)

    im also open to js but i dont see any good libaries for it

  7. lovetox

    i would not give the library too much weight in your decision

  8. lovetox

    for me in a xmpp library the whole network stuff, parsing / serializing xml needs to be locked down, you dont want to get into this really

  9. lovetox

    but there are a million of XEP extensions, and if they are in the lib or not is really not that important, because its often trivial to add them

  10. jjj333_p (any pronouns)

    hmmm alright

  11. taba

    jjj333_p (any pronouns): contribute to existing clients

  12. lovetox

    so if you like go, and you feel the GUI library can solve all problems which will come up, simply contributing to go-xmpp the bits you need down the line, seems a good decision for me

    👍 1
  13. jjj333_p (any pronouns)

    > jjj333_p (any pronouns): contribute to existing clients the main reason i lean away from this i have a very specific idea of what im going for. also i just wanna try it as a dumb personal project 🤷‍♂️

  14. lovetox

    > the main reason i lean away from this i have a very specific idea of what im going for. also i just wanna try it as a dumb personal project 🤷‍♂️ someone asked me this a week ago, what they have to expect when they write a client, and my answer was definitly expect > 50% writing GUI code

  15. jjj333_p (any pronouns)

    > someone asked me this a week ago, what they have to expect when they write a client, and my answer was definitly expect > 50% writing GUI code i know that person you talked to

  16. jjj333_p (any pronouns)

    and they passed that on to me

  17. lovetox

    if designing GUI stuff is not your thing, then this will be not a very successufl side project

  18. lovetox

    ah :D

  19. jjj333_p (any pronouns)

    > if designing GUI stuff is not your thing, then this will be not a very successufl side project the gui is while not my expertice (very little is my expertice) its the crux of why i want to try to make something new

  20. jjj333_p (any pronouns)

    so im very aware that the gui will be 50% or more of the battle, just on general principles

  21. jjj333_p (any pronouns)

    its very easy to make something functional. its very hard to make something someone actually wishes to use

  22. jjj333_p (any pronouns)

    anyways tysm for your input

  23. lovetox

    another thing that comes to mind which could factor into the language is, what tooling is available to distribute

  24. lovetox

    because thats one important thing, that your users can easily install the stuff and get it working

  25. jjj333_p (any pronouns)

    yeah, agreed

  26. jjj333_p (any pronouns)

    tbh thats one of the things that leans me towards go, its relatively easy to support all platforms you just have to compile it for each one (theres frameworks to support ios and android)

  27. lovetox

    ah i didnt ask this, so you want to do a mobile client?

  28. jjj333_p (any pronouns)

    not initially, but the plan is to eventually port to mobile

  29. jjj333_p (any pronouns)

    im starting on desktop while i get the hang of things

  30. jjj333_p (any pronouns)

    specifically targeting my own usecase first 😅

  31. lovetox

    and the go-gui lib you told us supports that explictly, because i think the toolkit would need to have special functionality "css like" where stuff resizes and reorders on different screensizes

  32. lovetox

    otherwise you end up writing 2 GUIs :D

  33. jjj333_p (any pronouns)

    im using fyne, which is exactly like that

  34. jjj333_p (any pronouns)

    ive used it before, it actually intentionally doesnt allow any kind of absolute positioning or anything

  35. jjj333_p (any pronouns)

    youre supposed to just put things into containing layout widgets and let the library figure it out

  36. jjj333_p (any pronouns)

    > im using fyne, which is exactly like that planning to use*

  37. lovetox

    yeah just checked out the website, its seems at least a prime goal of the lib

  38. jjj333_p (any pronouns)

    its also supposed to (id assume within desktop os-es) if it works on one it will work on any other os/arch "blindly"

  39. jjj333_p (any pronouns)

    its also supposed to (id assume within desktop os-es, not like within everything) if it works on one it will work on any other os/arch "blindly"

  40. jjj333_p (any pronouns)

    obviously its worth testing a little bit but yeah the main emphasis of both go and fyne seems to be cross platform compatibility

  41. singpolyma

    jjj333_p (any pronouns): if the main thing you're interested in is making a new UI experience and not in re-implementing all the protocol bits for the 800th time, the snikket SDK is getting to a usable level and I'm working to make it more so quite actively. I'm building a web client with it, but I've also built a simple cli client with it (only for calls). Current official bindings support is JavaScript, C, Haxe, and Swift. I want to add official rust soon. Other things I'm open to or you could wrap the C manually etc. The library handles MAM sync and storage, avatar and nickname fetches, bookmarks and roster, jingle negotiation for calls, and probably I'll add anything it's missing. No OMEMO in the library yet for example but that's planned for soon

  42. jjj333_p (any pronouns)

    > jjj333_p (any pronouns): if the main thing you're interested in is making a new UI experience and not in re-implementing all the protocol bits for the 800th time, the snikket SDK is getting to a usable level and I'm working to make it more so quite actively. I'm building a web client with it, but I've also built a simple cli client with it (only for calls). Current official bindings support is JavaScript, C, Haxe, and Swift. I want to add official rust soon. Other things I'm open to or you could wrap the C manually etc. The library handles MAM sync and storage, avatar and nickname fetches, bookmarks and roster, jingle negotiation for calls, and probably I'll add anything it's missing. No OMEMO in the library yet for example but that's planned for soon hm i dont see much reason to use it over something already existing (like go-xmpp) but ill keep it floating around

  43. singpolyma

    The reason is just if you're interested in re-implementing all those things yourself or not. A low level library like go-xmpp won't implement those concepts and in fact the snikket SDK uses those kind of libraries underneath. What it adds is the high level stuff (like mam sync and storage, etc)

  44. singpolyma

    The goal is to make it so a person can write a very good xmpp client without even knowing xeps exist or what the protocol looks like at all

  45. jjj333_p (any pronouns)

    mmm, yeah no i need some exposure to that, because i plan to ~ab~use pubsub and stuff for maybe something like stories, and several other things

  46. singpolyma

    That's good feedback thanks. I'll consider what we can do for pubsub on the roadmap, right now we only expose it for avatar but that could change

  47. singpolyma

    I've also considered if we want to have a minor escape hatch for people who do want to experiment with protocol stuff but don't want to contribute directly to the sdk

  48. moparisthebest

    jjj333_p (any pronouns): xmpp-rs is a good general purpose library that you might find too high level but you can just use certain parts, xmpp-proxy for only the bare minimum networking part, bring your own XML parser

  49. moparisthebest

    If history is anything go by, and your client becomes sufficiently complicated, you'll end up with your own library for it anyway https://www.moparisthebest.com/images/xmpp-client-devs.jpg

  50. singpolyma

    Most clients don't use any library at all but that's because they're all built by protocol tinkerers heh 🙂

  51. jjj333_p (any pronouns)

    > If history is anything go by, and your client becomes sufficiently complicated, you'll end up with your own library for it anyway https://www.moparisthebest.com/images/xmpp-client-devs.jpg fair enough

  52. jjj333_p (any pronouns)

    was talking to a friend, he said that he would prioritize using a library which allows easy stanza manipulation as it can be made effectively completely compliant. it looks like go-xmpp does this

  53. jjj333_p (any pronouns)

    > jjj333_p (any pronouns): xmpp-rs is a good general purpose library that you might find too high level but you can just use certain parts, xmpp-proxy for only the bare minimum networking part, bring your own XML parser hmmm. i do have to say that i would not be excited to use rust, and i would either be stuck with egui (ive heard horror storries) or tauri (ive seen the horror stories)

  54. jjj333_p (any pronouns)

    anyone know a muc for https://github.com/FluuxIO/go-xmpp that i can just lurk in?

  55. moparisthebest

    If you want go there is https://github.com/mellium/xmpp and they have a muc

  56. jjj333_p (any pronouns)

    > If you want go there is https://github.com/mellium/xmpp and they have a muc looks concerningly abandoned 🤔

  57. singpolyma

    Definitely not abandoned, what makes it seem that way?

  58. singpolyma

    > was talking to a friend, he said that he would prioritize using a library which allows easy stanza manipulation as it can be made effectively completely compliant. it looks like go-xmpp does this While this is technically true, this is effectively advice to implement everything from scratch yourself. Which is of course an option, but yeah

  59. moparisthebest

    jjj333_p (any pronouns): oh looks like the GitHub is abandoned because they moved to codeberg, my bad

  60. jjj333_p (any pronouns)

    > Definitely not abandoned, what makes it seem that way? only a minor commit within the last 2 years

  61. jjj333_p (any pronouns)

    > jjj333_p (any pronouns): oh looks like the GitHub is abandoned because they moved to codeberg, my bad ive never understood why people prefer the central codeberg instance to github. theyre both centralized

  62. jjj333_p (any pronouns)

    > jjj333_p (any pronouns): oh looks like the GitHub is abandoned because they moved to codeberg, my bad yeah no the codeberg is in the same state

  63. lbocquet

    jjj333_p (any pronouns): It is better to look recent https://github.com/xmppo/go-xmpp

  64. moparisthebest

    /shrug