XSF Discussion - 2018-01-17

Zash, jonasw: you thought xmpp over TLS on https port was bad https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-02

How about take udp DNS request, bas64 it and send it over https, then get answer back the same way :)

moparisthebest: Was that the one with or without JSON?

Zash: without at least, so that's better

DNS over HTTP, finally

So we finally have everything over http on a single port and single tasking OS (in the phone)

IT is progressing

> SamWhited> pluging in a 4k monitor everything on it is tiny, if I make it bigger when I unplug it the bar eats half my screen That's an X issue I believe

zinid: but now we have ALPN to multiplex

Ge0rG, Ports in userspace.

\o/

it’s only a matter of time until ALPN is handled by thekernel

now i'm wondering if iptables can filter based on alpn

Dave Cridland: I might not make it in time for the Council meeting today. I need to relocate 500km between now and 5PM, and my arrival depends on traffic conditions.

s/5PM/1600Z/

But I'll try hard because I want some qualified feedback on user-invite-protoXEP (for which I'm obviously +1)

daniel: you might be able to construct something with BPF and marks.

but kernels are getting less important every day, with the dockerization of our IT infrastructure

you don't need a kernel in SaaS :P

I’d be happy if ip6tables were able to filter on ipv6 neighbour discovery fields, like it can for arp ✏

Yay. Thon rejected my booking because the deadline of the 12th had passed. *facepalm*

Oh, really? :(

Yep.

They've got about a 24hour roundtrip time on emails, so this can only go well for me.

And two of my team's went through fine, when we sent the forms at the same time. Oh, Thon, we love you.

This is the point where I would give them a ring, really.

All we need is IP over http right.

Apparently there is such a thing already. "Microsoft used to discourage IP-HTTPS use because it was slow." duh

can't wait for XMPP over HTTP

wait…

There is tcp over http, called http2

Having now got Thon to honour the block booking rate, they still seem to be silently ripping me off by charging (much) more than the block booking rate anyway.

:/

Kev: I have written confirmation that Thon extended our block booking rate deadline to the 17th (today)

This was offered to us by David Hutsebaut on January 8th, by mail, to me.

I'm also interested in how much they're now charging you.

Actually, looking at the number they're charging me less for the second night, just much more for the third night, so in the end it only ends up being £20 or so difference. I can live with that.

If only somebody would disrupt the hotel business.

what do you want an 'Uber Hotels'

moparisthebest: I thought about a web portal where private people offer rooms or flats to random strangers from the Internet, filming them naked.

isn't there already something that does that, uh, airbnb or something?

moparisthebest: no way!

no, airbnb just gets you spider-infested flats which are half as large as claimed in the ad

jonasw: maybe the difference between sqft and m²?

nah

just fraud

that was pretty clear from the way the photos were and the general state of the flat

But you can rate down the flat!1!

we complained

daniel: as the operator of a public server, I don't want a module to expose user avatars to the general public by loading a "compatibility" module.

> I'm not sure we should be messing with vcard anymore, but we can probably discuss afterwards unless this is critical to someones vote and it can't be done on list? I think there is an argument to be made that vCard will be needed for as long as muc is around

s/a module//

Maybe there are people still using vcard as designed.

Ge0rG, aren’t user avatars factually already open to the general public when they’re stored as vcard?

jonasw: yes.

I'm not really happy about that either but I can't remove MUC from existence

could you run a query which tells you how many users have their avatar *only* in PEP?

jonasw: except that most clients will warn you about your vcard being public

(and how many have their avatar in PEP and vcard?)

> jonasw: except that most clients will warn you about your vcard being public What clients do?

I’d like to have numbers on clients which do *not* warn you and only support PEP.

daniel, conversations? ;-)

jonasw: no

There is the argument that maybe, while vCard is pretty rubbish, it's also good enough.

Ge0rG, because I think that clients are simply neglient about warning users about their o+r avatars.

jonasw: that might be true, but doesn't invalidate my argument.

daniel, I remotely recall that the avatar is visible to everyone, but maybe it was just "to your contacts" :)

Even though, for the record, I *was* surprised to see that my avatar passes through anon MUCs.

I see merit in having a public vcard by opt-in.

