XSF Discussion - 2023-01-27

@board as per council vote from December 14th I'm the new board liason (we decided to make chair == liason again) Can I be put on the board mailing list please?

ralphm, MattJ, arc, stpeter:

Yes, yes, I saw, we'll get to it 🙂

I can do it after 9am if nobody else gets there first

> MattJ: > 2023-01-27 08:59 (GMT+01:00) > I can do it after 9am if nobody else gets there first please, as I dont know the processing here

With HTTP File Upload, is there a way to synchronize uploaded data between domains? It's not hard to imagine having a scenario where users on a federated domain have a better network connection to their local servers, as compared to the server where the upload initially happened.

I'm not sure what you mean by "synchronize uploaded data between domains", but there is no requirement for the upload server and the XMPP server to be the same

Ah, you mean for recipients to download from a different (more local) server

exactly.

Would require rewriting the users message in the MUC too, no?

My unrealized plan for that is to have the XMPP server advertise a HTTP proxy via XEP-0215

This also has privacy benefits (not leaking the recipient's client IP to the sender)

That could work, yes. Thanks.

If you work on it, it would be great to make a brief XEP so we can get it more widely implemented :)

I don't plan to anytime soon.

OT: In hour remote happy hour today I presented XMPP as technology to my team at work. Many young folks there and I think it catched their interest 👍

emus, nice, well done!

They were asking how we could use it in the company (engineering consulting). I told some applications from IoT and the pblished papers, but had a real clue. I said its good to know it exist and spread the word if people do evaluations.

yeah, a http proxy announced via XEP-0215 would be really good, this will stop leaking IP addresses to some "random" server hosting http uploads aka xmpp filetransfers...

Download and rewrite is also possible but only when no e2ee

Can't clients use TURN to download https files?

Uh, with HTTP/3 maybe, but most often it's UDP only.

TURN does TCP and TLS doesn't it?

It's up to each deployment afaik.

Hmm does this work https://github.com/staaldraad/turner

Yep this has to be where I read it https://www.rtcsec.com/article/slack-webrtc-turn-compromise-and-bug-bounty/

So XMPP servers don't need to do anything more, clients just need to start using the TURN server as an http proxy :)

But now you have *two* servers and a longer network path where where problems can occur. Wasn't Guus after a way to improve reliability? Hence, you'd probably want a caching HTTP proxy, not a TCP proxy.

Two servers and same network path either way, but yea this wouldn't support caching

The advantage being it's more private, you could download e2e files this way without revealing the path, or even domain name with ECH (you'd still reveal IP and port though)

Using TURN may be slightly less efficient if there's a big number of users compared to a local proxy, but then hosters may prefer not to store more things on their server than they need to (space, moderation, etc.)

But yeah local proxy may not work for e2ee, or it'd have to be requested by the user

OTOH, in say a public MUC, it'd be nice to cache and rewrite URLs to obscure the original senders address. ✏

I'd like it if it were hosted by the MUC, as it's all data the MUC already has. Except e2ee.., and same questions about moderation etc. ✏

Yeah, public vs private chats have different requirements.

Zash, yeah, I agree. Exposing my http-upload domain has bothered me in public MUCs that otherwise don't expose my JID to participants

I have designs on a caching module for this sort of thing. Maybe this year

>Maybe this year™️

Fixed it :)

Heh

> Zash, yeah, I agree. Exposing my http-upload domain has bothered me in public MUCs that otherwise don't expose my JID to participants I mean nothing stops your client from uploading to anywhere, ipfs, imgur, whatever, and sending it like an http upload message

Can we get starting hours of the summit? at least on the first day? or is that something still undecided?

Don't Worry About It™

moparisthebest, true

I guess I should look at the XEP, but now I'm wondering if multiple URLs are supported. e.g. native ipfs:// and via an http gateway

jackhill: not with oob, but with SIMS yes

Note that all content on ipfs is public, though I guess in the context of public MUC that's what you want anyway

I see. A nice thing about using ones own domain, or the MUC domain, or something distributed like IPFS is not depending on a single 3rd party with no connection to the conversation.

Andrzej: we've started at 10am in previous years. Which sounds like a good time

I assume most http-uploaded content is public as well.

jackhill: sort of. It's on a secret URL

IPFS content gets announced

But Board members who have seen the paper work for the conference room might want to see if we have the room at this time

Daniel, I know but this year we have a different venue and there is nothing in the wiki so I wanted to confirm

We have the room 9am-5pm

I think people trickling in from 9am with the goal being a proper start at 10am would be sensible

We might want to use that time to figure out and set up remote a/v (if we even attempt this)

Indeed. I will in any case bring a camera. We also should have a video projector in the room.

What kind of camera?

Maybe we can move to summit@ and discuss logistics

A Razer Kiyo Pro, which is a web cam, but should be pretty decent for this.

sure