XSF Discussion - 2022-12-06

Tonight’s event is not on the XSF calendar, is this intended?

emus: I'll be there

nicomuc: no, but I have never dealt with it ralphm:

https://blog.keyoxide.org/xmpp-claims-vcard/ ==> maybe we should clean this vcard situation once for all, get rid of vcard-temp and IQ protocol in XEP-0292 to only use pubsub.

That's not really the problem though, although the post makes it seem like it is

The ultimate problem is that we are moving towards profiles that are not public by default, but non-public profiles are incompatible with keyoxide's requirements

So it makes it sound like this is due to a "transition between standards", but it's more about "dropping the legacy world-readable profiles"

we can make them public with an open access model

I've already contacted the author/developer and we're going to chat about how to solve keyoxide's requirements

but it would be better to be able to choose which data is public and which is not

Sure. If you make them public then everything is fine.

with pubsub encryption, it could be possible to have several vcards, the public one, and other one restricted to some users.

One obvious piece is that <DESC> has no equivalence in vcard4, so in Prosody we convert it to <note>, but that does have an equivalent <NOTE> element when converted back to vcard-temp.

simple solution would be to have 2 pubsub nodes with different settings for vcard4 (one public and second one for "friends")

You may not want to have your server admin to access some vcard data, pubsub encryption is a better option IMHO (also you have a single node, no need to look for the node id to use).

I'm not convinced to encrypted pubsub for vcard

Encryption isn't going to solve this issue tho, quite the opposite.

Zash: why?

The goal is to publish public information

Publish a proof to keyoxide and anyone who wants to verify, thus if anything signing may be helpful, but not encryption.

My proposal is to have several items, one bein plain text, and the other ones encrypted. You may want to have your nickname in public item, and phone number encrypted only for friends.

goffi: I have drafted https://github.com/xsf/xeps/pull/1246 about gitting rid of the iq

Zash: for keyoxide stuff, you put in plain text item.

singpolyma: great

goffi, so what solves it is having an "always public" part, not encryption

MattJ: ideally we wouldn't require this binary "world readable vs not" choice. There's no reason we can't send different vcards to different people, one for public, one with more for contacts at the very least

singpolyma, the XEP editor (hehe) awaits your submission :)

MattJ: doesn't really need a xep, IMO, there's nothing against the current specs to do that

I don't see how you can do it without a XEP

you mean in terms of how will the user configure what to send to who?

or are you saying the server should hard-code rules about what is public and what is not?

singpolyma, feel free to steal and complete all of my WIPs from https://github.com/xsf/xeps/compare/master...Zash:xep-0292-updates

MattJ: hard-coding would be the simplest way, but obviously not useful in all cases. If I were running a service for it I would expose an ad-hoc command that allowed this config. But for example something like snikket could also do it in the Web UI instead if that's preferred

And not all clients even have a way to view or edit vcards.

for sure, that's fine. not every clients needs to support every thing :)

Though I do want to add that to mine

complicates their use case tho

for keyoxide? I mean, their users are pretty techy so if there's a how-to for several well-known clients it's probably doable for them

XMPP End of the Year Talk 2022! Starting in about 30 mins! https://socialcoop.meet.coop/sam-pku-dud-niv

I managed keyoxide with gajim.. But many people had indeed problems. Even generally tech affine people.

It was me! I broke it!

Hmm, I am not amused. One needs to activate a BBB session? we cannot join until someone "starts" it?

emus, is Sam around to activate it ?

nope

fun

do we need another option? I can offer one if needed

is it jitsi or BBB?

I have one open already

(an alternative)

if you have something already that's fine. I have access to another BBB

can you get it ready? but please wait until I confirm to post before people run crazy.

everyone post different room links in 3... 2...

my god, how I hate this...

Last time i used BBB i swear it had a start room without me setting..

eh don't worry about it, these things are to be expected

anyone able to login? https://socialcoop.meet.coop/sam-pku-dud-niv

I'm on: > The meeting hasn't started yet. > You will automatically join when the meeting starts.

Nope doesnt work

Me too

🤬️

same ✏

okay, plan B activating...

Nope doesn't work

Time to launch the Matrix conference room ?

Me too ;)

Everyone interested in the XMPP End of the Year talk, please join here: https://bbb.sfconservancy.org/b/ste-fdo-qen (technical issues as always)

So we can chat over the Prosody in the embedded Jitsi Meet in Matrix?

Twitter user = Fosstodon user after two years! (only 100-200 related to recent situation)

https://jabbers.one:5281/upload/WimIkcmfCUVKdNB1II_an6Cj/4271647d-c2e5-47a8-8e58-804269bac5e2.png

Fediverse rulz 😎

FYI https://wiki.soprani.ca/ClientIssues

thanks goffi & mathieui for the pandoc suggestion it worked out well https://www.moparisthebest.com/slides/slides.sh

👌

Thank you for the interesting event.

Con gusto!

Yeah, was nice, thanks 👍

singpolyma: re: host-meta, another argument for not SRV is I want a place to put the ECH secret

I need to just write it up to get the discussion going...

I'm just pretty grumpy about anything that involves http

I don't actually blame you, it's just DNS and DNSSEC is so depressing

We could have such nice things!!!

Apparently conversations has DNSSEC support disabled by default because just asking for DNSSEC stuff can hang the connection on some DNS servers? I'm just reading some historical reports, not sure what actually causes the reported failure mode

Stop enabling the middlebox vendors by putting everything in HTTP! 🧐️

I mean, can get DNSSEC even in that case because of DoH

Seriously though, does anyone think we can get an XMPP DNS record type widely adopted the same way the https one is?

If someone wants to try I'll help, but I honestly can't see it succeeding

Just use the generic one that is identical to HTTPS?

Or even more evil, hijack the HTTPS RR type

Obviously the SVCB one will never work

iirc it didn't have everything we need, but I'll look again

SVCB? The one that lets you put arbitrary pseudo-RR types in it?

Not a new record type, no. But between srv and txt does anyone ever truly need a new type? ✏

I bet you could do DNS over HTTPS-the-RR-type

Those types are the ones that need defined, like https

Write "subtype X is a thing" and submit to IANA

I mean SVCB/HTTPS has A, AAAA, TLSA and some more stuff already

Oh I'm sure we could get iana to approve it, but getting support in any DNS dashboards or anything other than bind seems impossible

Meanwhile we can (unfortunately) use host-meta and get anything we need with secure delegation today

call the XEP dns-temp ;)

We should just rename XMPP to IM-TEMP to really cement our infinite existence

:D

Nice