XSF Discussion - 2024-03-07

What's the process for becoming editor again? Do I need board approval?

@board please decide on me becoming an Editor

> You could mention occupant-id Done. https://gultsch.de/files/xep-0333.html

👍 great thanks

Daniel: about avatar conversion. Why open?

lovetox: because vcard is open

Ah I thought for a moment my roster contacts cannot get it then if it's not open

But they would use pub anyway

But would it not anyway simply better to write into the exp that pubusb model needs to be taken into consideration

Than fixing it to open ✏

I mean it kinda said that. 'clients should put up appropriate warnings' or something. But that didn't pass Last Call

Fwiw conversion only if access model is open is what prosody has been doing since always

What I mean is that a legacy client which supports only vcard can not get my vcard anymore

Because you forbid the conversion with this xep

Although he is in my roster

And has subscription

Yes and no. It means that if you don't want to make your pep node open you can not use the xep

And have to publish your vcard separately

I see no reason for this limitation

It's also not implemented in servers that way I'm pretty sure

Servers take into consideration the pubusb access model. And I see no reason why this is something bad.

What you are describing means that I'm denying access to the vcard for people who have previously been able to access the vcard

Just because this conversation xep is active (and my avatar Pep node is not open)

I find that odd. That's not something the xep should just be able to do

i thought thats exactly what you do here with that open clause

i have a roster contact, with a legacy client, he is able to view my vcard, furhter he is able to see my pep avatar because it set to "presence"

There are two possible approaches. A) Check on access of the vcard b) check when uploading the pep avatar

now i activate this XEP on the server, suddenly all my legacy roster contact lose access to the vcard

No what ever has been in the vcard before stays there

It's just that the conversion isn't happening

thats madness in my opinion

like .. no indication for the client if a conversation on the server happens or not

did you talk with server implementations if this is really implemented that way?

that they have two storages and have conversion process going

as i understood it they store the pep avatar in pep storage, and convert on demand and checking the pubsub access model

there is no second storage, which means this XEP would force them to add a second storage, and then different things could end up in both storages?

maybe some server implementors can give a feedback here, but sounds all very not nice to me

> there is no second storage, which means this XEP would force them to add a second storage, and then different things could end up in both storages? Im under the impression that this is pretty much what is currently happening

IIRC we just have one storage, yeah (PEP)

I can check in a bit when I'm at my laptop

ok, so what the XEP says MattJ, is now you need a second storage, because the conversion is only allowed under certain conditions, and Daniel exepcts clients to publish a avatar separatley to the vcard storage in these cases

My opinion is the XEp should simply say "When answering Vcard Avatar requests, the pubsub model must be taken into consideration"

it bolts basically a access model on top of the avatar field inside a vcard

Well there's a single storage if you use the vcard4 and vcard_legacy modules because that's what they use? the "vcard" module used something else right?

Right. There is no conversion at all then, though.

> My opinion is the XEp should simply say "When answering Vcard Avatar requests, the pubsub model must be taken into consideration" I think that's a valid approach. However it's not the approach this XEP has taken (which I belive reflected what implementations have been doing)

In that case the xep needs to be retracted

In favor of a 'answer vcard requests by mixing in PEP information' xep

is this not an overreaction? the xep does not mention pubsub model in its current form, now server implementations added the sensible privacy feature that if a client publishes to PEP, the vcard request adhears to PEP access model rules, As the client and user would expect when setting the PEP access model.

why would this not fine with the current form of the XEP?

What I can tell you is that the xep in the current form didn't pass Last Call

ah ok it was rejected, and they wanted you to add this?

sorry didnt get the history

anyway i think i said enough, i give others the possibility to state their opinion

I think both 'copy' and 'feed from the same source' are valid approaches. This xep is build around the copy idea

last sentence from me: The implementations currently in the wild work *good* as a client dev i didnt waste time on this topic in a long time, it simply works. Please lets not make it worse

https://github.com/fabiang/sasl/issues/12#issuecomment-1983224432

The last question is actually valid, the "ordering" of the list is I assume alphabetically ?

https://xmpp.org/extensions/xep-0474.html#hash

> Note: All sorting operations MUST be performed using "i;octet" collation as specified in Section 9.3 of RFC 4790 [9].

