XMPP Council - 2024-06-17


  1. singpolyma

    daniel: submitting to inbox https://github.com/xsf/xeps/pull/1349 -- been awhile since I did this, hopefully I got it right

  2. moparisthebest

    exciting

  3. moparisthebest marks it down for some late night reading

  4. emus

    nice!

  5. larma

    > daniel: submitting to inbox https://github.com/xsf/xeps/pull/1349 -- been awhile since I did this, hopefully I got it right Thanks for writing it down. Do you also plan to specify other WebXDC features (selfAddr/selfName and realtime channel)?

  6. moparisthebest

    Also would you be able to easily host/upload a rendered version? No big deal either way

  7. larma

    Also the specification says for the `update.info` property: "implementations will truncate the text at about 50 characters or less. If there are series of info messages, older ones may be dropped." I don't see those remarks represented in the ProtoXEP

  8. singpolyma

    selfAddr/selfName doesn't affect the protocol at all, that's just javascript-side stuff. realtime channel will be specced once it's stable yes, I'm in discussion with them about that

  9. singpolyma

    moparisthebest: https://cheogram.com/xeps/webxdc.html

  10. larma

    singpolyma: don't you need to specify what to put in selfAddr/selfName? I know it's read from the JS, but the XMPP client that executes the xdc is the one to set those, no?

  11. singpolyma

    Well, the WebXDC spec specifies what to put there already. I don't know that we need to re-specify everything from them, just our parts yeah?

  12. larma

    but what is selfAddr then? The full JID? the bare JID? the bare JID's URI?

  13. singpolyma

    It is any string that is unique to the user and always the same when opening the same widget. So could be jid, or hmac(jid,widgetkey) or anything else you like

  14. singpolyma

    In a muc occupant ID could be a useful one. But if two different clients use different things it doesn't matter, so long as they are consistent it's just an id