Kev, 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
Kev
It does 55, I don't believe we RSM.
jonasw
I’d very much like to not return 4000 entries in one reply though
Kev
I don't think 55 supports RSM does it?
jonasw
does *anything* before XEP-0059 "support" RSM?
jonasw
oh look at this, XEP-0059 even uses XEP-0055 as example for RSM
jonasw
and it’s allegedly used with disco#items
jonasw
(even though I haven’t seen that in the wild with MUC services yet)
goffi
I 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)
goffi
I 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
jonasw
is 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
goffi
jonasw: 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
jonasw
goffi: sure, I can re-use bits of 55 but I was wondering whether there was any precedent for that
Who's here and what topics do you prefer to discuss today?
Guus
I'm here
MattJ
I'm here
MattJ
We can discuss the next steps for the results of the survey
Guus
Also: gdpr compliance?
ralphm
Cool. Maybe revisit the GDPR discussion
ralphm
That should fill most of the meeting.
Guus
also: did anyone hear from Martin in the last few weeks?
Guus
he didn't renew XSF membership - I wonder if that was intentional.
ralphm
Not since May 3.
MattJ
Likewise
vanitasvitaehas left
ralphm
While there's no requirement to be a Member to be a Director, I share your curiosity.
ralphm
2. Survey.
MattJ
The survey "officially" ended yesterday, with 24 responses
MattJ
Which I don't consider too bad, I was expecting worse
vanitasvitaehas left
alexishas joined
MattJ
I 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?
MattJ
and if anyone has specific things they'd like to discuss (e.g. points raised) we can add those to the agenda
Guus
Sounds good to me.
ralphm
Agreed
ralphm
3. GDPR
ralphm
So there a few things here and maybe we should split them.
vanitasvitaehas left
ralphm
1) the XSF's compliance
ralphm
2) the proposed XEP
MattJ
Agreed, sensible
Guus
this feels like a beast: can we further split them?
Andrew Nenakhovhas joined
ralphm
Go aheah
Guus
I would if I knew how 🙂
ralphm
Well, 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
ralphm
shout if you can think up more items
Guus
that is: items where we potentially store private information?
Guus
do we use cookies on the website?
MattJ
s/private/personal/
vanitasvitaehas left
ralphm
personal, indeed
Guus
Matt just asked for everyone's mail address in a nice (but one-off) poll
Zashhas left
MattJ
I also stated how they would be used, and that they would not be kept permanently
ralphm
We can probably continue doing all the things we do, but we have to document what we process, for what reason, etc.
Guus
ok, 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
ralphm
And 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)
ralphm
I also thought about the Wiki indeed, and the XEP
Zashhas left
ralphm
s
Guus
I was knee-deep in water at the time, have not read back 😕
Zashhas left
ralphm
Basically we had a PP for both jabber.org and xmpp.org, but with all the website transitions it is no longer available
ralphm
we have it somewhere still, though
Zashhas left
vanitasvitaehas left
Zashhas left
Guus
okay, 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
ralphm
First of all, no-one probably is 100% compliant, and you will know when somebody has sued you
MattJ
Nobody can really say for certain, there are too many grey areas - however I'm really not worried
efrithas joined
vanitasvitaehas left
MattJ
Pretty much all we have is public, and given by people knowingly
Zashhas left
ralphm
The focus points will be documentation, the pp, and possibly retention, and information and deletion requests.
MattJ
There may be hidden things like server logs, but if we don't keep those for "too long", we "should" be ok
Guus
sure, and although I assume that that's ok, that's not based on any knowledge of gdpr on my part.
flowhas left
flowhas joined
ralphm
Well, I've been involved professionally, so I know a few things
alexishas left
Guus
good. Tag, you're it. 🙂
alexishas joined
vanitasvitaehas left
ralphm
I think we should also involve Alex
ralphm
haha, good one
ralphm
Sounds like MattJ knows things, too
jubalhhas joined
Guus
maybe we should task a certain group of people with doing an inventory of our data, and make recommendations?
MattJ
iteam?
vanitasvitaehas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Guus
or an adhoc one (Ralph, Alex, the people that have bene working on the XEP)
vanitasvitaehas left
Guus
I'd be happy to do leg-work, but I need someone to tell me what to do.
vanitasvitaehas left
MattJ
Well in the case I gave (server logs), that's something that requires iteam - an inventory of running services and what they collect
vanitasvitaehas left
Guus
RIght - 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.
ralphm
I think a work team
vanitasvitaehas left
Guus
This 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.
ralphm
so indeed, you need iteam for inventory, someone the leads the effort, and in any case the Secretary should be involved
ralphm
There are probably helpful 10-step plans out there, but I haven't looked at that at all
Guus
I'm unsure if we can volunteer the Secretary for a WT, but we can at least ask the WT to inform the Secretary. 🙂
Guus
Ralph, would you mind spearheading that team?
vanitasvitaehas left
Guus
you seem to have a good grasp on tings.
Guus
things*
ralphm
On the involvement of the Secretary, probably yes we can volunteer him:
ralphm
Section 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.
ralphm
Note the part on 'corporate books and records'
vanitasvitaehas left
Guus
Let's aim to have a mission statement / member list ready for next week, so that we can procedurally establish the team.
ralphm
But of course we should ask Alex how he can help us on this
ralphm
seems reasonable
ralphm
Ok then, I guess we should move on to the other part
ralphm
4. GDPR XEP
Guus
(I don't have much more time to spend today)
ralphm
Oh, it is that time already.
Guus
as for the XEP: what are downsides of publishing such a XEP?
ralphm
Well, in principle it is unclear if the XSF should publish a specification that would give guidelines in direct relation to the GDPR
ralphm
I'm not familiar with US law, but the concept of Legal Advise is a apparently a Thing
ralphm
Advice even
Guus
what is "giving legal advice" ? Does publishing that XEP qualify?
ralphm
Well, in the state that it was in last week, there wasn't much in there yet
ralphm
I haven't checked since
MattJ
It's a combination of factors - for example, in some places you need to be licensed to practice law
ralphm
But 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
MattJ
It'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
Guus
My 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.
MattJ
and separate from this issue, but similar - someone could try to blame the XSF if they followed published advice but got fined under GDPR
Guus
There's a huge gap between practice law and give information
efrithas left
ralphm
Right, 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
Also, 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
goffi
would 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
flow
I'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
Kev
The answer is "yes". Also "no".
Kev
It 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?
flow
I feared that this was the conclusion back then
Zash
Can we have that odd text accidentally dropped down a well?
flow
would a MAM IQ to the own bare JID be equal to the same query without to attribute?
Kev
flow: Yes.
flow
*without 'to' attribute
MattJ
As far as I'm concerned, and Prosody is concerned, yes
Zash
Prosody treats to=own bare jid identical to missing to
daniel
Can we just get rid of missing to and missing froms
Zash
In fact, it removes the 'to' and uses its absense for security related things
blablahas left
Zash
daniel: make them mandatory always, like on s2s?
flow
Zash, interesting, care to elaborate on these "security related things" that you get when you handle stanzas without 'to'?
MattJ
daniel, in a way I prefer it, you know this stanza isn't going anywhere
daniel
Zash: yes. If you want to send something to your account you have to address it
daniel
And vice versa
ibikkhas joined
MattJ
flow, 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
Zash
daniel: I want the opposite
MattJ
and we normalize the to/from to 'missing to' so that there can't be any JID normalization accidents in modules
Zash
And then it bites Ge0rG right in the carbons
daniel
MattJ: but if you address your server the stanza isn't going anywhere either...
daniel
For some definition of not going anywhere
Kev
MattJ: Do you do some sort of NAT to get the right address injected when you reply then?
Kev
Because replying to a to=bare stanza with missing to isn't ok.✎
MattJ
Kev, 'from' is always set, and that's what we reply to
MattJ
and 'to' is not needed on c2s streams
Kev
Because replying to a to=bare stanza with missing from isn't ok. ✏
Zash
to and from should default to the entities on each end of c2s streams, ie the client and their account
MattJ
Obviously from and to are swapped in any reply
Kev
One has to be fairly careful when claiming anything is obvious, when talking about this ;)
Guushas left
Guushas left
jonasw
Kev, why is it not ok? missing from is identical to comes from bare jid, isn’t it?
I am /pretty/ sure that I’ve seen servers which do not do that.
jonasw
I have ugly workarounds for that
jonasw
ah, no I am at the wrong place in the text
Zash
Whowhere?
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>).
jonasw
Kev, so, there’s no NAT needed, just don’t emit the @from in the reply ^
Guushas left
daniel
Zash: hoover?
Kev
jonasw: Yes, but if it's a reply to a stanza the client sent, the server must swap the to/from.
Zash
🕴
Kev
You can't, as a server, receive a stanza that is to=bare JID, and reply with no from.
MattJ
Kev, says?
Zash
The holy text.
Alexhas joined
Kev
MattJ: 6120, somewhere.
Kev
e.g. for error stanzas "The error stanza SHOULD simply swap the 'from' and 'to' addresses from the generated stanza"
MattJ
That's a stretch to say it applies to all stanzas, as you're saying
Kev
Yes, that was just the quickest thing to find.
MattJ
I think the text jonasw pasted is pretty clear that the server has two valid options
Kev
Yes, but not clear that both are always right.
tahas joined
MattJ
Then that text might as well be removed, and let the text you remember specify what the 'from' should be
lumihas left
jonasw
Kev, ok, then I found a server with a bug.
Guushas left
jonasw
because that’s why I needed workarounds (because servers did exactly that)
jonasw
ah, well
jonasw
if the swap is only a SHOULD, I can see this to be an exception
Guushas left
Kev
I 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
Kev
jonasw: 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)
jonasw
oh yes
jonasw
I 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
koyu
hey, i just setup my own xmpp server
SaltyBoneshas left
Kev
Welcome to the cool club. Or something.
MattJ
:)
koyu
yeah, i just can't get omemo to work on ejabberd
Wiktor
As far as I remember omemo is disabled by default in ejabberd, but you may check in ejabberd room
Wiktor
xmpp:ejabberd@conference.process-one.net?join
alexishas joined
Neustradamushas joined
muppethhas left
muppethhas joined
lumihas joined
waqashas left
koyuhas joined
jjrhhas left
koyuhas joined
jjrhhas left
jubalhhas joined
tuxhas joined
koyuhas left
koyuhas joined
jjrhhas left
alexishas left
alexishas joined
alexishas joined
alexishas left
alexishas joined
koyuhas left
koyuhas joined
alexishas left
alexishas joined
waqashas joined
j.rhas joined
Steve Killehas left
Steve Killehas left
jonasw
Ge0rG, chat.yax.im down?
tuxhas joined
Dave Cridlandhas left
Dave Cridlandhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Guushas left
Guushas left
Valerianhas left
Valerianhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
efrithas left
efrithas joined
jerehas left
jerehas joined
Ge0rG
jonasw: works for me
jonasw
yeah, it just had a few minutes of hangup
jonasw
17: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
MattJ
So MIX proxy JIDs... if someone creates a MIX channel that is <1023 bytes>@mix.example.com... what happens to the userid part?
jonasw
"boom"
jonasw
I imagine servers simply wouldn’t allow that
MattJ
So how long is the generated id?
jonasw
probably service-defined
MattJ
It's such a hack
jonasw
do you have a better suggestion?
MattJ
Well 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
jonasw
because that leads to the same situation
jonasw
just in a different part and with different moving parts
jonasw
with Kevs variant (1), the multiple pieces are in the nodepart, with variant (2) the multiple pieces are in the resource
jonasw
so both are bad w.r.t. that
jonasw
one 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
MattJ
All existing routing, libraries and... everything already knows how to correctly split a JID
jonasw
true
jonasw
and I think that the semantics assumed with "bare JID" work better with variant (1) than with variant (2)
SamWhitedhas left
MattJ
Trust me, someone will want to implement some higher-level logic to know which messages are associated with a MIX channel
MattJ
Except with variant (1) you can't really do that
MattJ
You have to know it *is* a MIX channel, and that you have to strip the bit before the #
MattJ
Block a MIX channel? Ok, but messages from participants would still reach you
jonasw
and other people want to have high-level logic to konw which messages are associated with a MIX channel occupant.
ibikkhas joined
MattJ
any 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
jonasw
we should’ve followed email and allowed multiple @s in addresses
MattJ
Yes, that would really have helped... :)
MattJ
so now nobody knows what an email address actually is, but everyone has their own idea that's good enough for them
MattJ
Pretty much what's going on here, to be honest :)
MattJ
The # is the extra @ to the entities that can see it
MattJ
To the others, it's not and it's weird
jonasw
the variant (2) would make things worse than MUC actually
MattJ
Can you (or someone) lay down the reasons for that?
jonasw
didn’t I?
jjrhhas left
MattJ
I didn't see if you did, /me checks
jonasw
but 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
jonasw
so if you wanted to filter all messages from an occupant, you’d have to know that they’re MIX messages
jonasw
to split them correctly
jonasw
kinda the same issue you describe with MIX channels in variant (1)
MattJ
Hmm, what do you mean?
jonasw
for example, presence
jerehas joined
jonasw
and avatar hashes
jonasw
I keep those in a cache, usually keyed by the bare JID
jonasw
which 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)
jonasw
now 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
jonasw
i.e. do determine the identity this JID belongs to
jonasw
really, the same thing you described earlier, just with occupants instead of channels
MattJ
Right
jonasw
I 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)
MattJ
So how do you know it's a MIX message and you need to split the nodepart? Payload?
jonasw
yes
mikaelahas left
jonasw
Strawman 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
jonasw
Strawman 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> ✏
MattJ
Heh, part of me wants to dislike that, but I prefer it
MattJ
I feel like the security aspects need to be investigated here though
jonasw
that’s not how straw-mans are supposed to work
jonasw
which part exactly?
MattJ
Well you need to verify the service in every case, I think
jonasw
what do you mean exactly?
MattJ
Otherwise I register mattj#rocks@jabber.org and send you a message wih a MIX payload
Andrew Nenakhovhas left
jonasw
and then?
Andrew Nenakhovhas joined
MattJ
Don't know, currently I got as far as "your client breaks"
jonasw
the client or server would drop it because it doesn’t know about a MIX rocks@jabber.org
jonasw
just like we currently drop type="groupchat" from MUCs we don’t know.
MattJ
Right, the whole "participant's server needs to know MIX" thing
Andrew Nenakhovhas joined
jonasw
at least we’re honest about it this time (not with MUC, where servers were blindsided by interesting interaction sideeffects e.g. when changing nicknames)✎
jonasw
at 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) ✏
MattJ
I 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
jonasw
I’m not sure that’s a good thing
jonasw
but mmm, it could be
jonasw
it makes it more difficult for MIX services though
Guushas left
Guushas left
MattJ
How so?
jonasw
when 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)
jonasw
hm, or we require <mix channel="…"/> elements even in non-groupchat messages
jonasw
then 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
jonasw
question is whether that’s reasonable
SaltyBoneshas left
MattJ
Totally if you ask me
jonasw
so I’ll post that to the list now
MattJ
Variant 3! Thanks :)
MattJhas left
Guushas left
alacerhas left
jerehas joined
Tobiashas left
Tobiashas joined
jonasw
Advantages:
- 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)
jonasw
did I miss something?
rtq3has left
rtq3has joined
vanitasvitaehas left
jonasw
sent
MattJ
Sorry, 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
Kev
I'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.✎
Kev
I'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. ✏
Kev
i.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)
jonasw
Kev, 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)
Kev
No, you don't :)
jonasw
servers need to do DPI anyways today for archiving to work.
Kev
Not at this level.
MattJhas left
jonasw
normally, type="groupchat" isn’t archived at all, right?
Kev
That obviously has to change.
jonasw
for MIX, yes
Kev
type=groupchat to the bare JID gets archived.
Kev
(Once routing/archiving rules are fixed)
jonasw
right
jonasw
that would work
Kev
I 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.