If i understand correctly i agree with lovetox vcard conversion with single storage and you get whichever things access model says you can get. But also it's all for legacy anyway so I'm not super worried since the only place i still use vcard anything is muc avatars ✏

I should point out that, even though both approaches are valid, they both have their own quirks. If you suddenly start doing access checks on vcard access - and leave your pep access model at default - you will break vcard access through muc

Which is as you correctly point out the primary place where vcard is still used

Is that not true either way? If avatar is not open MUC should not see it. Unless you simehow have presence sub with a MUC 😉

there are minor differences between the two

That's solved by the "set a different vcard per muc" XEP that someone still has to write

why does it have to be that specific and we cant have instead a generic permission model that you can pick the entity to expose a specific vcard to?

or wait this is another limitation of vcard?

Write it and find out! 😁

lol if nobody else gets around to that by the time i need to implement profiles in my library/app sure :P

fwiw my goal is to get a XEP that is seemingly widely deployed https://compliance.conversations.im/test/xep0398/ and part of the compliance suite out of the deferred state. not write a different xep that fixes all of our avatar related issues

For sure, that's what I meant with my comment, other avatar problems are better solved with other XEPs

I think the only concern is speccing what is deployed and not something incompatible

yes I think we need clarification on what servers are doing. I was under the impression that prosody is doing what the new draft of the XEP says. due to comments like this: https://github.com/iNPUTmice/Conversations/issues/3289#issuecomment-441433477

OK. I read some source code and I guess I was mistaken

Probably best to retract the xep then

Why not just edit it?

I think the entire premise is different to what prosody implements

I doubt it's entirely different, but even if so can we not just make it say the ridht thing instead of having yet another dead duplicate number? ✏

Are we not just talking about wording for security considerations? I'm not sure how it's so different

I don't think we are just talking about security considerations

My understanding is that the main purpose of the XEP, like the bookmark conversion ones, is to define a feature so that the client knows if the server implements automatic conversion

Otherwise the client might decide to duplicate info between vcard/PEP "manually" to keep them in sync

Does any client actually do that?

or use only the older thing

No idea. Servers have implemented conversion for some time AFAIK, so it may be deemed unnecessary these days for sure.

Pretty sure Swift is still doing vcard.

(Just as an answer to Zash)

Btw MattJ since I was reading to source code shouldn't https://hg.prosody.im/trunk/file/tip/plugins/mod_vcard_legacy.lua#l329 do access control too?

Otherwise you leak the hash to parties who shouldn't have access to the avatar

Daniel, that's a one-time check prior to broadcast. is the hash sensitive enough that it's worth doing the access check n=roster items times?

Zash: depends. I guess if you already know the user you can confirm it's the same user that's in a muc

And or track users across mucs

I mean the premise of the module is that avatars are sensitive enough to be hidden behind access control. If one agrees with that premise that surely also involves the hash

You could do the presence injection only if the node is open. If you wanted to keep a one time look up

I'm not sure I would call that the premise of the module. It just seemed natural to respect the PEP access controls, but for that hash it's messy

Messier than access control on pep notifications?

Because the presence is constructed ahead of time

I just read the introduction of XEP 0398, and as i understand it now the only goal of this XEP was that we dont have to upload avatars into two storages because XEP0084 is not retriveable via MUC.

So to edit it now and add a sentence that essentially means, if you dont want to use "open" on your PEP node, then you still have to use 2 storages, goes against the initial intended goal of the XEP

Main Goal is, Use 0084 for upload, use 0153 to retrieve

Surely you can fetch pep via MUC. But you don't get +notify to know about changes which is the main thing still uring vcard-temp avatar for

what was exactly the problem why this did not go through last call, last time?

ding ding ding

As I see it, the goal of mod_vcard_legacy is to become obsolete and get deleted.

"If a user uploads his avatar via PEP with a access model X, this access model is to be respected when serving avatars via VCard" I dont see how this sentence breaks something for anyone

Which Board members do we have online for the meeting right now?

https://wiki.xmpp.org/web/Board-Meeting-2024-03-07

@emus @nicola are you here?

I would not be surprised if @ralphm is not able to join.

You know the "@" is likely not to make mentions work right :P

