XMPP Service Operators - 2021-04-07

  1. Martin

    Establishing a secure connection from mdosch.de to jabber.org failed. Certificate hash: 28096cffe62c8866db75947bb820003c201ce2c9c9fe03dad19d3e2cbaa7943a. Error with certificate 0: certificate has expired.

  2. christian

    Martin: i can confirm

  3. tom

    for http-upload, does the resultant URL have to be known before the file is uploaded, or can I tell the XMPP client the URL after it's been uploaded to the webserver

  4. tom

    I'd like to have the file url be resultant upon the hash of the file

  5. tom

    for implementing a distributed content-addressable object store

  6. jonas’

    tom, https://xmpp.org/extensions/xep-0363.html#example-6

  7. jonas’

    > The upload service responds with both a PUT and a GET URL wrapped by a <slot> element. The service SHOULD keep the file name and especially the file ending intact. Using the same hostname for PUT and GET is OPTIONAL. The host MUST provide Transport Layer Security (RFC 5246 [11]). Both HTTPS URLs MUST adhere to RFC 3986 [12]. Non ASCII characters MUST be percent-encoded.

  8. jonas’

    so the GET URL needs to be known before the upload has completed

  9. tom


  10. tom

    the sucks

  11. tom

    that's for confirming

  12. tom

    do you think it's practical if I could sumbit a proposed change to the spec

  13. tom

    and people would actually implement it?

  14. jonas’

    a bit late for that

  15. jonas’

    it was confirmed in the state it is on february 2020

  16. jonas’

    minor changes are possible, but you can’t remove <get/> in there

  17. jonas’

    minor changes are possible, but you can’t remove the requirement for the <get/> in there

  18. jonas’

    I mean, you can propose it, but I’d estimate your chances are slim...

  19. Licaon_Kter

    tom: > for implementing a distributed content-addressable object store Won't that be useless for encrypted files?

  20. jonas’

    oh indeed

  21. tom

    well I'd really like to use IPFS urls for that

  22. tom

    so if people are still interested in a file past the cleanup purge time the file can be accessed

  23. tom

    it also helps people in low-bandwidth situations, or people in russia who have ip censorship

  24. tom

    who haven't been able to access my cdn

  25. tom

    i don't see why i'd be useless for encrypted files

  26. Licaon_Kter

    tom: hash is always different, your CDN is not hit

  27. tom

    that's the point

  28. tom

    I'd like to make connecting to my CDN not needed

  29. tom

    instead a local IPFS daemon could be used

  30. tom

    that also makes large uploads instant

  31. tom

    so they don't lag behind a conversation

  32. tom

    instead, someone could publish content to ipfs and share a IPFS url, seed the content in realtime

  33. tom

    from their own computer

  34. jonas’

    it seems to me that you don’t need to use http upload at all then

  35. jonas’

    looks like you just want to stuff an IPFS URL somewhere

  36. mjk

    > looks like you just want to stuff an IPFS URL somewhere Somewhere like xep-0447

  37. tom


  38. tom

    can multiple <url-data> sources be supplied?

  39. tom

    ipfs:// and then fallback to an http gateway

  40. mjk

    tom: certainly

  41. xorman

    ipfs for uploads would be awesome