XSF Discussion - 2020-06-02

Memberbot is still online for our member meeting today. If you have not voted yet you can still do so

Is Davide Conzon here? If so, do you have a JID which federates with the rest of the Jabber network?

Alex: after the ending, it will be possible to test the memberbot solution to have no instead of No?

I have sent you code to test in real several months ago...

I cherry picked the code

It's there already

Master branch is broken and does not work. I need help to get ithis code fixed and working ✏

Someone (Alex?) mentioned that these application time windows are outdated: > Applications from prospective new members are accepted during the first two weeks of every quarter (i.e., the first two weeks of January, April, July, and October). How does it work these days?

Holger: usually I try to align with the timelines we had in previous years according to the wiki. Happy to agree on fixed timelines when it helps

Alex: Nah, fine with me. So next round would be early August AFAICS.

Ya

I planned to apply for some months now and kept being too late to the party so I thought I'd add a reminder to my calender, that's all :-)

Just create your application page now and I will add it to the Q3 application page

Or I ping you when the Q3 page is created

You sound as if I was able to get things done *before* it's almost too late.

:-) Hopefully my calender will do the trick this time. But thanks a lot!

happy to hear that Holger !!!

Holger, I may also add you to my mental nagging list ;)

like I pester Link Mauve all the time about the reapplication ;)

Holger, welcome to the club! :D

Heh, glad I'm not alone.

Hi. https://xmpp.org/extensions/xep-0373.html#discover-pubkey "Note that the result may contain multiple pubkey elements. Only the public keys found in the most recent item MUST be used." I don't get this. Why should there more than one public key? Which one is the most recent item?

That doesn't feel right

It should probably say that the node should be used and configured as a singleton node

"most recent item", is that the thing that's not-really-well-defined? (most recently created vs updated?)

(or is that defined now?)

Daniel, why?

I don't think 373 forces a single key per account

But in one item

ah right

According to the quoted wording

Well the quote suggests there might be multiple items, not multiple things in an <item/>

I think our knowledge and understanding of PEP was different when the xep was written

> Well the quote suggests there might be multiple items, not multiple things in an <item/> Yes. And you can avoid that was proper singleton nodes

Which the authors probably didn't really know

And/or implementations were more broken back then

Right, and different nodes for different keys

Yeah...

Not sure if one would do that today

I was just Reacting to the quote

I didn't check the xep

sure

There is a second question. I think it's not required to push the public key on the PEP. The client should be able to lookup for the key on the local keyring. I implemented it via lookup of checking the userid as XMPP URI in the local keyring. If there are more than one public key, should it be encrypted to all keys?

"the [only] client"?

I guess since you are one of the first people to implemt this I guess it's on you to use your best judgment and provide feedback

Personally I would probably only implemt lookup and not mix in third party key sources

There are already same problems with the gajim plugin :-(

If you don't push your public key on PEP, how are people going to encrypt to you? Am I missing something

I wouldn't even use the local Keychain that is used for 'regular' pgp

yeah I wouldn't either

I would :-)

Sure, that's left to the implementation anyway

Is that only for profanity? Any other clients you're pushing that to?

yes, profanity and a small gtk application.

Ok, I will try to write down some notes and send a mail on the mailinglist.

https://codeberg.org/xmpp-messenger/eagle/wiki/Usage

Isn't the possibility of having multiple keys inviting the same problems that omemo has

Aka not being able to do tofu

But having to resort to BTBV

Daniel, wasn't there talks about a "master key" at Summit?

Even if few people actually do it the fact that it is allowed means I have to have trust ui for that

on the account

That being independent from $e2ee, so you could have OX or OMEMO behind I guess

Maybe somebody(tm) should write this down somewhere

OpenPGP keyrings can consist of multiple keys ✏

I did already started in German: https://codeberg.org/xmpp-messenger/eagle/wiki/BS-XMPPOXOpenPGP I will try to work on it. Maybe in the wiki?

Sure

the design question is if the data/metadata node split is still required, given that we could to payload less notifications

the initial version of OX, had no split, then we split and now it looks like we do not need the split

singleton nodes are not relevant here

I *think* you can argue in favor of the data/metadata node split if we want to support multiple keyrings per user, which we do now

There can be more than one Key for a UID, but I don't like it. The user has to decided which key / key he would like to use.

Singelton nodes and metadata spilt are two different issues

metadata split?

The quoted paragraph is already requesting what should only contain one key