Depending on how regex are written

(Also why we need that mentions spec..)

> @emus @nicola are you here? Yes, I am

OK, we have a quorum then.

pep.: :shrug:

Matt J: would you like to run the meeting or shall I?

If you would please, I'm on mobile so typing will be less efficient than usual

OK!

Call to order! :-) We have Matthew, Nicola, and Peter here. Eddie and Ralph absent at least to start.

Returning business….

(a) Anything new about the editor role, related tooling, etc.?

No news from the tooling side that I'm aware of, though there were recent discussions about the future of the Deferred status

I think that just needs someone to write up a proposal if we want to consider it

> @board please decide on me becoming an Editor Said Daniel

Oh yes

It seems we go back and forth on Deferred, with no significant energy either way.

+1 to Daniel!

+1

The most interesting thing to me would be removal of the automatic transition, because it impacts (specifically, simplifies) tooling

+1 to Daniel

sorry, I missed the meeting

I had a PR about editor tooling open durng summit I don't know if that needs review still or what

emus: we’re just starting

> The most interesting thing to me would be removal of the automatic transition, because it impacts (specifically, simplifies) tooling I agree

singpolyma: ah, missed that

MattJ: ah, interesting. Simplify, simplify! ;-)

Im not sure if I can participate. i have one or two aob

The challenge in the past was that we had more XEPs seemingly under active consideration than was really the case.

emus: please mention your AOBs and we’ll add them at the end

I just made tne script able to auto do actions, with the idea that editor can run that like the do the current script and if all goes well it's trivial to make a GitHub action (which im willing to write

Basically we have a bunch of stuff marked as deferred that is actually in active use. Sometimes we have reasons for that, sometimes we've just not been on the ball about advancing them. There was a suggestion that making "deferred" a conscious move would be better.

stpeter: ok

Daniel has been doing some work to get some of those XEPs advanced, which is great

Excellent. Thanks, Daniel!

MattJ: I see. I have no objections to that.

So we need to find someone who can be “voluntold” to write up a proposal. 😊

🙂

Likely we were following IETF practice, but they have way more Internet-Drafts than we have XEPs.

What to do of currently Deferred documents? Leave them as is?

I will look at it and think about writing the XEP.

Fix typos for those we care about?

- Topic 1: Paying two twitter accounts or deprecate. I vote for deprecate. on the other side we have new money - Topic 2: Trello --> Github projects function? - Info: Outreachy does not accept umbrella organisations

pep. not sure - let’s see what the proposal looks like, but that’s something that needs to be considered.

emus: OK

moving on to the next item then? Daniel is on the Editor team, I might write the Deferred proposal

(b) infrastructure situation

Any news here?

No news since last month

OK

moving on then 😊

(c) sponsors

We’ve done a great job of getting more sponsors on board, thanks to everyone who has helped with that!

A few of them are still in progress.

And big thanks to Isode for sponsoring the Summit.

👍👍

Great!

If we can keep up this level of sponsorship (with annual renewals) then your Treasurer will be much more comfortable. :-)

Moving on again, then, to New Business.

(a) GSOC

Thanks to Eddie for getting us into GSOC again.

Accepted, 7 ideas, 3 clients

emus: is there anything you need from us?

> Accepted, 7 ideas, 3 clients 👍

stpeter: just advertise where you can, also offlie

offlline

OK

emus: what is the deadline?

(our internal deadline for people to submit ideas)

16th

ahh 16th +1w

OK, thanks.

i think

So folks should poke their developer friends.

Moving on again. I like short meetings. ;-)

New (b) explicitly pseudonymous authors of XEPs

https://jabbers.one:5281/file_share/YWWvBsXyX_4wa5U4WSAA5hTF/zb2rhYPCCQJLjAUnC6Uox3iDHuzXf7gbCD4Jz2yvarG2WQw6n.jpg

The Editor team has received a new XEP contribution from someone who explicitly told us he operates under a pseudonym.

We don’t actually check people’s legal status / name when they contribute a spec.

e.g., for IPR assignment

And we’ve never done that.

It’s not as if there is a legal contract involved.

The author merely says “here, it’s now the XSF’s IPR”

That's not exactly true.

There is an explicit IP grant step.

