XSF Discussion - 2019-09-25

jcbrand: looking at the updates. I'm on the phone though so I'll do github things later on.

pep. Thanks no rush!

The moderation XEP is still WIP

So don't look at that 😛

A message with* full certainty

Thanks

Do XEPs using 422 also have to talk about 359 btw?

I guess sub-dependencies don't need to be explicitly mentioned

Say tomorrow we say "no more 359, let's use 765"

We'd only have to change 422. I'm not sure that's practical but..

jcbrand: do you think we can loosen the restriction on the fulljid?

For retractions

Just like we did for LMC

`muc ? full_jid : bare_jid`

For retractions, yeah I guess

Maybe it would be good to have a XEP discussing JID based access / authorization like this

Could have the matching rule from privacy lists / blocking command there too

pep. Where do you see a restriction concerning full JID? Is it implicit in one of the examples?

> A retraction MUST only be processed when both the original message and retraction request are received from the same full-JID. ✏

I guess that's an artifact of the protoXEP not being new

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.

But ... why

I don't know.

Martin: It's a matter of updating a JSON file via Github PR

pep. Thanks, will update.

Zash, if you point me to that repo I will create an MR. :)

s/M/P

fear not for I have returned

Martin https://github.com/xsf/xmpp.org/tree/master/data

jonas’! Are you okay!?

You were gone?

3 days in a cave?

Sorry for not realizing, but the girls sobbing in front of that cave were not heared in munich.

Emerges as 🤖 ?

Ge0rG, I was just on vacation :D

and I wasn’t able to use XMPP for reasons I don’t understand

and I had nothing there to debug

quite frustrating

jonas’: no VPN? no mobile?

Ge0rG, mobile data coverage was too bad to use

even for XMPP? eww!

except with the congstar thing which doesn’t have my credentials and just 32kbit/s

Ge0rG, yeah, once I started to use the link it broke down :)

Really? I was able to use xmpp on a train ride where I was not able to open any website.

Martin, "broke down" as in "No coverage"

like, not even for calls

and the wifi there probably filtered DNS heavily

or maybe ports

but Conversations said "Server not found", so I guess they filtered DNS

jcbrand: hmm, maybe use wording similar to https://xmpp.org/extensions/xep-0308.html#nt-idm46554800195296 ? Not just "JID"

I guess you can also mention relying on occupant id optionally

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)

I don’t think that remote-server-not-found should be interpreted as "client has been removed from the room"

jonas’: that's an interesting point.

jonas’: it might be a network outage or a server outage.

exactly

I think it should be treated like a timeout

(especially since a re-join is not likely to succeed anyways)

pep. Done. I already mentioned that the occupant id should be checked in MUCs, clarified that further.

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.

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?

flow, https://github.com/horazont/aioxmpp/issues/312

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.

so I’m very confident that assuming that r-s-n-f means "you got removed" is wrong.

jonas’: good point. Wanna send a PR to the XEP? ;)

after auditing RFC 6120 for more error conditions of that type, yes

remote-server-timeout is another one

if only we had a practically useful error scheme.

I think we do, we just don’t use it well

jcbrand: I guess that's fine like that for the protoXEP. I'd probably relax the dependency on occupant-id though

Why? It's necessary IMO

It's useful for better UX yeah

Not especially necessary

It's necessary to prevent impersonation

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