Daniel, right, my point was that there singleton nodes only help collect garbage, they don't offer an advantage when it comes to determing the current keyring(s)

Zash, xep373 § 4.1 and 4.2

The quoted paragraph says you might get multiple items in return

Which wouldn't be the case if the node was a singleton

Daniel, I don't have the paragraph in front of me, which one was it again?

> Hi. https://xmpp.org/extensions/xep-0373.html#discover-pubkey > "Note that the result may contain multiple pubkey elements. Only the public keys found in the most recent item MUST be used." > I don't get this. Why should there more than one public key? Which one is the most recent item?

in any way, you could also simply request only the latest item

That was the initial question

And what I was Reacting to

Uh, that is multiple pubkeys per item

xep373 ex7 uses max_items=1

Which makes the quoted paragraph even more confusing

no wait, that is a request on a data node

Ahh I guess I see now

that is why the second sentence hints towards using max_items=1

flow you could add a paragraph that says singleton node has to be used

Even max_items=1 is just a work around for a proper singleton node

well from a protocol POV there is no need to use a singleton node

id="current" etc.?

pep.: yes. Plus max items 1 on the node config

flow either your XEP wants to request a single item

Not on request

then it should also enforce singleton node

or not then you dont need maxitems=1

I'm not saying the xep is wrong or anything

Just our best practices have changed

Wrt to PEP

sure, the question is, if older versions of the keyring could be beneficial in some cases

I can not answer that, and hence I am a little bit reluctant to specify the singleton node as a must

Isn't the key supposed to be stripped down?

Daniel, could you elaborate on max_items being just a work around for proper singleton nodes?

So what kind of information would change?

flow: well one limits the request the other actually let's the server store only one

There is no need to have different versions of the public key.

Daniel, right, I say that those are for different use cases

flow are you aware whata singleton node is in pubsub?

lovetox, yes

If the intent is to make historic variants of the key available the xep should state that as a feature

Otherwise it comes of like an accident

ok, so max-items=1 request always the last item, so why would you have a node that stores unlimited items

if you always only request one

as I said, I do not have an answer if having the history of the pubkey is benefical or not. Hence this part of the XEP is deliberatly designed so that we can experiment with it

no its not, you looked at other XEPs back at that time and copied what they did

now its a design decision

ok :)

Not sure if it fits this use case, but there's a thing in XEP-0060 about payloadless notifications that could be nice for certain PEP uses. Avatars for example, if it had been designed with that in mind.

It really doesn't come of as deliberate

But noted

So the XEP saying nothing about singleton nodes but recommending to use max_items=1 when requesting, while I followed the whole OMEMO singleton discussion does not come as deliberate?

No

anyway this discussion is not relevant client side anyway, as a client has to use max_items=1 anyway because we cannot depend that all other clients respect the singleton node

I feel a little bit accused, but anyway. I mean the arguments in favor of keeping are not strong, I know, but I also do not see any harm in keeping the history

its just a server thing to not store unlimited items

sure, I hope servers have a quota mechanism of some sort

There was a brief period after adding support for multiple items in Prosody and before adding limits where it it could store unlimited items.

well not declaring it a singleton node tells clients this can be a list, right? (then I'm not sure why the max_items=1 at all if it's not meant to be a singleton node)

pep., because in most cases you want the most recent version of the key

Does max_items=1/singleton have anything to do with this?

(sorry I'm not sure I followed all of the above)

Can you give an example for when the historic version of the same key is useful?

with either of them you get the most recent version

flow, ah so a client can request max_items=1 for the "latest" but the server storing more?

Daniel, no, but can you list all examples and show that none of them benefits from prior data? ;)

I mean, I can not right now, and it is not unlikely that there is none

But at least in this stage I wouldn't close the door for it

And again, I don't see any harm, since servers have incentive to purge old items anyway

There's gonna be an update of 373 at some point anyway, for SCE :p

Or maybe 374 rather(?)

AFAIK, the local Keyring, the keyserver and WKD doesn't provides historic versions of public keys.

pep., well actually SCE's design was inspired by what xep373/374 do

flow, I know

Right. So if you can't give an example for why one would want such a feature and if the feature is not mentioned anywhere then this is the reason that I believe the feature was not deliberate

But now that we have a SCE..

Daniel, if I don't know if it is a feature or not, then I would hardly spell it out in the xep

pep., sure, but at the current stage of SCE would switching OX to SCE provide any benefit and justify the version bump?