So I don’t have a problem accepting this contribution.

That GitHub checks for us, and when it's not received via GitHub that the Editor does manually by mail.

Right, but the author doesn’t sign a contract with their legal name with notarization and all that.

Because Board decided that doing what you describe wasn't sufficient a couple of years ago.

IIRC

Yes, there is an explicit grant, but we don’t check the person’s identity.

And we never have.

I'm fine to continue with that

IP grant steps are done everyday with CLAs or DCOs without any means of legal identity verification

No, indeed, but I've been told in the past (by lawyers) that email is fine to be considered a contract-in-writing.

At least, that was what I understood from it.

> No, indeed, but I've been told in the past (by lawyers) that email is fine to be considered a contract-in-writing. I agree 😀

pep.: yes, most open-source projects do it that way, there are all sorts of nicks/handles/ contributing.

As long as the author is reachable..

(which isn't the case of some of the XEPs' authors, note, even though they may have used their legal names) ✏

Kev mentioned another potential concern, which is that a pseudonymous author might be less reachable or less inclined to move the document forward, but we have other ways of handling that situation (e.g., assign co-author).

Right.

> mentioned another potential concern, which is that a pseudonymous author might be less reachable or less inclined to move the document forward, but we have other ways of handling that situation (e.g., assign co-author). Did I? I thought that was someone else, but maybe it was me.

Can’t recall. Could have been someone else.

(I have to duck out again now. I don't care which way it goes, but I'm noting that we *do* require people to grant IP explicitly, and so what I was mostly wanting was that Board was happy/not happy that that was still valid when it happens under a pseudonym, in whichever legal regions we have to care about)

Answers on a post card to Editor please :)

In any case, what I’m seeing is that Nicola and I are fine with accepting this XEP. And I think Matthew as well if I understand the reference of his statement above “I’m fine to continue with that.”

Kev: yep, will do, thanks. :-)

> In any case, what I’m seeing is that Nicola and I are fine with accepting this XEP. And I think Matthew as well if I understand the reference of his statement above “I’m fine to continue with that.” Yes

Yes, happy to accept this XEP and pseudonymous authors

OK!

It would be one step towards being more open

We have quorum, decision made, I’ll post something about this somewhere to memorialize it.

emus: are you OK with this, too?

Moving along to “Any Other Business”…

emus raised the following AOBs above: - Topic 1: Paying two twitter accounts or deprecate. I vote for deprecate. on the other side we have new money - Topic 2: Trello --> Github projects function? - Info: Outreachy does not accept umbrella organisations

> emus: are you OK with this, too? yes ↺

(1) I thought we had decided to pay for 12 months while we sort out where to move our social media presence.

> emus raised the following AOBs above: > > - Topic 1: Paying two twitter accounts or deprecate. I vote for deprecate. on the other side we have new money > - Topic 2: Trello --> Github projects function? > - Info: Outreachy does not accept umbrella organisations I agree with Topic1 and 2

emus: read, thanks.

s/read/great/

> (1) I thought we had decided to pay for 12 months while we sort out where to move our social media presence. Yes, but according to twitter I must pay my remote account as well ↺

ah

Sorry I meant that I prefer to deprecate

we can test and kev starts to party for the main one and see if it requires me to pay as well

I’m fine with deprecating, personally! But then I got off Twitter in 2016. Ten years was enough for me. ;-)

emus: sure, whatever you think makes sense is fine with me.

> I’m fine with deprecating, personally! But then I got off Twitter in 2016. Ten years was enough for me. ;-) I see 😀

As before, my preference is to deprecate that account, but ralphm felt strongly about this in the past so it might be worth discussing when he is around

MattJ: noted

Or we just abandon the tweetdeck approach

Let’s discuss via email or in next month’s meeting. I don’t see a hurry here, unless emus says our access will be cut off.

nod

As to Trello->GitHub, that seems sensible (this way we don’t have things spread around on different services).

On twitter: Just saying its unmaintainable.this way. I cannot do reach out to Kev all the time and its quite a burden

> As to Trello->GitHub, that seems sensible (this way we don’t have things spread around on different services). If we use it ok, otherwise …

I'm fine with that, but we haven't really been using Trello for years

emus: Yes, that’s crazy. 😊

