jcbrand: looking at the updates. I'm on the phone though so I'll do github things later on.
jcbrand
pep. Thanks no rush!
jcbrand
The moderation XEP is still WIP
jcbrand
So don't look at that 😛
pep.
A message with* full certainty
jcbrand
Thanks
pep.
Do XEPs using 422 also have to talk about 359 btw?
jcbrand
I guess sub-dependencies don't need to be explicitly mentioned
pep.
Say tomorrow we say "no more 359, let's use 765"
pep.
We'd only have to change 422. I'm not sure that's practical but..
karoshihas joined
Danielhas left
mukt2has joined
kokonoehas left
Douglas Terabytehas left
Danielhas joined
Mikaelahas left
kokonoehas joined
mimi89999has joined
Mikaelahas joined
debaclehas joined
Douglas Terabytehas joined
pep.
jcbrand: do you think we can loosen the restriction on the fulljid?
pep.
For retractions
pep.
Just like we did for LMC
Zash
`muc ? full_jid : bare_jid`
winfriedhas left
winfriedhas joined
pep.
For retractions, yeah I guess
Douglas Terabytehas left
Zash
Maybe it would be good to have a XEP discussing JID based access / authorization like this
Zash
Could have the matching rule from privacy lists / blocking command there too
jcbrand
pep. Where do you see a restriction concerning full JID? Is it implicit in one of the examples?
pep.
> MUST only be processed when both the original message and retraction request are received from the same full-JID.✎
pep.
> A retraction MUST only be processed when both the original message and retraction request are received from the same full-JID. ✏
Steve Killehas left
pep.
I guess that's an artifact of the protoXEP not being new
Martinhas joined
Martin
At https://xmpp.org/software/clients.html profanity links to profanity.im but the new website is https://profanity-im.github.io/. Right now profanity.im should forward but they were already considering ditching the domain, so you should better change that to prevent linking to a domain squatter in the future.
Zash
But ... why
Martin
I don't know.
Zash
Martin: It's a matter of updating a JSON file via Github PR
LNJhas joined
jcbrand
pep. Thanks, will update.
Martin
Zash, if you point me to that repo I will create an MR. :)
Martin
s/M/P
jonas’
fear not for I have returned
Zash
Martin https://github.com/xsf/xmpp.org/tree/master/data
Ge0rG
jonas’! Are you okay!?
Zash
You were gone?
Martin
3 days in a cave?
Martin
Sorry for not realizing, but the girls sobbing in front of that cave were not heared in munich.
Steve Killehas joined
Zash
Emerges as 🤖 ?
winfriedhas left
winfriedhas joined
winfriedhas left
winfriedhas joined
delehas joined
jonas’
Ge0rG, I was just on vacation :D
jonas’
and I wasn’t able to use XMPP for reasons I don’t understand
jonas’
and I had nothing there to debug
jonas’
quite frustrating
Ge0rG
jonas’: no VPN? no mobile?
jonas’
Ge0rG, mobile data coverage was too bad to use
Ge0rG
even for XMPP? eww!
murabitohas left
jonas’
except with the congstar thing which doesn’t have my credentials and just 32kbit/s
murabitohas joined
jonas’
Ge0rG, yeah, once I started to use the link it broke down :)
Douglas Terabytehas joined
Martin
Really? I was able to use xmpp on a train ride where I was not able to open any website.
winfriedhas left
winfriedhas joined
jonas’
Martin, "broke down" as in "No coverage"
jonas’
like, not even for calls
jonas’
and the wifi there probably filtered DNS heavily
jonas’
or maybe ports
jonas’
but Conversations said "Server not found", so I guess they filtered DNS
Martinhas left
delehas left
delehas joined
UsLhas joined
jubalhhas joined
delehas left
Dele (Mobile)has joined
zachhas left
zachhas joined
Mikaelahas left
Mikaelahas joined
winfriedhas left
winfriedhas joined
larmahas left
j.rhas joined
Martinhas joined
larmahas joined
debaclehas left
winfriedhas left
winfriedhas joined
Dele (Mobile)has left
Mikaelahas left
COM8has joined
Mikaelahas joined
mukt2has left
pdurbinhas joined
delehas joined
jubalhhas left
COM8has left
pep.
jcbrand: hmm, maybe use wording similar to https://xmpp.org/extensions/xep-0308.html#nt-idm46554800195296 ? Not just "JID"
pep.
I guess you can also mention relying on occupant id optionally
kokonoehas left
Dele (Mobile)has joined
kokonoehas joined
jubalhhas joined
winfriedhas left
winfriedhas joined
j.rhas left
debaclehas joined
Dele (Mobile)has left
pdurbinhas left
jonas’
Ge0rG, regarding that self-ping failure: the issue is twofold. first, the pinger interprets remote-server-not-found as "client was removed from the room" as per XEP-0410. second, it does not auto-rejoin after being removed (or maybe the rejoin fails because remote-server-not-found and it doesn’t re-try)
jonas’
I don’t think that remote-server-not-found should be interpreted as "client has been removed from the room"
Ge0rG
jonas’: that's an interesting point.
Ge0rG
jonas’: it might be a network outage or a server outage.
jonas’
exactly
jonas’
I think it should be treated like a timeout
jonas’
(especially since a re-join is not likely to succeed anyways)
jcbrand
pep. Done. I already mentioned that the occupant id should be checked in MUCs, clarified that further.
pep.
No SHOULD right? I know some people are not particularly happy with occupant-id, (because de-pseudonimisation, which is the goal), even though they haven't expressed that clearly yet.
flow
jonas’, it looks like I can't find the context of "that self-ping failure". Would you be so kind and point me to it?
Ge0rG, and even on server outages, the room state may still be persistent on the server an the client might not have actually been removed.
lskdjfhas joined
jonas’
so I’m very confident that assuming that r-s-n-f means "you got removed" is wrong.
jubalhhas left
Ge0rG
jonas’: good point. Wanna send a PR to the XEP? ;)
jonas’
after auditing RFC 6120 for more error conditions of that type, yes
jonas’
remote-server-timeout is another one
Ge0rG
if only we had a practically useful error scheme.
jonas’
I think we do, we just don’t use it well
pep.
jcbrand: I guess that's fine like that for the protoXEP. I'd probably relax the dependency on occupant-id though
jcbrand
Why? It's necessary IMO
pep.
It's useful for better UX yeah
pep.
Not especially necessary
jcbrand
It's necessary to prevent impersonation
Nekithas left
pep.
A client not implementing occupant-id (or a future equivalent?) would probably just ignore retractions when they can't validate the identity of the sender
kokonoehas left
larma
pep., I'd say it's SHOULD (without retractions won't work in many cases) but not a MUST 😉
pep.
larma: yeah, SHOULD would be fine
jcbrand
pep. that's why it's a requirement, a client that doesn't support occupant-id can't support retractions
Nekithas joined
pep.
jcbrand: why not?
jcbrand
because it can't validate the identity of the sender
pep.
For all other cases it works
Ge0rG
jcbrand: you can validate the sender without occupant-id, just in a more limited manner
jcbrand
Ge0rG: How? AFAIK you can determine whether don't know it's the same sender, but you can't always determine that you DO know it's the same sender.✎
jcbrand
Ge0rG: How? AFAIK you can determine whether you don't know it's the same sender, but you can't always determine that you DO know it's the same sender. ✏
Ge0rG
jcbrand: as long as both you and the sender are joined to the MUC, you can know it's the same sender
jcbrand
yes but that's not always the case, hence the requirement
Ge0rG
jcbrand: it was good enough for LMC
jcbrand
It's a huge issue and not good enough IMO
Ge0rG
jcbrand: it's a minor issue, because it only affects public semi-anon MUCs and you can't rely on user identity in those anyway.
Ge0rG
jcbrand: I might be Ge0rG, a Council member, or Ge0rG, a russian troll bot.
jcbrand
At least I would know that a retracted message was by the same entity
Ge0rG
so there is not much difference between the authenticity of the things I say now vs. the things I say after a leave & rejoin
jcbrand
There is, because I know it's the same entity
Ge0rG
only if you require occupant-id
jcbrand
which I do
larma
jcbrand, I know you didn't touch that from the previous protoXEP, but I really don't like the tombstones thing: It changes the meaning of a messages UID in a non-backwards compatible fashion. This will most likely lead to different or even perceivably random behavior within clients that implement MAM but don't implement retractions...
Ge0rG: You and I both are of the opinion that it makes sense to try and "fix" MUCs as much as possible instead of putting our hopes on some future migration/rewrite. Requiring occupant id is a very good step in that direction.
Ge0rG
jcbrand: I'm not sure I agree.
Ge0rG
jcbrand: I'm not sure I disagree, either.
kokonoehas joined
Ge0rG
jcbrand: my point is: occupant-id is a significant change of user identity exposition in semi-anon MUCs, and this step shouldn't be taken lightly.
Ge0rG
jcbrand: there is no _technical_ requirement on occupant-id in either LMC or Retractions.
jcbrand
It's security related
larma
jcbrand, (also regarding tombstones) shouldn't the logic of how to apply fastenings in MAM be part of fastening and not part of every individual XEP? I expected that to be the main reason why we'd want a generic fastening XEP, no?
jonas’
oh look at how awake I am
jonas’
I didn’t even realise that Ge0rG is in Council.
Ge0rG
jonas’: it will be a very interesting discussion on whether that change mandates a namespace bump.
Ge0rG
jonas’: therefore I explicitly only approved the XEP with my author hat on.
Ge0rGputs on his robe and author hat
jonas’
"yes, but..."
jcbrand
larma: I think we should have a way to actually remove the message from the archive and not just append a hint that it shouldn't be shown. Most fastenings will be append only I presume.
Ge0rG
jcbrand: you can't actually remove a message from MAM, merely remove its payload.
jcbrand
Ge0rG: "removal" means tombstoning
Ge0rG
Ah, okay
jcbrand
This is another security issue IMO. It's better to not send certain messages to clients, even if a retraction will be sent afterwards
larma
> However a server that wishes to remove messages from the middle of an archive, e.g. to remove accidentally transmitted sensitive information may omit the <message> stanza from inside the <forwarded> element
jcbrand
The retraction is only for currently connected clients who already received the offending message
Ge0rG
Can't we already just implement a distributed chat history database synchronization protocol, instead of adding one quirk on top of another over unreliable message transport stream semantics?
jcbrand
larma: I'm not sure what you're point with that quote is. The point of tombstoning is to not remove the original message✎
jcbrand
larma: I'm not sure what you're point with that quote is. The point of tombstoning is to remove the original message ✏
jcbrand
Sorry... there was a "not" in there
Kev
Ge0rG: I don't know, can we?
jubalhhas joined
Ge0rG
Kev: you tell me
larma
jcbrand, the MAM XEP suggests that you probably want to remove the <message> from the <forwarded> (and optionally replace it with a <retracted>) instead of adding <retracted> inside <message>
larma
at least that's how I read it
jcbrand
larma: Look at the example, the <retracted> element is inside the <message> element.
Ge0rG
Kev: I've recently thought a bit about one of the aspects of that: https://gist.github.com/ge0rg/5ae3365196a0c046fc596bbf707fdc15
jcbrand
larma: Are you looking at my PR? Or where are you reading this?
jubalhhas left
larma
jcbrand, yes your PR has <retracted> inside <message> inside <forwarded> but 313§2.1 suggests that you shouldn't do that and instead remove <message> from <forwarded> and optionally replace it with an appropriate placeholder (like <retracted> directly inside <forwarded>)
Kev
Ge0rG: that's what bind2's trying to help with, I think? (The (4) part at least).
Ge0rG
Kev: yes, but bind2 will only do a very small subset of #4
Kev
Probably.
jcbrand
larma: Then you don't know who the retracted message was from
Kev
Ge0rG: Or, rather, probably needs to be extended to cover them.
larma
jcbrand, then you have to add that to <retracted>?
jcbrand
What's the difference? Why is this an issue?
Ge0rG
Kev: I'm not saying that bind2 isn't the right syntactic vehicle to perform MAM-Sub. It just lacks momentum.
jcbrand
larma: IMO it looks more correct semantically the way it is now
Kev
Ge0rG: Right.
larma
jcbrand: It is an issue because with your way it is undecidable if the message was send this way from the original sender or if it was done by MAM
jcbrand
Ok you have a point
larma
Also IMO the retracted message from MAM should probably also tell who retracted it and when?
jcbrand
yes, "when" is a good addition
Ge0rG
so store an original tombstone plus the retraction message?✎
Ge0rG
so store an "original" tombstone plus the retraction message? ✏
larma
Ge0rG, we are approaching what a proper fastening XEP would add to a MAM message for every fastening 😉
(by being optional and defaulting to same as from)
mukt2has joined
zachhas left
zachhas joined
larma
jcbrand,
> Clients MUST set the XEP-0359 'origin id' attribute on sent messages to make them suitable for message retraction.
Shouldn't be needed in MUCs as we use MUCs stanza-id instead (and it would be stupid if you can't moderate messages that don't have an origin-id :D)
jubalhhas joined
j.rhas joined
alameyohas left
alameyohas joined
larma
jcbrand, https://github.com/xsf/xeps/pull/833/files#diff-30e15b71462f098e1b7b4cb6931c64bbR84 is type=normal intended here?
Ge0rG
larma: you tell us it will break MAM and Carbons?
larma
Ge0rG, huh?
Ge0rG
larma: type=normal is the code word to enter the black magic underground of xmpp message routing.
Ge0rG
I really need to update my "What's wrong" presentation
Zash
Shall we issue a blanket statement that examples without @type means "any type"
jcbrand
Is a type attribute mandatory?
Zash
No, but it defaults to 'normal'
karoshihas left
Zash
so `<message/>` == `<message type="normal"/>`
karoshihas joined
kokonoehas left
mukt2has left
kokonoehas joined
alameyohas left
larma
jcbrand, https://github.com/xsf/xeps/pull/833/files#diff-30e15b71462f098e1b7b4cb6931c64bbR62 if you leave out type=groupchat here, the message won't be delivered to room occupants. Technically type=normal works in the other case because it is the MUC sending it, but type=groupchat is better IMO because it implies that every room occupant receives it and also if this was a self-retraction message, it would be type=groupchat as well.
jcbrand
larma: Thanks, I'll fix
larma
(We can also go with type=headline for the retraction message, but I bet this would just f**k up things)
Ge0rG
larma: yeah, it would
Ge0rG
I think we should be using headline for MAM retrieval and such
jubalhhas left
Ge0rG
just to annoy pidgin users.
LNJhas left
Martinhas left
Martinhas joined
zachhas left
zachhas joined
pdurbinhas joined
Chobbeshas joined
Chobbeshas left
Chobbeshas joined
pdurbinhas left
Zash
What is the deal with https://xmpp.org/extensions/xep-0182.html ?
zachhas left
zachhas joined
Zash
It registers the namespace urn:xmpp:errors but I'm not aware of anything that uses it
delehas left
delehas joined
Zash
https://xmpp.org/registrar/errors.html hm
Chobbeshas left
Chobbeshas joined
Ge0rG
<too-many-stanzas/> is one for the firewall
Danielhas left
flow
jonas’> I think we do, we just don’t use it well [re error scheme]
I think it could be improved here and there: https://github.com/igniterealtime/Smack/blob/93aaf6d8d7df1071a224ef406738ff322c20724b/smack-extensions/src/main/java/org/jivesoftware/smackx/ping/PingManager.java#L156
Danielhas joined
alameyohas joined
Chobbeshas left
Chobbeshas joined
zachhas left
zachhas joined
Andrew Nenakhovhas joined
j.rhas left
Andrew Nenakhovhas left
LNJhas joined
zachhas left
zachhas joined
winfriedhas left
winfriedhas joined
winfriedhas left
winfriedhas joined
lumihas joined
winfriedhas left
winfriedhas joined
Chobbeshas left
winfriedhas left
winfriedhas joined
zachhas left
zachhas joined
remkohas left
remkohas joined
lorddavidiiihas left
winfriedhas left
winfriedhas joined
Marandahas left
Marandahas joined
lorddavidiiihas joined
zachhas left
zachhas joined
winfriedhas left
winfriedhas joined
alameyohas left
Guushas left
Guushas joined
alameyohas joined
winfriedhas left
delehas left
winfriedhas joined
delehas joined
delehas left
j.rhas joined
jubalhhas joined
winfriedhas left
winfriedhas joined
zachhas left
zachhas joined
delehas joined
gavhas left
gavhas joined
kokonoehas left
zachhas left
zachhas joined
Kevhas left
alameyohas left
delehas left
Chobbeshas joined
kokonoehas joined
delehas joined
Mikaelahas left
Mikaelahas joined
j.rhas left
j.rhas joined
karoshihas left
karoshihas joined
delehas left
rionhas left
rionhas joined
j.rhas left
delehas joined
zachhas left
zachhas joined
j.rhas joined
patrickhas joined
Kevhas joined
mimi89999has left
jubalhhas left
mimi89999has joined
lorddavidiiihas left
lorddavidiiihas joined
kokonoehas left
j.rhas left
APachhas left
APachhas joined
j.rhas joined
zachhas left
zachhas joined
LNJhas left
LNJhas joined
Chobbeshas left
Chobbeshas joined
j.rhas left
zachhas left
zachhas joined
edhelas
I reopened https://github.com/xsf/xeps/pull/824 a few days ago because it was merged by mistake, should I do something else to make it reviewed by the Council ?
wojtekhas joined
!xsf_Martinhas left
Ge0rG
edhelas: tell Council about it. Ideally through the means of an agenda submission to dwd, but shouting about it in here at the right time might work
jonas’
edhelas, posting it somewhere around 15:00Z on a wednesday in an XSF room is a good start :)