Might as well bump while there isn't many impls.

bumping as soon as there is more than one experimental impl is hard, and we should also bump in batches

that is, I would not bump for SCE alone, but if I had to bump, then sure, why not

:/

I am not sure why this is disappointing?

If we have learned one thing, then it is that version bumps should be taken carefully, and coordinated

Becaue I never get why people fear updates

It's just a thing that happens and we deal with it

I don't think I fear updates

But the fallout of version bumps can be significant

In fact I am happy to bump, esp. in the 'experimental' stage

I only know of 2 implementations atm, gajim and DebXWoody's, 373 is not used. I'm not sure what's preventing a bump at all

but I would not bump for every "tiny" thing

well for one, as of 5 minutes ago, nobody suggested a bump

then, IMHO, the far more important design decission when it comes to OX, is not SCE, but the metadata node split ✏

what is SCE?

420

Stuff that 373 does, but not specific to OX

Ok, I saw,.. but forgot :-)

pep., btw, smack has also an OX impl

k

flow what do you refering to when you talk about a meta data node split

there is already a metadata node

lovetox, right, the question is if we could go instead with payloadless notifications

i would not classify this as "far more important"

this was a idea by someone, never impl in any xep and tested

well if we could get rid of the split, then it would reduce the complexity of the protocol somewhat

which is always desirable IMHO

its not complex, we have that split in 20 other xeps

completely changing the syntax of how messages are transmitted ( SCE )

well that does not mean that we have to continue that pattern if something better is feasible

that is indeed a big change that should be made rather sooner than later

is it really *completely* changing the syntax? IIRC SCE re-uses a lot names from OX

it breaks that what i meant, it does not really matter by how much

Notes I have in mind about OX: https://wiki.xmpp.org/web/Tech_pages/OX

hey guys, anyone ready for our member meeting?

!

here is our Agenda for today: https://wiki.xmpp.org/web/Meeting-Minutes-2020-06-02

1) Call for Quorum

as you can see 33 memebrs voted via proxy, so we have a quorum

2) Items Subject to a Vote

new and returning members, you can see all applicants here: https://wiki.xmpp.org/web/Membership_Applications_Q2_2020

3) Opportunity for XSF Members to Vote in the Meeting

anyone here who has not voted yet and wants to do so? Membernot is still online. Also accepting votes over other channels

Kev, you around?

I seem to recall that Kev had issues contacting memberbot

I am. Yes, I wasn't able to vote.

(Because xmpp.org won't S2S with my server)

how are you in this MUC then?

How do we actually do voting in person?

Different server.

Kev, you can send me your votes via private message if you want, or email

Memberbot knows me on my personal server, rather than work.

Alex: Or would it be easy to tell memberbot to know me at this address?

Kev, can whitelist also another Jid if you want

Kev, yes

send mme teh Jid and I will add it

There we go.

gottit?

ya, try now please

restarted the bot, just in case

Done.

Thanks Alex.

👍

anyone else? Otherwise I start counting

onay, working on the results then

🥁️

(Thanks for the ping jonas’ too)

Kev, you’re welcome :) ✏

4) Announcement_of_Voting_Results

when you reload teh page at: https://wiki.xmpp.org/web/Meeting-Minutes-2020-06-02#Announcement_of_Voting_Results you can see the results

all new and returning memebrs were accepted. Congrats to everyone

5) Any Other Business?

None here

I need to update memberbot for our next voting to mmae sur ethe latest code on master works. Rigt now its throwing exceptions. I may ask for help here from more experiences python folks ;-)

I think something broke with the update from sleekxmpp

hi

6) Formal Adjournment

I motion that we adjourn

Thanks again, Alex.

Thanks Alex

Seconded

thanks Alex!

agustin cordero, hi

thanks everyone. Will updatethe lists tomorrow morning and send out mmeeting minutes to the list

My python skills are nonexistent

Thanks Alex.

Thanks Alex

i wish i could unsubscribe a thread on the standards list

lovetox, open your sieve filters, match on References/In-Reply-To and discard;

in this case, you probalby want to match on a References header containing DB7PR02MB49561FD17292B534CAE51C60BC8D0@DB7PR02MB4956.eurprd02.prod.outlook.com

filters, yeah such thing exists on my mail client, never needed it until now :D

I’m *nearly* surpirsed that kmail doesn’t have a shortcut for creating a filter based on a thread…