MattJ: true, so this is perhaps a non-decision.

But we might want to remove the Trello board to reduce confusion (I don’t even know who controls it now).

+1 but extract if there are still valid topics listed

Shall we think about it and postpone the decision to the next board?

emus: what I see is, let us know what you need/want re Twitter/X and we’ll support you - but before turning off the account we should talk with Ralph.

nicola: yes

emus: please send a note to the board@ or members@ list about Trello so we can have a look (I don’t recall what the URL is for our board there).

OK, any other AOBs?

None here

Date of Next Meeting. This should be 2024-04-04 (the first Thursday in April). I can create a wiki page with the agenda.

> Date of Next Meeting. This should be 2024-04-04 (the first Thursday in April). I can create a wiki page with the agenda. Ok. Thank you everyone

Hearing no more agenda items, I move that we adjourn. Second?

Seconded

Thanks, all!

Thanks stpeter 🙂

My pleasure!

Thank stpeter

Now back to our regularly scheduled technical programming… ;-)

Btw I just checked the ejabberd source code and I'm pretty sure it copies the avatar on write from one storage to another. Which is different to what prosody is doing. (which is synthesizing the vcard on access). So I'm not sure I'm comfortable rewriting the xep to what prosody is doing

thanks all

One reason we did it the way we do is to honour access control on the vcard info, even if you have clients supporting only legacy vcard

Otherwise it's weird, and having two copies of the same data (that can get out of sync, sometimes) is also weird

It's not that I dislike prosodys approach. But I think the difference (essentially when access control happens) is more than just an implementaional difference

For Snikket we expose the access control, and I don't want to have to explain to users that it only affects the visibility of their profile to *some* other entities

Neither do I particularly want to just remove vcard-temp (for interop)

And the xep was certainly written with the intent to spec out what ejabberd is doing.

Can the XEP cover both use cases? As I said earlier, I thought the main value was the client knowing it didn't need to publish the data twiilce

Not saying it's good that the xep is that way. But that makes me uncomfortable changing the xep

"If the server stores the data in both places separately, here's how"

We did that with 0191/0016

> Can the XEP cover both use cases? As I said earlier, I thought the main value was the client knowing it didn't need to publish the data twiilce Not with providing clear and accurate security considerations I think

So should Prosody not advertise the feature?

That seems like a step backwards

Idk if you think you currently implemt 0398 we can also publish it as is

And only slightly modify the existing security considerations to remove the 'in the future' wording and replace it with 'services may'

As lovetox said, from a client perspective, "it works"

I wonder when we can sunset vcard-temp completely

Hey, it was always supposed to be “temp”

At least it wasn't called simple-vcard-temp

temporary the way the earth is?

https://xkcd.com/1606/

we can depreceate it and then its done :)

deprecate*

see the new 5.2 section and the slightly updated security considerations https://gultsch.de/files/xep-0398.html

sounds good, so does ejabberd check the pep access? or does it simply serve the avatar to everyone that requests vcard

because i would consider this a leak

this XEP introduced a privacy leak when not correctly implemented, clients who always only published to PEP with access presence, suddenly would have there avatar public when requested via vcard. I think Daniels intention with the XEP edit now, was to make it clear to servers that this leak must not happen. Thas why he added the rule, that avatar must only be sent via vcard if model is "open". what i proposed is simply to make it not stricly open, rather say "honor the pep access model". I still dont understand how "open" can be ok with the XEP intention but "honor the pep access model" is not

it was not my intention to get everything out of the XEP about the access model, there is a privacy leak risk here which should be mitigated with wording in the XEP

Now your proposal talks about different ways to implement the storage, and now we have different rules per storage? why would it be allowed for ejabberd to have this privacy leak, just because they decided to copy avatars around

We have two very different implementations that both claim to be compatible. I can't write security considerations that are strict and keep both implementions in compliance

Write them strict then fix the ejabberd impl

just so it be noted, i never checked the ejabberd impl, and dont know if they consider the access model

Daniel checked the code, and i asked if he saw something

> this XEP introduced a privacy leak The xep (as published on xmpp.org) says so

I think maybe security considerations can say "note that many vcard-temp implementations historically have not used any access control, so care should be taken if the pep node access model is not open" or such?