jonasw, Conversations had a message saying that pep avatars are only available to contacts. but i don't know a single client that warns you before publishing a vcard avatar

Ge0rG, agreed. I recently cleared my own vcard for that. Avatar is fine-ish

daniel, ok, it’s been a while since I set conversations up

so as far as I see it the argument is either users expect avatars to be public in that case pep-vcard-conversion is not a problem. OR users expect avatars to be private in which case we need to fix vcard

so, what do we need vcard avatars for exactly?

is it only anon MUCs?

jonasw, pretty much

if so, couldn’t we make MUC implementations handle that case like they handle vcards?

pep.: depends on how you use your avatar. If you just put in some random picture from google images, everything is alright. if you have your photo there... not quite

+ a little but backwards compat

but mostly muc

Ge0rG, sure

I was talking about mine

like, a generic PEP-through-MUC XEP which specifies how that works (welp, obviously updates won’t get pushed necessarily etc., but how queries are passed through), with a whitelisting approach and suggesting a list of things to allow based on MUC configuration and affiliations of the involved entities

because going forward we might want to abandon vcard entirely (or finally replace it by vcard4 proper)

pep.: I don't see your avatar.

153?

fwiw i'm fine with resubmitting the XEP as informal like 'look this is what ejabberd and prosody can do. take it or leave it'

pep.: I'm on a console client.

I’m fine with the XEP as-is. It has clear security considerations, it can be built upon and whether public operators do this or not is their matter.

but i'd prefer to 'fix' this by putting the kind of access control Ge0rG described in front of vcard

Ge0rG, I'm on the same console client with borked avatar support :P

daniel, that’d be better but I don’t see that as an requirement

jonasw, not for that XEP, no

yupp

My view is that we should be moving towards a world in which vcard doesn't exist, so we shouldn't modify the historical spec. It's worked "well enough" for years, so why add more stuff that things will have to implement? If the privacy thing is a concern for some clients (with the note that it's never been a concern for any client I've seen, so I don't know why that could change now), people could always do Daniel's hack if they have the pep node set to public and not do it (thereby losing avatars in MUCs) if it's set to private. If you want your avatar to be private, you probably don't want it showing up in MUCs anyways, no?

SamWhited, I think that the privacy expectations for avatars and the actual privacy delivered by the XMPP network diverge.

The problem I would say is having to choose one avatar (or let's say identity) for everything.

oO(it's really annoying to read long texts in Gajim when you have been mentioned. because gajim makes that into bold text with a low contrast)

and that clients do not care about this is not a sign that everything is alright

jonasw: historically, XMPP clients don't care about privacy.

"yay"?

SamWhited: we should be talking about _users'_ privacy expectations, not clients'.

I mean, it’s fine-ish if you don’t care about MAM things, because you’re supposed to trust your server anyways.

(or at least, one can argue that it’s "fine-ish")

jonasw: MAM is another messy issue in my eyes.

but it’s less fine if data gets available to everyone.

Ignore that part, it's irrelavant, as usual I shoudln't have mentioned anything extra.

The point is "if you want private avatars, they probably shouldn't show up in MUCs, so don't do the vcard thing and now you don't have to make changes to vcards"

jonasw: https://prosody.im/issues/867

SamWhited: the vcard thing is a server-wide module.

Ge0rG, unless coupled with PEP permissions, which is what SamWhited was saying I think.

SamWhited: so the server admin decides for all users if public avatars are fine

Ge0rG: that's an implementation detail; we can tell servers "do serve vcards in MUCs or don't"

(then the client gets to decide)

but yes, whether or not they implement the XEP we write is a server admin decision, but there's not much we can do about that. Server operators can share avatars online publically over HTTP for all we know, all we can do is provide guidance.

SamWhited: the world is full of implementation details. The XEP does not contain this detail, so it's changing the status quo

I didn't understand that?

SamWhited: if we tell server admins "this will make avatars of your users work in MUC" but don't tell them "this will make all user avatars public" we've failed our job

It won't make user avatars public if it says "don't do this if user avatars are private"

it's an interesting related question whether we should apply the same ACL to anonymous MUCs we are in as to our contacts.

Hi everyone! Can someone please type 123 to comfirm everything is connecting properly and this server works?

456

Haha

a.k.a. "test failed".