XSF Discussion - 2024-02-14

  1. moparisthebest

    dwd, MSavoritias fae.ve , responded to your host-meta-2 feedback on the mailing list after way too long, thanks much for doing that!

  2. larma

    moparisthebest: I don't think your assessment that popular HTTPS/WS libraries don't support being a domain fronting client is particularly true. I know that node.js `https` module in the standard library does support it as well as the popular `ws` module. (I only know that because I once needed to use domain fronting to bypass a certain very restrictive firewall with only what I had on the machine at the time and conveniently nodejs was installed)

  3. dwd

    Also, as I'll shortly say on the list, the HTTPS/SVCB-for-https records both require this, as does RFC 9641 (SVCB-for-DNS) in the DoH case, so i think we're swimming with the current here.

  4. Stefan

    profanity has a plain text logging and a database. Logging can be disabled, db not. Due to 'modern' chat features clients may need db to support those.

  5. Stefan

    Correction: /privacy logging off may also disable db logging.

  6. nicoco

    https://github.com/xsf/xeps/pull/1271 (update of XEP-0425 (moderation) to remove dependency on fastening) uses the `urn:xmpp:message-retract:0` namespace. Since XEP-0424 has been updated and now uses `urn:xmpp:message-retract:1`, shouldn't we update the PR before merging? ping jcbrand

  7. singpolyma

    I'm not really sure why the "retract" is in there at all

  8. singpolyma

    nicoco: looking at the diff it looks like it is using :1 in that pr?

  9. nicoco

    oh right, just missing one update in the examples: https://github.com/xsf/xeps/pull/1271/files#diff-51a64a03fe3956a5dc05adee148d0d003bd3639b4877cbe40fdff2ccf368807aR160

  10. Schimon


  11. Schimon

    I am working on ad-hoc commands and forms.

  12. Schimon

    I was wondering if there are forms of "Select file...". Are there forms of that type?

  13. Schimon

    My use case: Importing data to an XMPP App (i.e. XMPP Bot) 1) Select file; 2) Upload file (i.e. XEP-0363); 3) Bot downloads file and process it. The bot already does both #2 and #3 when sending it a URL. #1 is missing for convenience while using ad-hoc command forms.

  14. fjklp

    is there a preferred term to refer to the list within a client of all the users present within a group chat?

  15. fjklp

    And, is there a preferred term to refer to a user within a chat? Such as user, participant, occupant, etc.?

  16. MattJ

    fjklp: participant: https://docs.modernxmpp.org/terminology/

  17. MattJ

    This is for user-facing terminology, "participant" has a specific meaning at the protocol level

  18. fjklp

    thanks. The need to know if advance that it was historically 'Occupant' is a bit of an impediment

  19. fjklp

    maybe I'm just lazy :)

  20. fjklp

    ok, so sometimes there will be conflicts between user-facing and protocol terms

  21. fjklp

    unfortunate, at the lest

  22. fjklp

    unfortunate, at the least

  23. MattJ

    fjklp: "occupant" makes sense when the "room" terminology is used

  24. MattJ

    Since a room is a space that can be occupied

  25. MattJ

    ModernXMPP doesn't advocate for that terminology, because it's not what most platforms are using these days so people are unfamiliar with it

  26. singpolyma

    Schimon: here is some thinking about it: field type=text-single validation datatype=xs:anyURI but then you also want some kind of mime-type patterns list for what kind of stuff you're looking for/accepting here. Obviously I wouldn't provide a "file upload" option for just any uri input, but a uri input with a list of mime type patterns feels like maybe enough of a hint? and then can offer eg camera etc depending on the mime types as well of course. so I think we need a new thing for this mime type list maybe

  27. singpolyma

    Something like: ``` <field var="myfile" type="text-single"> <validate xmlns='http://jabber.org/protocol/xdata-validate' datatype='xs:anyURI' /> <accept xmlns="https://example.com/demo-format"><mime>image/*</mime><mime>video/*</mime></accept> </field> ```

  28. moparisthebest

    How do you tell mime type given a URL though...

  29. moparisthebest

    There are a multiple ways, nearly all of them wrong lol

  30. singpolyma

    moparisthebest: you don't. it's a hint to the client about what mime types are acceptable

  31. moparisthebest

    The thing fetching them needs to be very careful... Otherwise seems ok

  32. Schimon

    This is for importing an OPML file.

  33. Wirlaburla

    Send HEAD request to URL and hope it returns back a Content-Type header.

  34. moparisthebest

    > Send HEAD request to URL and hope it returns back a Content-Type header. Can't count on this, many servers will return ye olde octet-stream

  35. singpolyma

    moparisthebest: are you suggesting that we might want the client to tell the bot what it thinks the mime type of the file is?

  36. Wirlaburla

    That's why I said "hope".

  37. Wirlaburla

    None of the options for finding a mime based on URL will be anywhere near definitive.

  38. Wirlaburla

    If you want to be certain, you'll have to grab the contents.

  39. hook

    Schimon, OK, now I’m quite intrigued at what you’re doing (also lawyer here)

  40. singpolyma

    right, most of the time you can't trust the mime type from the client or the server anyway, you ignore it and just treat it as a bag of bytes. when it comes to file uploads etc anyway

  41. Schimon

    > Send HEAD request to URL and hope it returns back a Content-Type header. Wirlaburla, even if that HEAD request will not be sabotaged (i.e. a deliberate return of http code 404), it might not be possible to know without reading the actual file. (i.e. some Atom/JSON/OPML/RSS pages are sent as HTML pages, even thoughthese are XML files)

  42. singpolyma

    I do like sending that kind of hints with a file transfer to another human, because then their client can display things based on if it expects and image or whatever. but in this case the server/bot kind of alrady knows what it expects

  43. Schimon

    hook, I am working on a news bot, which really should be called XMPP App

  44. moparisthebest

    singpolyma: no, just that: 1. Rejecting files based on file extension is gonna be wrong 2. Rejecting them on mimetype returned by server is gonna be wrong 3. Basically have to download (being wary of all https attacks, unlimited length, massive length, zipbomb, unlimited headers, slowloris etc etc etc) and then super carefully determine validity itself

  45. singpolyma

    moparisthebest: yes, I think that's fine. If this were an HTTP app the file would be uploaded direct

  46. hook

    Schimon, Atom-to-XMPP or more complex?

  47. Schimon

    moparisthebest, good point!

  48. Schimon

    hook, I think more complex

  49. Wirlaburla

    Download and run `file` on it internally and determine how much to trust it based on the response.

  50. singpolyma

    my main reservation with doing this is that it feels like it priviledges http upload, but I've never thought of a good way for tying jingle-push into a form, you could have it in ad-hoc if one step was just a file upload and nothing else, but it's nice to have it as part of a form.

  51. Schimon

    hook, it is a news bot that is intended to habdle multiple JIDs at the same time (groupchats and chats). You can find it at https://gitgud.io/sjehuda/slixfeed

  52. singpolyma

    with my proposed strategy you could still use a uri to a hash to indicate "fetch from me over jingle" based on ambient caps knowledge

  53. hook

    Schimon, cool, thanks πŸ™‚

  54. Schimon

    You are welcome

  55. Schimon

    We have a groupchat too, for testing and asking feature requests etc.

  56. singpolyma

    Schimon: if we went with something like my proposal above, then the fallback behavior in clients not supporting it would be a text box to paste a URL into

  57. Schimon

    This is great. I like the idea!

  58. singpolyma

    Ok. Barring a better idea ocurring I can probably prototype something soon and we'll see how it goes. This one feels worthy of a xep if it works out

  59. moparisthebest

    I was about to say a normal user doesn't know what a URL is but I guess they also don't know what RSS is so it's ok 😁

  60. Schimon

    I think I have found an issue with Cheogram. 1) Import OPML 2) Enter "abcd" (not begining with http and not enging with opml) 3) Form of type note *has* "next" and "cancel". 4) Clicking on next will lead to error in slixmpp. singpolyma

  61. Schimon

    Or I should set session['has next'] = False

  62. Schimon

    > 3) Form of type note *has* "next" and "cancel". Correction "cancel" and "finish" and "finish" will lead to error with slixmpp.

  63. Schimon

    Setting session['has next'] = False session['next'] = False solve this, but Cheogram still shows buttons. I will update the repository so you get to see this.

  64. singpolyma

    Schimon: ok, yeah, push what you have and I'll look

  65. singpolyma

    moparisthebest: occasionally they know what a "link" is, but yes obviously this is why we want a file upload ui

    πŸ‘ 1
  66. moparisthebest

    > moparisthebest: occasionally they know what a "link" is, but yes obviously this is why we want a file upload ui πŸ‘