I would note that the Prosody module defaults to open, so it would behave as with the old vcard module until the user interacts directly with PEP and sets some other access model, which is then respected. Seemed the sensible thing to do back then.

If the xep has no clear security considerations and is written broadly enough to allow for both the prosody and the ejabberd approach then I'm not really sure what we need the xep for

It's a transition helper, ultimately it should all become obsolete and leave us in a glorious PEP-only paradise, right? :)

So maybe we don't need to worry too much about it

Right. Servers do _something sensible_ no xep required

The XEP doesn't say anything about merging in other PEP nodes like vcard4 or nickname, right? Only avatar?

Yes only avatar

I don't dislike the idea of writing down what prosody does in xep form

Like a 'virtual vcard' xep

Tho parts of it can be squint-derived from the vcard4 xep.

Which two parts?

https://xmpp.org/extensions/xep-0292.html#mapping

But not in the same way of 398

('Tho' = 'Although')

Reading 398 and going with a single source of truth method where data is stored in a canonical form in PEP, moving out the rest of the vcard data into vcard4 seemed sensible, but we never got around to a XEP about that.

Zash: if I publish a vcard4 with a photo will it store that in the avatar node (and remove it from vcard4)

if you publish to vcard4 then it's just regular pubsub

I would recommend against putting a photo in vcard4, since we have the separate pep node for that

Well yes but vcard4 can have a photo (and nicks) so you'd be duplicating information again

having a public avatar but contact-only profile details was a thing I personally wanted

> Zash: if I publish a vcard4 with a photo will it store that in the avatar node (and remove it from vcard4) Would be nice ↺

Pep nick has always felt redundant to me

I think it would be nice if we just offer generic PEP and don't have to do anything special

Hence the module translating to/from vcard-temp but storing vcard4+pep avatar (and also mod_bookmarks doing a similar thing)

So when all the clients have moved to the PEP native method, these translation layers can be turned off.

> Well yes but vcard4 can have a photo (and nicks) so you'd be duplicating information again i dont think we need to think about that, a client is not forced to do this at all

vcard is vcard, we didnt invent it, and it has a million things in it, no problem with that

we have a better way to store avatars, and client devs know about it, really there own problem if they decide they need to put it into vcard

same with nickname, we have different nodes on pubsub for different kind of data, everything is nicely separated with the additional nice thing, that we can also use different access model on different data

i really see no problem we need to solve here that merges server side different data into one

XEP0398 was a helper so we can transition to pubsub with avatar, without losing avatar in MUCs

thats about it, im not aware of another problem which needs solving in that regard (vcard/nickname/avatar)

Sorry I never finished the vcard4 PR adding some words of discourangement for including pictures.

no need really, every developer will get it rather fast

we have compliance specs ect, and they probably all mention avatars

https://vin01.github.io/piptagole/security-tools/soar/urlscan/hybrid-analysis/data-leaks/urlscan.io/cloudflare-radar%22/2024/03/07/url-database-leaks-private-urls.html ==> could this affect HTTP Upload links? Those links are not supposed to be handled outside of chat room by XMPP clients, but how can we be sure that there is not a proxy or whatever CDN somewhere in the middle? When e2ee is used, it should not be a problem though.

yes if e2e is not used, middleman can steal your data, i dont think we can do something about it

We could add a password in HTTP header (or use Jingle).

Is that about people being surprised that when they send links to 3rd party services that the 3rd party services have the links then? Yikes... Stop hitting yourself

goffi: http has user/pass auth standardized, but also this isn't a problem unless clients are sending URLs to third parties and then no amount of passwords will help e2e uploads are protected from CDNs/middleboxes at least

moparisthebest: my concern is more about not being aware of third party being used (your XMPP provider use a CDN, your web client does URL analysis, or whatever). But I realise that there is authorization header already in HTTP Upload, I remembered it wrongly as not allowed. So this is fine.

assuming you don't also expose that header to whatever third party :)

yeah sure. Anyway if you really want your file to be safe, use proper e2ee. I was mostly concerned about the file link shared on the casual unencrypted private conversation being accidentally exposed.

And if we can't totally avoid that, we can at least add some foolproof.

You can also send the encryption key to third parties if you want to

so many options!