AlexMemberbot is still online for our member meeting today. If you have not voted yet you can still do so
Link MauveIs 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
NeustradamusAlex: after the ending, it will be possible to test the memberbot solution to have no instead of No?
NeustradamusI have sent you code to test in real several months ago...
AlexI cherry picked the code
AlexIt's there already
AlexMaster branch is broken and does not work. I need help to get ithis code fixed. People pushed non working code without testing it✎
AlexMaster branch is broken and does not work. I need help to get ithis code fixed and working ✏
govanifyhas left
govanifyhas joined
krauqhas joined
HolgerSomeone (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
AlexHolger: 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
HolgerAlex: Nah, fine with me. So next round would be early August AFAICS.
AlexYa
HolgerI 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 :-)
AlexJust create your application page now and I will add it to the Q3 application page
AlexOr I ping you when the Q3 page is created
HolgerYou 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
Sevehappy 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 MauveHolger, welcome to the club! :D
HolgerHeh, 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
DebXWoodyHi. 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?
DanielThat doesn't feel right
DanielIt 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
DanielBut in one item
pep.ah right
DanielAccording to the quoted wording
chynahas left
pep.Well the quote suggests there might be multiple items, not multiple things in an <item/>
DanielI 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
DanielWhich the authors probably didn't really know
DanielAnd/or implementations were more broken back then
pep.Right, and different nodes for different keys
lovetoxhas joined
DanielYeah...
DanielNot sure if one would do that today
DanielI was just Reacting to the quote
DanielI didn't check the xep
pep.sure
DebXWoodyThere 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"?
DanielI 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
DanielPersonally I would probably only implemt lookup and not mix in third party key sources
DebXWoodyThere 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
DanielI wouldn't even use the local Keychain that is used for 'regular' pgp
pep.yeah I wouldn't either
DebXWoodyI would :-)
pep.Sure, that's left to the implementation anyway
pep.Is that only for profanity? Any other clients you're pushing that to?
DebXWoodyyes, profanity and a small gtk application.
DebXWoodyOk, I will try to write down some notes and send a mail on the mailinglist.
DanielIsn't the possibility of having multiple keys inviting the same problems that omemo has
DanielAka not being able to do tofu
DanielBut having to resort to BTBV
pep.Daniel, wasn't there talks about a "master key" at Summit?
DanielEven if few people actually do it the fact that it is allowed means I have to have trust ui for that
pep.on the account
pep.That being independent from $e2ee, so you could have OX or OMEMO behind I guess
pep.Maybe somebody(tm) should write this down somewhere
flowOpenPGP keyrings can consists of multiple keys✎
flowOpenPGP keyrings can consist of multiple keys ✏
DebXWoodyI 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
flowthe design question is if the data/metadata node split is still required, given that we could to payload less notifications
flowthe initial version of OX, had no split, then we split and now it looks like we do not need the split
flowsingleton nodes are not relevant here
flowI *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
DebXWoodyThere 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.
DanielSingelton nodes and metadata spilt are two different issues
Zashmetadata split?
DanielThe quoted paragraph is already requesting what should only contain one key
flowDaniel, 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)
flowZash, xep373 § 4.1 and 4.2
DanielThe quoted paragraph says you might get multiple items in return
DanielWhich wouldn't be the case if the node was a singleton
flowDaniel, 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?
flowin any way, you could also simply request only the latest item
DanielThat was the initial question
DanielAnd what I was Reacting to
flowUh, that is multiple pubkeys per item
flowxep373 ex7 uses max_items=1
DanielWhich makes the quoted paragraph even more confusing
flowno wait, that is a request on a data node
flowAhh I guess I see now
flowthat is why the second sentence hints towards using max_items=1
lovetoxflow you could add a paragraph that says singleton node has to be used
DanielEven max_items=1 is just a work around for a proper singleton node
flowwell from a protocol POV there is no need to use a singleton node
govanifyhas left
pep.id="current" etc.?
govanifyhas joined
Danielpep.: yes. Plus max items 1 on the node config
lovetoxflow either your XEP wants to request a single item
DanielNot on request
lovetoxthen it should also enforce singleton node
lovetoxor not then you dont need maxitems=1
DanielI'm not saying the xep is wrong or anything
DanielJust our best practices have changed
DanielWrt to PEP
flowsure, the question is, if older versions of the keyring could be beneficial in some cases
flowI can not answer that, and hence I am a little bit reluctant to specify the singleton node as a must
DanielIsn't the key supposed to be stripped down?
flowDaniel, could you elaborate on max_items being just a work around for proper singleton nodes?
DanielSo what kind of information would change?
Danielflow: well one limits the request the other actually let's the server store only one
DebXWoodyThere is no need to have different versions of the public key.
flowDaniel, right, I say that those are for different use cases
lovetoxflow are you aware whata singleton node is in pubsub?
flowlovetox, yes
alexishas left
DanielIf the intent is to make historic variants of the key available the xep should state that as a feature
DanielOtherwise it comes of like an accident
lovetoxok, so max-items=1 request always the last item, so why would you have a node that stores unlimited items
lovetoxif you always only request one
flowas 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
lovetoxno its not, you looked at other XEPs back at that time and copied what they did
lovetoxnow its a design decision
lovetoxok :)
karoshihas left
ZashNot 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.
DanielIt really doesn't come of as deliberate
DanielBut noted
flowSo 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?
DanielNo
Marandahas left
lovetoxanyway 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
flowI 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
lovetoxits just a server thing to not store unlimited items
paulhas left
paulhas joined
flowsure, I hope servers have a quota mechanism of some sort
ZashThere 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)
flowpep., 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)
DanielCan you give an example for when the historic version of the same key is useful?
flowwith 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
flowDaniel, no, but can you list all examples and show that none of them benefits from prior data? ;)
flowI mean, I can not right now, and it is not unlikely that there is none
flowBut at least in this stage I wouldn't close the door for it
flowAnd 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(?)
DebXWoodyAFAIK, the local Keyring, the keyserver and WKD doesn't provides historic versions of public keys.
flowpep., well actually SCE's design was inspired by what xep373/374 do
pep.flow, I know
DanielRight. 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..
flowDaniel, if I don't know if it is a feature or not, then I would hardly spell it out in the xep
Wojtekhas joined
flowpep., 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.
flowbumping as soon as there is more than one experimental impl is hard, and we should also bump in batches
flowthat is, I would not bump for SCE alone, but if I had to bump, then sure, why not
pep.:/
flowI am not sure why this is disappointing?
flowIf 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
flowI don't think I fear updates
flowBut the fallout of version bumps can be significant
krauqhas joined
flowIn 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
flowbut I would not bump for every "tiny" thing
flowwell for one, as of 5 minutes ago, nobody suggested a bump
flowthen, 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
flowthen, IMHO, the far more important design decission when it comes to OX, is not SCE, but the metadata node split ✏
DebXWoodywhat is SCE?
pep.420
krauqhas left
pep.Stuff that 373 does, but not specific to OX
DebXWoodyOk, I saw,.. but forgot :-)
krauqhas joined
Marandahas joined
karoshihas joined
flowpep., btw, smack has also an OX impl
pep.k
lovetoxflow what do you refering to when you talk about a meta data node split
lovetoxthere is already a metadata node
flowlovetox, right, the question is if we could go instead with payloadless notifications
lovetoxi would not classify this as "far more important"
lovetoxthis was a idea by someone, never impl in any xep and tested
flowwell if we could get rid of the split, then it would reduce the complexity of the protocol somewhat
eevvoorhas left
flowwhich is always desirable IMHO
lovetoxits not complex, we have that split in 20 other xeps
eevvoorhas joined
lovetoxcompletely changing the syntax of how messages are transmitted ( SCE )
flowwell that does not mean that we have to continue that pattern if something better is feasible
lovetoxthat is indeed a big change that should be made rather sooner than later
flowis it really *completely* changing the syntax? IIRC SCE re-uses a lot names from OX
LNJhas left
Mikaelahas left
eevvoorhas left
lovetoxit 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
DebXWoodyNotes I have in mind about OX: https://wiki.xmpp.org/web/Tech_pages/OX
Alexhey 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
Alexhere is our Agenda for today:
https://wiki.xmpp.org/web/Meeting-Minutes-2020-06-02
Alex1) Call for Quorum
Alexas you can see 33 memebrs voted via proxy, so we have a quorum
Alex2) Items Subject to a Vote
Alexnew and returning members, you can see all applicants here:
https://wiki.xmpp.org/web/Membership_Applications_Q2_2020
Alex3) Opportunity for XSF Members to Vote in the Meeting
Alexanyone 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
KevI 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?
KevHow do we actually do voting in person?
KevDifferent server.
AlexKev, you can send me your votes via private message if you want, or email
KevMemberbot knows me on my personal server, rather than work.
KevAlex: Or would it be easy to tell memberbot to know me at this address?
AlexKev, can whitelist also another Jid if you want
Alexwhen you reload teh page at:
https://wiki.xmpp.org/web/Meeting-Minutes-2020-06-02#Announcement_of_Voting_Results
you can see the results
Alexall new and returning memebrs were accepted. Congrats to everyone
neshtaxmpphas joined
Alex5) Any Other Business?
pep.None here
AlexI 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
AlexI think something broke with the update from sleekxmpp
agustin corderohi
Alex6) Formal Adjournment
AlexI motion that we adjourn
GuusThanks again, Alex.
pep.Thanks Alex
ZashSeconded
moparisthebestthanks Alex!
Alexbangs the gavel
pep.agustin cordero, hi
Alexthanks everyone. Will updatethe lists tomorrow morning and send out mmeeting minutes to the list
GuusMy python skills are nonexistent
agustin corderohas left
youhas joined
eevvoorhas left
youhas left
KevThanks 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
mathieuiThanks 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
lovetoxi 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
lovetoxfilters, 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…