Memberbot is still online for our member meeting today. If you have not voted yet you can still do so
Link Mauve
Is Davide Conzon here? If so, do you have a JID which federates with the rest of the Jabber network?
lovetoxhas left
lovetoxhas joined
mukt2has left
govanifyhas left
govanifyhas joined
mukt2has joined
lovetoxhas left
govanifyhas left
govanifyhas joined
paulhas left
paulhas joined
govanifyhas left
govanifyhas joined
karoshihas left
Neustradamus
Alex: after the ending, it will be possible to test the memberbot solution to have no instead of No?
Neustradamus
I have sent you code to test in real several months ago...
Alex
I cherry picked the code
Alex
It's there already
Alex
Master branch is broken and does not work. I need help to get ithis code fixed. People pushed non working code without testing it✎
Alex
Master branch is broken and does not work. I need help to get ithis code fixed and working ✏
govanifyhas left
govanifyhas joined
krauqhas joined
Holger
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?
karoshihas joined
Alex
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
Andrzejhas joined
Holger
Alex: Nah, fine with me. So next round would be early August AFAICS.
Alex
Ya
Holger
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 :-)
Alex
Just create your application page now and I will add it to the Q3 application page
Alex
Or I ping you when the Q3 page is created
Holger
You sound as if I was able to get things done *before* it's almost too late.
Holger
:-) Hopefully my calender will do the trick this time. But thanks a lot!
krauqhas left
Seve
happy to hear that Holger !!!
krauqhas joined
jonas’
Holger, I may also add you to my mental nagging list ;)
jonas’
like I pester Link Mauve all the time about the reapplication ;)
Link Mauve
Holger, welcome to the club! :D
Holger
Heh, glad I'm not alone.
karoshihas left
karoshihas joined
calvinhas joined
karoshihas left
govanifyhas left
govanifyhas joined
karoshihas joined
waqashas left
krauqhas left
mukt2has left
krauqhas joined
govanifyhas left
govanifyhas joined
eevvoorhas joined
krauqhas left
krauqhas joined
lovetoxhas joined
mukt2has joined
krauqhas left
wurstsalathas left
wurstsalathas joined
Shellhas left
krauqhas joined
adiaholic_has left
adiaholic_has joined
Bezihas left
Bezihas joined
krauqhas left
neshtaxmpphas left
andyhas left
krauqhas joined
rionhas left
xeckshas left
xeckshas joined
!XSF_Martinhas left
adiaholic_has left
adiaholic_has joined
!XSF_Martinhas joined
andyhas joined
werdanhas left
neshtaxmpphas joined
krauqhas left
karoshihas left
mukt2has left
mukt2has joined
mukt2has left
mukt2has joined
karoshihas joined
karoshihas left
adiaholic_has left
adiaholic_has joined
mukt2has left
govanifyhas left
govanifyhas joined
mukt2has joined
xeckshas left
xeckshas joined
lovetoxhas left
adiaholic_has left
adiaholic_has joined
karoshihas joined
davidhas left
davidhas joined
govanifyhas left
govanifyhas joined
stpeterhas joined
karoshihas left
mukt2has left
karoshihas joined
mukt2has joined
etahas left
etahas joined
mukt2has left
mukt2has joined
karoshihas left
karoshihas joined
adiaholic_has left
adiaholic_has joined
APachhas left
DebXWoody
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?
Daniel
That doesn't feel right
Daniel
It should probably say that the node should be used and configured as a singleton node
pep.
"most recent item", is that the thing that's not-really-well-defined? (most recently created vs updated?)
pep.
(or is that defined now?)
pep.
Daniel, why?
pep.
I don't think 373 forces a single key per account
Daniel
But in one item
pep.
ah right
Daniel
According to the quoted wording
chynahas left
pep.
Well the quote suggests there might be multiple items, not multiple things in an <item/>
Daniel
I think our knowledge and understanding of PEP was different when the xep was written
Daniel
> 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
Daniel
Which the authors probably didn't really know
Daniel
And/or implementations were more broken back then
pep.
Right, and different nodes for different keys
lovetoxhas joined
Daniel
Yeah...
Daniel
Not sure if one would do that today
Daniel
I was just Reacting to the quote
Daniel
I didn't check the xep
pep.
sure
DebXWoody
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?
pep.
"the [only] client"?
Daniel
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
archas left
archas joined
Daniel
Personally I would probably only implemt lookup and not mix in third party key sources
DebXWoody
There are already same problems with the gajim plugin :-(
pep.
If you don't push your public key on PEP, how are people going to encrypt to you? Am I missing something
Daniel
I wouldn't even use the local Keychain that is used for 'regular' pgp
pep.
yeah I wouldn't either
DebXWoody
I would :-)
pep.
Sure, that's left to the implementation anyway
pep.
Is that only for profanity? Any other clients you're pushing that to?
DebXWoody
yes, profanity and a small gtk application.
DebXWoody
Ok, I will try to write down some notes and send a mail on the mailinglist.
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?
pep.
Sure
flow
the design question is if the data/metadata node split is still required, given that we could to payload less notifications
flow
the initial version of OX, had no split, then we split and now it looks like we do not need the split
flow
singleton nodes are not relevant here
flow
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
DebXWoody
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.
Daniel
Singelton nodes and metadata spilt are two different issues
Zash
metadata split?
Daniel
The quoted paragraph is already requesting what should only contain one key
flow
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)
flow
Zash, xep373 § 4.1 and 4.2
Daniel
The quoted paragraph says you might get multiple items in return
Daniel
Which wouldn't be the case if the node was a singleton
flow
Daniel, I don't have the paragraph in front of me, which one was it again?
Daniel
> 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?
flow
in any way, you could also simply request only the latest item
Daniel
That was the initial question
Daniel
And what I was Reacting to
flow
Uh, that is multiple pubkeys per item
flow
xep373 ex7 uses max_items=1
Daniel
Which makes the quoted paragraph even more confusing
flow
no wait, that is a request on a data node
flow
Ahh I guess I see now
flow
that is why the second sentence hints towards using max_items=1
lovetox
flow you could add a paragraph that says singleton node has to be used
Daniel
Even max_items=1 is just a work around for a proper singleton node
flow
well from a protocol POV there is no need to use a singleton node
govanifyhas left
pep.
id="current" etc.?
govanifyhas joined
Daniel
pep.: yes. Plus max items 1 on the node config
lovetox
flow either your XEP wants to request a single item
Daniel
Not on request
lovetox
then it should also enforce singleton node
lovetox
or not then you dont need maxitems=1
Daniel
I'm not saying the xep is wrong or anything
Daniel
Just our best practices have changed
Daniel
Wrt to PEP
flow
sure, the question is, if older versions of the keyring could be beneficial in some cases
flow
I can not answer that, and hence I am a little bit reluctant to specify the singleton node as a must
Daniel
Isn't the key supposed to be stripped down?
flow
Daniel, could you elaborate on max_items being just a work around for proper singleton nodes?
Daniel
So what kind of information would change?
Daniel
flow: well one limits the request the other actually let's the server store only one
DebXWoody
There is no need to have different versions of the public key.
flow
Daniel, right, I say that those are for different use cases
lovetox
flow are you aware whata singleton node is in pubsub?
flow
lovetox, yes
alexishas left
Daniel
If the intent is to make historic variants of the key available the xep should state that as a feature
Daniel
Otherwise it comes of like an accident
lovetox
ok, so max-items=1 request always the last item, so why would you have a node that stores unlimited items
lovetox
if you always only request one
flow
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
lovetox
no its not, you looked at other XEPs back at that time and copied what they did
lovetox
now its a design decision
lovetox
ok :)
karoshihas left
Zash
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.
Daniel
It really doesn't come of as deliberate
Daniel
But noted
flow
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?
Daniel
No
Marandahas left
lovetox
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
flow
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
lovetox
its just a server thing to not store unlimited items
paulhas left
paulhas joined
flow
sure, I hope servers have a quota mechanism of some sort
Zash
There was a brief period after adding support for multiple items in Prosody and before adding limits where it it could store unlimited items.
pep.
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)
flow
pep., because in most cases you want the most recent version of the key
pep.
Does max_items=1/singleton have anything to do with this?
pep.
(sorry I'm not sure I followed all of the above)
Daniel
Can you give an example for when the historic version of the same key is useful?
flow
with either of them you get the most recent version
pep.
flow, ah so a client can request max_items=1 for the "latest" but the server storing more?
LNJhas left
flow
Daniel, no, but can you list all examples and show that none of them benefits from prior data? ;)
flow
I mean, I can not right now, and it is not unlikely that there is none
flow
But at least in this stage I wouldn't close the door for it
flow
And again, I don't see any harm, since servers have incentive to purge old items anyway
pep.
There's gonna be an update of 373 at some point anyway, for SCE :p
pep.
Or maybe 374 rather(?)
DebXWoody
AFAIK, the local Keyring, the keyserver and WKD doesn't provides historic versions of public keys.
flow
pep., well actually SCE's design was inspired by what xep373/374 do
pep.
flow, I know
Daniel
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
pep.
But now that we have a SCE..
flow
Daniel, if I don't know if it is a feature or not, then I would hardly spell it out in the xep
Wojtekhas joined
flow
pep., sure, but at the current stage of SCE would switching OX to SCE provide any benefit and justify the version bump?
pep.
Might as well bump while there isn't many impls.
flow
bumping as soon as there is more than one experimental impl is hard, and we should also bump in batches
flow
that is, I would not bump for SCE alone, but if I had to bump, then sure, why not
pep.
:/
flow
I am not sure why this is disappointing?
flow
If we have learned one thing, then it is that version bumps should be taken carefully, and coordinated
pep.
Becaue I never get why people fear updates
pep.
It's just a thing that happens and we deal with it
flow
I don't think I fear updates
flow
But the fallout of version bumps can be significant
krauqhas joined
flow
In fact I am happy to bump, esp. in the 'experimental' stage
LNJhas joined
pep.
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
flow
but I would not bump for every "tiny" thing
flow
well for one, as of 5 minutes ago, nobody suggested a bump
flow
then, the far more important design decission when it comes to OX, is not SCE, but the metadata node split✎
govanifyhas left
bearhas left
govanifyhas joined
flow
then, IMHO, the far more important design decission when it comes to OX, is not SCE, but the metadata node split ✏
DebXWoody
what is SCE?
pep.
420
krauqhas left
pep.
Stuff that 373 does, but not specific to OX
DebXWoody
Ok, I saw,.. but forgot :-)
krauqhas joined
Marandahas joined
karoshihas joined
flow
pep., btw, smack has also an OX impl
pep.
k
lovetox
flow what do you refering to when you talk about a meta data node split
lovetox
there is already a metadata node
flow
lovetox, right, the question is if we could go instead with payloadless notifications
lovetox
i would not classify this as "far more important"
lovetox
this was a idea by someone, never impl in any xep and tested
flow
well if we could get rid of the split, then it would reduce the complexity of the protocol somewhat
eevvoorhas left
flow
which is always desirable IMHO
lovetox
its not complex, we have that split in 20 other xeps
eevvoorhas joined
lovetox
completely changing the syntax of how messages are transmitted ( SCE )
flow
well that does not mean that we have to continue that pattern if something better is feasible
lovetox
that is indeed a big change that should be made rather sooner than later
flow
is it really *completely* changing the syntax? IIRC SCE re-uses a lot names from OX
LNJhas left
Mikaelahas left
eevvoorhas left
lovetox
it breaks that what i meant, it does not really matter by how much
LNJhas joined
krauqhas left
krauqhas joined
uhoreghas joined
krauqhas left
krauqhas joined
karoshihas left
karoshihas joined
flowhas left
govanifyhas left
govanifyhas joined
govanifyhas left
govanifyhas joined
govanifyhas left
govanifyhas joined
lovetoxhas left
krauqhas left
bearhas joined
alameyohas left
Nekithas left
krauqhas joined
mukt2has left
Nekithas joined
mukt2has joined
papatutuwawahas joined
krauqhas left
krauqhas joined
APachhas joined
Dele Olajidehas joined
alameyohas joined
lovetoxhas joined
archas left
archas joined
eevvoorhas joined
Marandahas left
Marandahas joined
eevvoorhas left
eevvoorhas joined
Dele Olajidehas left
krauqhas left
krauqhas joined
flowhas joined
flowhas left
neshtaxmpphas left
Nekithas left
mukt2has left
goffihas joined
karoshihas left
karoshihas joined
flowhas joined
Bezihas left
Bezihas joined
DebXWoody
Notes I have in mind about OX: https://wiki.xmpp.org/web/Tech_pages/OX
Alex
hey guys, anyone ready for our member meeting?
archas left
archas joined
archas left
jonas’is
archas joined
Zash
!
jonas’also forgot about it, but I’m still ready!
Alexbangs the gavel
Alex
here is our Agenda for today:
https://wiki.xmpp.org/web/Meeting-Minutes-2020-06-02
Alex
1) Call for Quorum
Alex
as you can see 33 memebrs voted via proxy, so we have a quorum
Alex
2) Items Subject to a Vote
Alex
new and returning members, you can see all applicants here:
https://wiki.xmpp.org/web/Membership_Applications_Q2_2020
Alex
3) Opportunity for XSF Members to Vote in the Meeting
Alex
anyone here who has not voted yet and wants to do so? Membernot is still online. Also accepting votes over other channels
jonas’
Kev, you around?
jonas’
I seem to recall that Kev had issues contacting memberbot
Kev
I am. Yes, I wasn't able to vote.
Mikaelahas joined
Kev
(Because xmpp.org won't S2S with my server)
jonas’
how are you in this MUC then?
Kev
How do we actually do voting in person?
Kev
Different server.
Alex
Kev, you can send me your votes via private message if you want, or email
Kev
Memberbot knows me on my personal server, rather than work.
Kev
Alex: Or would it be easy to tell memberbot to know me at this address?
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
Alex
all new and returning memebrs were accepted. Congrats to everyone
neshtaxmpphas joined
Alex
5) Any Other Business?
pep.
None here
Alex
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 ;-)
Bezihas left
Bezihas joined
agustin corderohas joined
Alex
I think something broke with the update from sleekxmpp
agustin cordero
hi
Alex
6) Formal Adjournment
Alex
I motion that we adjourn
Guus
Thanks again, Alex.
pep.
Thanks Alex
Zash
Seconded
moparisthebest
thanks Alex!
Alexbangs the gavel
pep.
agustin cordero, hi
Alex
thanks everyone. Will updatethe lists tomorrow morning and send out mmeeting minutes to the list
Guus
My python skills are nonexistent
agustin corderohas left
youhas joined
eevvoorhas left
youhas left
Kev
Thanks Alex.
Shellhas left
Shellhas joined
karoshihas left
karoshihas joined
neshtaxmpphas left
archas left
archas joined
archas left
archas joined
govanifyhas left
govanifyhas joined
etahas left
etahas joined
archas left
archas joined
govanifyhas left
govanifyhas joined
neshtaxmpphas joined
Yagizahas left
j.rhas left
j.rhas joined
mathieui
Thanks Alex
j.rhas left
j.rhas joined
krauqhas left
Tobiashas left
papatutuwawahas left
Tobiashas joined
j.rhas left
j.rhas joined
Mikaelahas left
Andrzejhas left
karoshihas left
adiaholic_has left
adiaholic_has joined
karoshihas joined
mukt2has joined
Shellhas left
Shellhas joined
archas left
archas joined
matkorhas left
krauqhas joined
Tobiashas left
goffihas left
Shellhas left
Shellhas joined
matkorhas joined
lovetox
i wish i could unsubscribe a thread on the standards list
adiaholic_has left
jonas’
lovetox, open your sieve filters, match on References/In-Reply-To and discard;
adiaholic_has joined
jonas’
in this case, you probalby want to match on a References header containing DB7PR02MB49561FD17292B534CAE51C60BC8D0@DB7PR02MB4956.eurprd02.prod.outlook.com
lovetox
filters, yeah such thing exists on my mail client, never needed it until now :D
jonas’
I’m *nearly* surpirsed that kmail doesn’t have a shortcut for creating a filter based on a thread…