pep.jcbrand: looking at the updates. I'm on the phone though so I'll do github things later on.
jcbrandpep. Thanks no rush!
jcbrandThe moderation XEP is still WIP
jcbrandSo don't look at that 😛
pep.A message with* full certainty
jcbrandThanks
pep.Do XEPs using 422 also have to talk about 359 btw?
jcbrandI 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
ZashMaybe it would be good to have a XEP discussing JID based access / authorization like this
ZashCould have the matching rule from privacy lists / blocking command there too
jcbrandpep. 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
MartinAt 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.
ZashBut ... why
MartinI don't know.
ZashMartin: It's a matter of updating a JSON file via Github PR
LNJhas joined
jcbrandpep. Thanks, will update.
MartinZash, if you point me to that repo I will create an MR. :)
MartinSorry for not realizing, but the girls sobbing in front of that cave were not heared in munich.
Steve Killehas joined
ZashEmerges 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
Ge0rGjonas’: no VPN? no mobile?
jonas’Ge0rG, mobile data coverage was too bad to use
Ge0rGeven 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
MartinReally? 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"
Ge0rGjonas’: that's an interesting point.
Ge0rGjonas’: 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)
jcbrandpep. 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.
flowjonas’, it looks like I can't find the context of "that self-ping failure". Would you be so kind and point me to it?
jonas’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
Ge0rGjonas’: 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
Ge0rGif 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
jcbrandWhy? It's necessary IMO
pep.It's useful for better UX yeah
pep.Not especially necessary
jcbrandIt'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
larmapep., 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
jcbrandpep. 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?
jcbrandbecause it can't validate the identity of the sender
pep.For all other cases it works
Ge0rGjcbrand: you can validate the sender without occupant-id, just in a more limited manner
jcbrandGe0rG: 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.
jcbrandGe0rG: 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.
Ge0rGjcbrand: as long as both you and the sender are joined to the MUC, you can know it's the same sender
jcbrandyes but that's not always the case, hence the requirement
Ge0rGjcbrand: it was good enough for LMC
jcbrandIt's a huge issue and not good enough IMO
Ge0rGjcbrand: it's a minor issue, because it only affects public semi-anon MUCs and you can't rely on user identity in those anyway.
Ge0rGjcbrand: I might be Ge0rG, a Council member, or Ge0rG, a russian troll bot.
jcbrandAt least I would know that a retracted message was by the same entity
Ge0rGso there is not much difference between the authenticity of the things I say now vs. the things I say after a leave & rejoin
jcbrandThere is, because I know it's the same entity
Ge0rGonly if you require occupant-id
jcbrandwhich I do
larmajcbrand, 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...
jcbrandGe0rG: 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.
Ge0rGjcbrand: I'm not sure I agree.
Ge0rGjcbrand: I'm not sure I disagree, either.
kokonoehas joined
Ge0rGjcbrand: 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.
Ge0rGjcbrand: there is no _technical_ requirement on occupant-id in either LMC or Retractions.
jcbrandIt's security related
larmajcbrand, (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.
Ge0rGjonas’: it will be a very interesting discussion on whether that change mandates a namespace bump.
Ge0rGjonas’: therefore I explicitly only approved the XEP with my author hat on.
Ge0rGputs on his robe and author hat
jonas’"yes, but..."
jcbrandlarma: 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.
Ge0rGjcbrand: you can't actually remove a message from MAM, merely remove its payload.
jcbrandGe0rG: "removal" means tombstoning
Ge0rGAh, okay
jcbrandThis 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
jcbrandThe retraction is only for currently connected clients who already received the offending message
Ge0rGCan'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?
jcbrandlarma: I'm not sure what you're point with that quote is. The point of tombstoning is to not remove the original message
jcbrandlarma: I'm not sure what you're point with that quote is. The point of tombstoning is to remove the original message
jcbrandSorry... there was a "not" in there
KevGe0rG: I don't know, can we?
jubalhhas joined
Ge0rGKev: you tell me
larmajcbrand, 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>
larmaat least that's how I read it
jcbrandlarma: Look at the example, the <retracted> element is inside the <message> element.
Ge0rGKev: I've recently thought a bit about one of the aspects of that: https://gist.github.com/ge0rg/5ae3365196a0c046fc596bbf707fdc15
jcbrandlarma: Are you looking at my PR? Or where are you reading this?
jubalhhas left
larmajcbrand, 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>)
KevGe0rG: that's what bind2's trying to help with, I think? (The (4) part at least).
Ge0rGKev: yes, but bind2 will only do a very small subset of #4
KevProbably.
jcbrandlarma: Then you don't know who the retracted message was from
KevGe0rG: Or, rather, probably needs to be extended to cover them.
larmajcbrand, then you have to add that to <retracted>?
jcbrandWhat's the difference? Why is this an issue?
Ge0rGKev: I'm not saying that bind2 isn't the right syntactic vehicle to perform MAM-Sub. It just lacks momentum.
jcbrandlarma: IMO it looks more correct semantically the way it is now
KevGe0rG: Right.
larmajcbrand: 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
jcbrandOk you have a point
larmaAlso IMO the retracted message from MAM should probably also tell who retracted it and when?
jcbrandyes, "when" is a good addition
Ge0rGso store an original tombstone plus the retraction message?
Ge0rGso store an "original" tombstone plus the retraction message?
larmaGe0rG, we are approaching what a proper fastening XEP would add to a MAM message for every fastening 😉
larma(by being optional and defaulting to same as from)
mukt2has joined
zachhas left
zachhas joined
larmajcbrand,
> 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
larmajcbrand, https://github.com/xsf/xeps/pull/833/files#diff-30e15b71462f098e1b7b4cb6931c64bbR84 is type=normal intended here?
Ge0rGlarma: you tell us it will break MAM and Carbons?
larmaGe0rG, huh?
Ge0rGlarma: type=normal is the code word to enter the black magic underground of xmpp message routing.
Ge0rGI really need to update my "What's wrong" presentation
ZashShall we issue a blanket statement that examples without @type means "any type"
jcbrandIs a type attribute mandatory?
ZashNo, but it defaults to 'normal'
karoshihas left
Zashso `<message/>` == `<message type="normal"/>`
karoshihas joined
kokonoehas left
mukt2has left
kokonoehas joined
alameyohas left
larmajcbrand, 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.
jcbrandlarma: 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)
Ge0rGlarma: yeah, it would
Ge0rGI think we should be using headline for MAM retrieval and such
jubalhhas left
Ge0rGjust to annoy pidgin users.
LNJhas left
Martinhas left
Martinhas joined
zachhas left
zachhas joined
pdurbinhas joined
Chobbeshas joined
Chobbeshas left
Chobbeshas joined
pdurbinhas left
ZashWhat is the deal with https://xmpp.org/extensions/xep-0182.html ?
zachhas left
zachhas joined
ZashIt registers the namespace urn:xmpp:errors but I'm not aware of anything that uses it
delehas left
delehas joined
Zashhttps://xmpp.org/registrar/errors.html hm
Chobbeshas left
Chobbeshas joined
Ge0rG<too-many-stanzas/> is one for the firewall
Danielhas left
flowjonas’> 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
edhelasI 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
Ge0rGedhelas: 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 :)
XSF Discussion - 2019-09-25