jonaswKev, I heard swift can do XEP-0055 (Jabber Search). Does it support RSM-based pagination and if so, where is the RSM element included? And if not, do you think RSM would be a reasonable way to do that and if so, where would the RSM element go?
Nekithas joined
alexishas left
Dave Cridlandhas left
alexishas joined
danielhas left
efrithas left
Guushas left
alexishas left
alexishas joined
Guushas left
rishiraj22has left
Dave Cridlandhas left
Dave Cridlandhas joined
rishiraj22has joined
j.rhas joined
j.rhas joined
Guushas left
Guushas left
Guushas joined
danielhas joined
Zashhas left
Timhas joined
blablahas left
blablahas joined
rionhas left
KevIt does 55, I don't believe we RSM.
jonaswI’d very much like to not return 4000 entries in one reply though
KevI don't think 55 supports RSM does it?
jonaswdoes *anything* before XEP-0059 "support" RSM?
jonaswoh look at this, XEP-0059 even uses XEP-0055 as example for RSM
jonaswand it’s allegedly used with disco#items
jonasw(even though I haven’t seen that in the wild with MUC services yet)
goffiI though RSM could be applied anywhere without need to specify it. This this was we answered to me when I asked for disco in the past.
jonasw(AFAICT)
goffiI thought RSM could be applied anywhere without need to specify it. This this what was answered to me when I asked for disco in the past.
rionhas left
ibikkhas joined
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Zashhas left
waqashas left
rionhas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
mikeaohas joined
jubalhhas joined
la|r|mahas joined
blablahas left
blablahas joined
rishiraj22has left
edhelashas left
jonaswis there any standard for something like XEP-0055 (Jabber Search) but for MUCs? (not disco#items)
Valerianhas joined
ibikkhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
xnyhpshas left
edhelashas left
xnyhpshas joined
danielhas left
marchas left
blablahas left
blablahas joined
tahas joined
Steve Killehas left
Steve Killehas left
Zashhas left
Steve Killehas joined
jubalhhas joined
j.rhas left
j.rhas joined
mikaelahas joined
goffijonasw: what prevent you from using XEP-0055 with MUC ? It returns jid and can use data form for any extra data you wish.
andyhas joined
Valerianhas left
Valerianhas joined
marmistrzhas joined
Andrew Nenakhovhas left
lskdjfhas joined
Andrew Nenakhovhas joined
andyhas left
andyhas joined
lorddavidiiihas left
lorddavidiiihas left
ralphmhas joined
Valerianhas left
Valerianhas joined
muppethhas joined
SaltyBoneshas left
marchas left
Andrew Nenakhovhas left
Chobbeshas joined
winfriedhas joined
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
muppethhas joined
SaltyBoneshas left
Andrew Nenakhovhas joined
Lancehas joined
danielhas joined
Lancehas joined
lnjhas left
Zashhas joined
jonaswgoffi: sure, I can re-use bits of 55 but I was wondering whether there was any precedent for that
ralphmWho's here and what topics do you prefer to discuss today?
GuusI'm here
MattJI'm here
MattJWe can discuss the next steps for the results of the survey
GuusAlso: gdpr compliance?
ralphmCool. Maybe revisit the GDPR discussion
ralphmThat should fill most of the meeting.
Guusalso: did anyone hear from Martin in the last few weeks?
Guushe didn't renew XSF membership - I wonder if that was intentional.
ralphmNot since May 3.
MattJLikewise
vanitasvitaehas left
ralphmWhile there's no requirement to be a Member to be a Director, I share your curiosity.
ralphm2. Survey.
MattJThe survey "officially" ended yesterday, with 24 responses
MattJWhich I don't consider too bad, I was expecting worse
vanitasvitaehas left
alexishas joined
MattJI haven't had time to do anything with the responses, barely look at them. I propose I do that and share a Google Spreadsheet over email, and we can discuss in more detail next week?
MattJand if anyone has specific things they'd like to discuss (e.g. points raised) we can add those to the agenda
GuusSounds good to me.
ralphmAgreed
ralphm3. GDPR
ralphmSo there a few things here and maybe we should split them.
vanitasvitaehas left
ralphm1) the XSF's compliance
ralphm2) the proposed XEP
MattJAgreed, sensible
Guusthis feels like a beast: can we further split them?
Andrew Nenakhovhas joined
ralphmGo aheah
GuusI would if I knew how 🙂
ralphmWell, there are a few things on 1)
vanitasvitaehas left
ralphm- The foundation membership
ralphm- The e-mail archives
ralphm- The XMPP server with its rooms and archives
ralphmshout if you can think up more items
Guusthat is: items where we potentially store private information?
Guusdo we use cookies on the website?
MattJs/private/personal/
vanitasvitaehas left
ralphmpersonal, indeed
GuusMatt just asked for everyone's mail address in a nice (but one-off) poll
Zashhas left
MattJI also stated how they would be used, and that they would not be kept permanently
ralphmWe can probably continue doing all the things we do, but we have to document what we process, for what reason, etc.
Guusok, stepping back: I'm unsure what exactly the end-goal is (other than 'be compliant' which I don't know what that entails)
Zashhas left
ralphmAnd we need to revisit/reinstate the Privacy Policy that was written in 2008
vanitasvitaehas left
Guus(we've got personal data in the wiki too, probably - and there's author information in each XEP)
ralphm(for a discussion on this, see the archives of this room -1W)
ralphmI also thought about the Wiki indeed, and the XEP
Zashhas left
ralphms
GuusI was knee-deep in water at the time, have not read back 😕
Zashhas left
ralphmBasically we had a PP for both jabber.org and xmpp.org, but with all the website transitions it is no longer available
ralphmwe have it somewhere still, though
Zashhas left
vanitasvitaehas left
Zashhas left
Guusokay, say we are able to restore that: is there someone available that can tell if it is GDPR compliant?
Zashhas left
alexishas joined
rtq3has joined
Zashhas left
Andrew Nenakhovhas joined
ralphmFirst of all, no-one probably is 100% compliant, and you will know when somebody has sued you
MattJNobody can really say for certain, there are too many grey areas - however I'm really not worried
efrithas joined
vanitasvitaehas left
MattJPretty much all we have is public, and given by people knowingly
Zashhas left
ralphmThe focus points will be documentation, the pp, and possibly retention, and information and deletion requests.
MattJThere may be hidden things like server logs, but if we don't keep those for "too long", we "should" be ok
Guussure, and although I assume that that's ok, that's not based on any knowledge of gdpr on my part.
flowhas left
flowhas joined
ralphmWell, I've been involved professionally, so I know a few things
alexishas left
Guusgood. Tag, you're it. 🙂
alexishas joined
vanitasvitaehas left
ralphmI think we should also involve Alex
ralphmhaha, good one
ralphmSounds like MattJ knows things, too
jubalhhas joined
Guusmaybe we should task a certain group of people with doing an inventory of our data, and make recommendations?
MattJiteam?
vanitasvitaehas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Guusor an adhoc one (Ralph, Alex, the people that have bene working on the XEP)
vanitasvitaehas left
GuusI'd be happy to do leg-work, but I need someone to tell me what to do.
vanitasvitaehas left
MattJWell in the case I gave (server logs), that's something that requires iteam - an inventory of running services and what they collect
vanitasvitaehas left
GuusRIght - that's why I suggest to have a SIG or WT with people like yourself that know what to look for. A small group of people that maintains an overview, and coordinates efforts with other WTs and board.
ralphmI think a work team
vanitasvitaehas left
GuusThis all might be me being overcautious, based on a lack of understanding - if you see a way to shorttrack things, that's also fine by me.
ralphmso indeed, you need iteam for inventory, someone the leads the effort, and in any case the Secretary should be involved
ralphmThere are probably helpful 10-step plans out there, but I haven't looked at that at all
GuusI'm unsure if we can volunteer the Secretary for a WT, but we can at least ask the WT to inform the Secretary. 🙂
GuusRalph, would you mind spearheading that team?
vanitasvitaehas left
Guusyou seem to have a good grasp on tings.
Guusthings*
ralphmOn the involvement of the Secretary, probably yes we can volunteer him:
ralphmSection 6.7 Secretary. Unless provided otherwise by a resolution adopted by the Board of Directors, the Secretary shall keep accurate records of the acts and proceedings of all meetings of the Members and Directors. The Secretary shall give all notices required by law and by these Bylaws. He or she shall mail to all Directors within thirty (30) days after each meeting copies of all said actions and minutes of said proceedings. In addition, the Secretary shall have general charge of the corporate books and records and of the corporate seal, and he or she shall affix, or attest the affixing of, the corporate seal to any lawfully executed instrument requiring it. The Secretary shall have general charge of the membership records of the Corporation and shall keep, at the principal office of the Corporation, a record of the Members showing the name, address, telephone number, facsimile number and electronic mail address of each Member. The Secretary shall sign such instruments as may require his or her signature and, in general, shall perform all duties as may be assigned to him or her from time to time by the Chair, the Executive Director or the Board of Directors.
ralphmNote the part on 'corporate books and records'
vanitasvitaehas left
GuusLet's aim to have a mission statement / member list ready for next week, so that we can procedurally establish the team.
ralphmBut of course we should ask Alex how he can help us on this
ralphmseems reasonable
ralphmOk then, I guess we should move on to the other part
ralphm4. GDPR XEP
Guus(I don't have much more time to spend today)
ralphmOh, it is that time already.
Guusas for the XEP: what are downsides of publishing such a XEP?
ralphmWell, in principle it is unclear if the XSF should publish a specification that would give guidelines in direct relation to the GDPR
ralphmI'm not familiar with US law, but the concept of Legal Advise is a apparently a Thing
ralphmAdvice even
Guuswhat is "giving legal advice" ? Does publishing that XEP qualify?
ralphmWell, in the state that it was in last week, there wasn't much in there yet
ralphmI haven't checked since
MattJIt's a combination of factors - for example, in some places you need to be licensed to practice law
ralphmBut I think it is more important for any such document to provide general guidelines in terms of knowing what you process and what things to take into account to ensure privacy for your service, and leave the rest up to people who Know Things (typically lawyers) for actual compliance
MattJIt's a stretch, but if it was taken as the XSF is giving legal advice without being qualified to do so, that's illegal in those $some_places
muppethhas joined
GuusMy perspective is that I'd prefer to help the XMPP community by providing information, as long as a) we're not opening ourselves up to liability, and b) we can somehow be reasonably certain that we're not spreading misinformation.
MattJand separate from this issue, but similar - someone could try to blame the XSF if they followed published advice but got fined under GDPR
GuusThere's a huge gap between practice law and give information
efrithas left
ralphmRight, so as Peter has suggested, and I agree with, I'd like any such document to be actual best practices, not related to any particular legislation
ralphmAlso, I'm sure I used 4 two times, so whoever is making the Minutes (*wink*) should take that into account
vanitasvitaehas left
Guushas left
Zashhas left
vanitasvitaehas left
Guushas left
Guushas left
alexishas left
alexishas joined
lskdjfhas joined
Guushas left
vanitasvitaehas left
la|r|mahas joined
vanitasvitaehas left
vanitasvitaehas left
lumihas joined
vanitasvitaehas left
muppethhas left
muppethhas joined
vanitasvitaehas left
vanitasvitaehas left
rtq3has left
blablahas left
blablahas left
blablahas joined
vanitasvitaehas left
mikaelahas left
muppethhas left
vanitasvitaehas left
muppethhas joined
ibikkhas joined
rtq3has joined
mikaelahas joined
muppethhas joined
muppethhas joined
alexishas left
alexishas joined
andyhas joined
efrithas joined
jubalhhas joined
mimi89999has joined
Valerianhas left
Valerianhas joined
Valerianhas left
Valerianhas joined
tuxhas joined
danielhas left
ibikkhas left
rishiraj22has left
muppethhas joined
muppethhas left
jubalhhas joined
j.rhas joined
j.rhas joined
rishiraj22has joined
Guushas left
goffiwould not it be possible for the XSF to hire some legal advisor to create a document? I mean this is expensive for a single project, but if XSF is hiring one describing general helping document, we could do some kind of crowdfunding among XMPP community. Maybe FSF have some helpful contacts
goffi
Guushas left
jubalhhas joined
vanitasvitaehas left
jerehas joined
Zashhas left
Dave Cridlandhas left
Dave Cridlandhas joined
rtq3has left
lorddavidiiihas left
Zashhas left
Dave Cridlandhas left
flowI'm pretty sure I've asked years ago on standards@ if an IQ send to the own bare JID is semantically equivalent to the same stanza without a 'to' attribute, but my google-fu is not strong enough to find that thread again
KevThe answer is "yes". Also "no".
KevIt is the same, except that there's some odd text still lying around that hints otherwise, like that roster queries must be no-JID (rather than bare-JID), maybe?
flowI feared that this was the conclusion back then
ZashCan we have that odd text accidentally dropped down a well?
flowwould a MAM IQ to the own bare JID be equal to the same query without to attribute?
Kevflow: Yes.
flow*without 'to' attribute
MattJAs far as I'm concerned, and Prosody is concerned, yes
ZashProsody treats to=own bare jid identical to missing to
danielCan we just get rid of missing to and missing froms
ZashIn fact, it removes the 'to' and uses its absense for security related things
blablahas left
Zashdaniel: make them mandatory always, like on s2s?
flowZash, interesting, care to elaborate on these "security related things" that you get when you handle stanzas without 'to'?
MattJdaniel, in a way I prefer it, you know this stanza isn't going anywhere
danielZash: yes. If you want to send something to your account you have to address it
danielAnd vice versa
ibikkhas joined
MattJflow, these stanzas are typically special in most XEPs (from user to their own account), they are privileged and Prosody handles them separately from normal stanzas that are to be routed
rishiraj22has left
waqashas joined
j.rhas joined
j.rhas joined
Zashdaniel: I want the opposite
MattJand we normalize the to/from to 'missing to' so that there can't be any JID normalization accidents in modules
ZashAnd then it bites Ge0rG right in the carbons
danielMattJ: but if you address your server the stanza isn't going anywhere either...
danielFor some definition of not going anywhere
KevMattJ: Do you do some sort of NAT to get the right address injected when you reply then?
KevBecause replying to a to=bare stanza with missing to isn't ok.
MattJKev, 'from' is always set, and that's what we reply to
MattJand 'to' is not needed on c2s streams
KevBecause replying to a to=bare stanza with missing from isn't ok.
Zashto and from should default to the entities on each end of c2s streams, ie the client and their account
MattJObviously from and to are swapped in any reply
KevOne has to be fairly careful when claiming anything is obvious, when talking about this ;)
Guushas left
Guushas left
jonaswKev, why is it not ok? missing from is identical to comes from bare jid, isn’t it?
jonaswI am /pretty/ sure that I’ve seen servers which do not do that.
jonaswI have ugly workarounds for that
jonaswah, no I am at the wrong place in the text
ZashWhowhere?
jonasw
3. When the server generates a stanza from the server for delivery
to the client on behalf of the account of the connected client
(e.g., in the context of data storage services provided by the
server on behalf of the client), the stanza MUST either (a) not
include a 'from' attribute or (b) include a 'from' attribute
whose value is the account's bare JID (<localpart@domainpart>).
jonaswKev, so, there’s no NAT needed, just don’t emit the @from in the reply ^
Guushas left
danielZash: hoover?
Kevjonasw: Yes, but if it's a reply to a stanza the client sent, the server must swap the to/from.
Zash🕴
KevYou can't, as a server, receive a stanza that is to=bare JID, and reply with no from.
MattJKev, says?
ZashThe holy text.
Alexhas joined
KevMattJ: 6120, somewhere.
Keve.g. for error stanzas "The error stanza SHOULD simply swap the 'from' and 'to' addresses from the generated stanza"
MattJThat's a stretch to say it applies to all stanzas, as you're saying
KevYes, that was just the quickest thing to find.
MattJI think the text jonasw pasted is pretty clear that the server has two valid options
KevYes, but not clear that both are always right.
tahas joined
MattJThen that text might as well be removed, and let the text you remember specify what the 'from' should be
lumihas left
jonaswKev, ok, then I found a server with a bug.
Guushas left
jonaswbecause that’s why I needed workarounds (because servers did exactly that)
jonaswah, well
jonaswif the swap is only a SHOULD, I can see this to be an exception
Guushas left
KevI can't find the odd text about rosters now on a quick search either, so there's clearly text I'm failing to find.
Guushas left
Guushas left
lnjhas joined
Kevjonasw: We have handling too, in https://github.com/swift/swift/blob/master/Swiften/Queries/Request.cpp#L79
Kev(In fact, we have further workarounds for ejabberd issues where they used to reply with full JIDs)
jonaswoh yes
jonaswI love those
Steve Killehas left
Steve Killehas left
Wiktorhas joined
Guushas left
Steve Killehas joined
goffihas left
valohas joined
valohas joined
jubalhhas joined
alacerhas left
alacerhas joined
jjrhhas left
muppethhas joined
muppethhas joined
rtq3has joined
Neustradamushas left
j.rhas joined
koyuhas joined
koyuhas left
Alexhas left
jerehas left
jerehas joined
alexishas left
Alexhas joined
alexishas joined
alexishas left
alexishas joined
koyuhas joined
koyuhas joined
koyuhey, i just setup my own xmpp server
SaltyBoneshas left
KevWelcome to the cool club. Or something.
MattJ:)
koyuyeah, i just can't get omemo to work on ejabberd
WiktorAs far as I remember omemo is disabled by default in ejabberd, but you may check in ejabberd room
jonasw17:04:14 <--- You (jonasw) left the room (the MUC server is not responding)
17:07:17 ---> You (jonasw) joined the room
jonasw(or maybe it was just the link between us. who knows)
Valerianhas left
Valerianhas joined
Lancehas joined
Lancehas joined
jubalhhas joined
SaltyBoneshas left
SaltyBoneshas left
SaltyBoneshas left
rtq3has left
jjrhhas left
koyuhas left
jjrhhas left
jjrhhas left
rtq3has joined
jubalhhas left
jjrhhas left
lskdjfhas joined
lskdjfhas joined
lskdjfhas joined
jjrhhas left
lskdjfhas left
ibikkhas joined
SamWhitedhas left
vanitasvitaehas left
la|r|mahas joined
la|r|mahas joined
Guushas left
Guushas left
Tobiashas joined
Tobiashas joined
vanitasvitaehas left
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas joined
la|r|mahas left
mikeaohas left
jerehas left
Lancehas joined
vanitasvitaehas left
Lancehas joined
tahas left
tahas joined
andyhas left
jerehas joined
Dave Cridlandhas left
SaltyBoneshas left
andyhas joined
j.rhas joined
Guushas left
tahas joined
Valerianhas left
Valerianhas joined
UsLhas joined
mikaelahas joined
Dave Cridlandhas left
Dave Cridlandhas joined
Valerianhas left
Valerianhas joined
vanitasvitaehas left
rtq3has left
Dave Cridlandhas left
Dave Cridlandhas joined
vanitasvitaehas left
j.rhas joined
Alexhas left
andyhas left
Valerianhas left
vanitasvitaehas left
Dave Cridlandhas left
Dave Cridlandhas joined
Zashhas left
vanitasvitaehas left
rtq3has joined
vanitasvitaehas left
vanitasvitaehas left
jubalhhas joined
rtq3has left
vanitasvitaehas left
vanitasvitaehas left
vanitasvitaehas left
vanitasvitaehas left
vanitasvitaehas left
vanitasvitaehas left
vanitasvitaehas left
vanitasvitaehas left
vanitasvitaehas left
la|r|mahas joined
vanitasvitaehas left
Tobiashas left
Tobiashas joined
Dave Cridlandhas left
Dave Cridlandhas joined
Dave Cridlandhas left
jjrhhas left
Dave Cridlandhas joined
jubalhhas left
j.rhas joined
MattJSo MIX proxy JIDs... if someone creates a MIX channel that is <1023 bytes>@mix.example.com... what happens to the userid part?
jonasw"boom"
jonaswI imagine servers simply wouldn’t allow that
MattJSo how long is the generated id?
jonaswprobably service-defined
MattJIt's such a hack
jonaswdo you have a better suggestion?
MattJWell instead of overloading what should be an opaque identifier why not re-use a mechanism that is already in the protocol as a secondary identifier behind bare JIDs?
rtq3has joined
jonaswbecause that leads to the same situation
jonaswjust in a different part and with different moving parts
jonaswwith Kevs variant (1), the multiple pieces are in the nodepart, with variant (2) the multiple pieces are in the resource
jonaswso both are bad w.r.t. that
jonaswone way out of that would be to use $service-wide-user-id@$service-domain/$resource instead (so the MIX identifier wouldn’t be part of the node at all). but that requires to have the JID of the MIX inside the relevant stanzas
MattJAll existing routing, libraries and... everything already knows how to correctly split a JID
jonaswtrue
jonaswand I think that the semantics assumed with "bare JID" work better with variant (1) than with variant (2)
SamWhitedhas left
MattJTrust me, someone will want to implement some higher-level logic to know which messages are associated with a MIX channel
MattJExcept with variant (1) you can't really do that
MattJYou have to know it *is* a MIX channel, and that you have to strip the bit before the #
MattJBlock a MIX channel? Ok, but messages from participants would still reach you
jonaswand other people want to have high-level logic to konw which messages are associated with a MIX channel occupant.
ibikkhas joined
MattJany kind of filtering or logic based on the channel JID now almost always will need to be adapted to look for the # part
vanitasvitaehas left
jonaswwe should’ve followed email and allowed multiple @s in addresses
MattJYes, that would really have helped... :)
MattJso now nobody knows what an email address actually is, but everyone has their own idea that's good enough for them
MattJPretty much what's going on here, to be honest :)
MattJThe # is the extra @ to the entities that can see it
MattJTo the others, it's not and it's weird
jonaswthe variant (2) would make things worse than MUC actually
MattJCan you (or someone) lay down the reasons for that?
jonaswdidn’t I?
jjrhhas left
MattJI didn't see if you did, /me checks
jonaswbut the point which I just realized is, that with variant (2), there’s no single JID which will ever occur in a message identifies an occupant
jonaswso if you wanted to filter all messages from an occupant, you’d have to know that they’re MIX messages
jonaswto split them correctly
jonaswkinda the same issue you describe with MIX channels in variant (1)
MattJHmm, what do you mean?
jonaswfor example, presence
jerehas joined
jonaswand avatar hashes
jonaswI keep those in a cache, usually keyed by the bare JID
jonaswwhich I can’t do for MUC, I have to use the full JID, but that’s okay
jonasw(I actually have to break layers to detect that a presence is MUC related at that point)
jonaswnow with MIX, it’s worse, because not only do I have to check that it’s MIX-related, I also have to use a non-RFC6122 splitting function on the JID to determine the cache key
jonaswi.e. do determine the identity this JID belongs to
jonaswreally, the same thing you described earlier, just with occupants instead of channels
MattJRight
jonaswI think your issue is more server-side and my issue is more client-side, actually, and that might be why we see them strongly each
jonasw(clients may be more interested in occupant identities, while servers may be more interested in channel identities because that’s the granularity they work on)
MattJSo how do you know it's a MIX message and you need to split the nodepart? Payload?
jonaswyes
mikaelahas left
jonaswStrawman proposal:
- proxy JID does not contain the MIX channel, but only the proxy identifier in the nodepart
- resource as usual
- MIX channel is identified in payload, e.g. <message from="ac2c37a7-10a6-4cd7-a708-4973d5d365f8@mixservice.domain.example" to="user@other.example" type="groupchat"><mix channel="..."/></message>
Dave Cridlandhas left
Dave Cridlandhas joined
jonaswStrawman proposal:
- proxy JID does not contain the MIX channel, but only the proxy identifier in the nodepart
- resource as usual
- MIX channel is identified in payload, e.g. <message from="ac2c37a7-10a6-4cd7-a708-4973d5d365f8@mixservice.domain.example/client-resource" to="user@other.example" type="groupchat"><mix channel="..."/></message>
MattJHeh, part of me wants to dislike that, but I prefer it
MattJI feel like the security aspects need to be investigated here though
jonaswthat’s not how straw-mans are supposed to work
jonaswwhich part exactly?
MattJWell you need to verify the service in every case, I think
jonaswwhat do you mean exactly?
MattJOtherwise I register mattj#rocks@jabber.org and send you a message wih a MIX payload
Andrew Nenakhovhas left
jonaswand then?
Andrew Nenakhovhas joined
MattJDon't know, currently I got as far as "your client breaks"
jonaswthe client or server would drop it because it doesn’t know about a MIX rocks@jabber.org
jonaswjust like we currently drop type="groupchat" from MUCs we don’t know.
MattJRight, the whole "participant's server needs to know MIX" thing
Andrew Nenakhovhas joined
jonaswat least we’re honest about it this time (not with MUC, where servers were blindsided by interesting interaction sideeffects e.g. when changing nicknames)
jonaswat least we’re honest about it this time (not like with MUC, where servers were blindsided by interesting interaction sideeffects e.g. when changing nicknames)
MattJI like your straw-man because it opens up the possibility for a user on a MIX service to have a stable JID across multiple channels
Guushas left
jonaswI’m not sure that’s a good thing
jonaswbut mmm, it could be
jonaswit makes it more difficult for MIX services though
Guushas left
Guushas left
MattJHow so?
jonaswwhen I send a message to ac2c37a7-10a6-4cd7-a708-4973d5d365f8@mixservice.domain.example, they need to verify that I share a channel with them
jonasw(or may need to, depending on the service policies; but I assume that this is how most services will want to operate)
jonaswhm, or we require <mix channel="…"/> elements even in non-groupchat messages
jonaswthen the sender would assert through which channel this message shall be "tunneled" and the server would not have to form the intersection of both channel lists
jonaswquestion is whether that’s reasonable
SaltyBoneshas left
MattJTotally if you ask me
jonaswso I’ll post that to the list now
MattJVariant 3! Thanks :)
MattJhas left
Guushas left
alacerhas left
jerehas joined
Tobiashas left
Tobiashas joined
jonaswAdvantages:
- No re-write of resources
- Bare JID refers to occupant identity (good for clients)
- Servers can simply filter on message/mix@channel
- Opens up the possibility of re-using the same proxy JID for the same occupant across different channels (may be useful in some deployments, via MattJ)
Disadvantages:
- All (including 1:1) stanzas exchanged between occupants require the <mix channel="…"/> element for MIX channels to be able to easily route them
- Entities filtering on MIX channel identity still need to know about MIX (and the <mix channel="…"/> element)
jonaswdid I miss something?
rtq3has left
rtq3has joined
vanitasvitaehas left
jonaswsent
MattJSorry, lgtm
vanitasvitaehas left
MattJhas left
Lancehas joined
peterhas joined
Lancehas joined
Dave Cridlandhas left
Dave Cridlandhas joined
efrithas left
efrithas joined
vanitasvitaehas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
KevI'll reply properly onlist in the morning, but now you need to do DPI to be able to routing in your client, because the routing information is no longer in the header? That's terribly unpleasant.
KevI'll reply properly onlist in the morning, but now you need to do DPI to be able to do routing in your client, because the routing information is no longer in the header? That's terribly unpleasant.
Kevi.e. I think option 3 is the worst of the three.
Kev(And possibly worse, your server needs to be doing DPI in order to make archiving work)
jonaswKev, don’t you need to do DPI anyways because you need to be sure you’re looking at a MIX message?
jonasw(otherwise, the "MIX JID splitting function" (whatever that is) would operate on non MIX JIDs and possibly yield wrong results)
KevNo, you don't :)
jonaswservers need to do DPI anyways today for archiving to work.
KevNot at this level.
MattJhas left
jonaswnormally, type="groupchat" isn’t archived at all, right?
KevThat obviously has to change.
jonaswfor MIX, yes
Kevtype=groupchat to the bare JID gets archived.
Kev(Once routing/archiving rules are fixed)
jonaswright
jonaswthat would work
KevI have to sort out bins and then go to bed, but I think option 3 has worse issues than the conflation in option 1/2.
XSF Discussion - 2018-05-31