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?
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 ✏
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?
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
HolgerAlex: Nah, fine with me. So next round would be early August AFAICS.
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!
Sevehappy to hear that Holger !!!
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.
"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.I don't think 373 forces a single key per account
DanielBut in one item
DanielAccording to the quoted wording
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
DanielNot sure if one would do that today
DanielI was just Reacting to the quote
DanielI didn't check the xep
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
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?
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
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
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?
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
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
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?
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
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?
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
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
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
flowIn fact I am happy to bump, esp. in the 'experimental' stage
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✎
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.Stuff that 373 does, but not specific to OX
DebXWoodyOk, I saw,.. but forgot :-)
flowpep., btw, smack has also an OX impl
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
flowwhich is always desirable IMHO
lovetoxits not complex, we have that split in 20 other xeps
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
lovetoxit breaks that what i meant, it does not really matter by how much
Dele Olajidehas joined
Dele Olajidehas left
DebXWoodyNotes I have in mind about OX: https://wiki.xmpp.org/web/Tech_pages/OX
Alexhey guys, anyone ready for our member meeting?
jonas’also forgot about it, but I’m still ready!
Alexbangs the gavel
Alexhere is our Agenda for today:
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:
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.
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?
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