pep., I'd say it's SHOULD (without retractions won't work in many cases) but not a MUST 😉

larma: yeah, SHOULD would be fine

pep. that's why it's a requirement, a client that doesn't support occupant-id can't support retractions

jcbrand: why not?

because it can't validate the identity of the sender

For all other cases it works

jcbrand: you can validate the sender without occupant-id, just in a more limited manner

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. ✏

jcbrand: as long as both you and the sender are joined to the MUC, you can know it's the same sender

yes but that's not always the case, hence the requirement

jcbrand: it was good enough for LMC

It's a huge issue and not good enough IMO

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.

jcbrand: I might be Ge0rG, a Council member, or Ge0rG, a russian troll bot.

At least I would know that a retracted message was by the same entity

so there is not much difference between the authenticity of the things I say now vs. the things I say after a leave & rejoin

There is, because I know it's the same entity

only if you require occupant-id

which I do

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...

at least in this XEP

Ge0rG, https://github.com/xsf/xeps/pull/834#issue-321176452

jonas’: 👍

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.

jcbrand: I'm not sure I agree.

jcbrand: I'm not sure I disagree, either.

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.

jcbrand: there is no _technical_ requirement on occupant-id in either LMC or Retractions.

It's security related

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?

oh look at how awake I am

I didn’t even realise that Ge0rG is in Council.

jonas’: it will be a very interesting discussion on whether that change mandates a namespace bump.

jonas’: therefore I explicitly only approved the XEP with my author hat on.

"yes, but..."

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.

jcbrand: you can't actually remove a message from MAM, merely remove its payload.

Ge0rG: "removal" means tombstoning

Ah, okay

This is another security issue IMO. It's better to not send certain messages to clients, even if a retraction will be sent afterwards

> 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

The retraction is only for currently connected clients who already received the offending message

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?

larma: I'm not sure what you're point with that quote is. The point of tombstoning is to remove the original message ✏

Sorry... there was a "not" in there

Ge0rG: I don't know, can we?

Kev: you tell me

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>

at least that's how I read it

larma: Look at the example, the <retracted> element is inside the <message> element.

Kev: I've recently thought a bit about one of the aspects of that: https://gist.github.com/ge0rg/5ae3365196a0c046fc596bbf707fdc15

larma: Are you looking at my PR? Or where are you reading this?

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>)

Ge0rG: that's what bind2's trying to help with, I think? (The (4) part at least).

Kev: yes, but bind2 will only do a very small subset of #4

Probably.

larma: Then you don't know who the retracted message was from

Ge0rG: Or, rather, probably needs to be extended to cover them.

jcbrand, then you have to add that to <retracted>?

What's the difference? Why is this an issue?

Kev: I'm not saying that bind2 isn't the right syntactic vehicle to perform MAM-Sub. It just lacks momentum.

larma: IMO it looks more correct semantically the way it is now

Ge0rG: Right.

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

Ok you have a point

Also IMO the retracted message from MAM should probably also tell who retracted it and when?

yes, "when" is a good addition

so store an "original" tombstone plus the retraction message? ✏

Ge0rG, we are approaching what a proper fastening XEP would add to a MAM message for every fastening 😉

<forwarded xmlns='urn:xmpp:forward:0'> <delay xmlns='urn:xmpp:delay' stamp='2019-09-20T23:08:25Z'/> <retracted xmlns='urn:xmpp:message-retract:0' from='romeo@montague.example' by='lord@capulet.example' stamp='2019-09-20T23:09:15Z' /> </forwarded>

(by being optional and defaulting to same as from)

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)

jcbrand, https://github.com/xsf/xeps/pull/833/files#diff-30e15b71462f098e1b7b4cb6931c64bbR84 is type=normal intended here?

larma: you tell us it will break MAM and Carbons?

Ge0rG, huh?

larma: type=normal is the code word to enter the black magic underground of xmpp message routing.

I really need to update my "What's wrong" presentation

Shall we issue a blanket statement that examples without @type means "any type"

Is a type attribute mandatory?

No, but it defaults to 'normal'

so `<message/>` == `<message type="normal"/>`

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.

larma: Thanks, I'll fix

(We can also go with type=headline for the retraction message, but I bet this would just f**k up things)

larma: yeah, it would

I think we should be using headline for MAM retrieval and such

just to annoy pidgin users.

What is the deal with https://xmpp.org/extensions/xep-0182.html ?

It registers the namespace urn:xmpp:errors but I'm not aware of anything that uses it

https://xmpp.org/registrar/errors.html hm

<too-many-stanzas/> is one for the firewall

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

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 ?

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

edhelas, posting it somewhere around 15:00Z on a wednesday in an XSF room is a good start :)

moments ago, in the council room:

https://igniterealtime.org:443/httpfileupload/20d808ee-fbdf-4ab5-857d-95891aefbcd7/image.png

MattJ, can we make a time window (2h or 3h in duration) where we try to figure out how the XSF Registrar is supposed to work technically?

Sure

How about this time +1w - 2h?

MattJ: that would overlap with Council Meeting

-1h?

or just... after the council meeting next week