XMPP Service Operators - 2021-04-07

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

Martin: i can confirm

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

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

for implementing a distributed content-addressable object store

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

> 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.

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

damn

the sucks

that's for confirming

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

and people would actually implement it?

a bit late for that

it was confirmed in the state it is on february 2020

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

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

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

oh indeed

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

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

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

who haven't been able to access my cdn

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

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

that's the point

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

instead a local IPFS daemon could be used

that also makes large uploads instant

so they don't lag behind a conversation

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

from their own computer

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

looks like you just want to stuff an IPFS URL somewhere

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

hmm

can multiple <url-data> sources be supplied?

ipfs:// and then fallback to an http gateway

tom: certainly

ipfs for uploads would be awesome