XSF Discussion - 2017-03-13

Hidiho! In the light of Push Notifications I wondered if it wouldn't make sense to add a <no-push xmlns="urn:xmpp:hints"/> to https://xmpp.org/extensions/xep-0334.html ?

zeank: where should it be used, then?

To not trigger a push on the server side

and you want remote parties in control of that?

in certain cases, yes

Ok, I see a problem … they could control it all then :/

zeank, what cases are those?

in our scenario we exchange let's call it meta information between clients

as messages though

and we don't want to trigger a push for those

Servers need to not act on hints, because you almost never want a remote client being able to tell your server what to do about things like storing or copying or pushing.

typing notifications could be another

why would servers trigger push notifications on body-less messages

hm, fair point in our case all messages are body less because they are encrypted and have no body in general

it's a proprietary system

just thought it might be useful for others as well

@Kev so the whole XEP is wrong?

I think we need a common ruleset for decisions about pushing, carbon-copying and MAM-archiving of messages.

zeank: I thought 334 said that they were just hints, and entities didn't have to honour them.

Kev: the alternative would be to encode stateful processing rules in the server, right?

But if it really says that a remote client can choose whether my server puts things in my archive, then yes, it's of limited applicability (rather than wrong, as it might still be useful in closed systems), and we need to be very careful about anything depending on it.

yes, they are just "hints", but they are targeting the behaviour of the server, not sure how push and MAM are so different in this regard then

zeank, that proprietary system sounds interesting if it can encrypt even typing notifications, which OMEMO currently can't afaik :)

we don't have typing notifications yet, just to be clear ;)

:p

Kev: do you happen to have an idea how to make the desired functionality of hints secure and proper, in the context of the right trust boundaries?

Ge0rG: Put the rules in the server not the remote client, is all I have.

As for the copying of messages, doesn't XMPP core allow the sender to control this by addressing the full vs. bare JID and using certain message types?

What gets archived by the server is very clearly a server decision, not a remote client decision.

Holger: Not with carbons.

right, but there are currently few sensible guidelines on that, not?

Kev: "A message of type 'chat' is not eligible for carbon copies if it contains a body and the body starts with the verbatim string '?OTR'"

Yes then XEP-0280 breaks this, which is why we need hints for that :-)

:p

Holger: actually, the remote party can only choose between "deliver to THIS resource" and "deliver to somebody implementation-defined"

Sure.

and I really despise the last part of it.

I think the desired behavior is to be able to address either an individual device or the account.

because you can't rely on it, but you need to for a proper notification implementation.

we could all agree that "somebody implementation defined" is "nobody, but everyone interested gets a carbon copy" :)

jonasw: that makes sense if all your clients enable carbons and if you make no client-side semantic difference between "real" messages and carbons

jonasw: but the latter will bite you in a multi-client context.

e.g. in the "I have my phone on the desk and use my desktop" user story.

Ge0rG: you need to solve that anyways, no matter if you CC everything or not

because the user can switch at any point in time

jonasw: yes, but you can use carbons as a hint

for the former part: clients who cannot into CC are annoying anyways and they’re gambling on whether they get messages or not as-is

Ge0rG: but you depend on the server implementation-defined mess if your peer always addresses the bare JID like your client does ;)

I’d rather use xep 84 as a hint actually.

> clients who cannot into CC are annoying anyways said the pidgin user

yes, that means that I must know, Ge0rG.

It's obviously getting complicated and complicated, on the client side. This is the opposite of the general idea of XMPP, but we could do something like this: on received message: if (message is carbon or sent to bare JID) and (we got presence/activity from another resource of our account recently): delay notification by a 1-minute timer which is cancelled on activity from another client

Conversations does the "we got presence/activity from another resource" check.

Holger: Conversations does many things that are not codified. While this is good for Conversations users, it makes it harder for future client implementations

A better solution might be looking at the CSI state. Then again, at least desktop clients probably just don't have a good idea of whether they're currently active or not.

What about just reading tea leaves?

I think 'implement Kev's upcoming read-sync XEP' might be a good approach ;)

I really need to write something there, though :/

Ge0rG, that won't float well with coffee enthusiasts

Tobias: they wouldn't even notice, if we provide centralized access to tea-leaves-entropy. Otherwise, we'd need to kindly ask the user to make a photograph.

Kev: the read-sync sounds like a more explicit way to tell other clients that messages have been read. I'm not sure if it will also help in the notification-delay/prevention situation

Well, it helps, because it's an explicit way of knowing that a message doesn't need to be notified (or that a notification can be cleared), but it doesn't prevent you needing some logic somewhere about delaying notifications, indeed.

I think that's just the cost of doing business.

Kev: will it be similar to chat state notifications?

Not particularly, no :)

Kev: why not?

Because CSN go to the other party, and read sync goes to your server, and from there to your clients?

Hm. So it's an account-centric thing.

Yes.

Kev: you could send CSN to your own bare JID :-)

and let carbons do the rest

jonasw: it would get reflected to yourself.

exactly

jonasw: That doesn't work for saying which messages are read, though.

there is no xmpp primitive to "send something to all the other clients of yours"

Kev: yes, but isn’t there something for that already?

Ge0rG: ah, that’s what you mean

Ge0rG: well, we may need one

one could use PEP

ugh

Ge0rG, with carbons there is, not?

Tobias: all *other* clients

Tobias: what'd be your destination JID? the server?

Ge0rG, your own bare JID? :)

message to "account-domain.xmpp" would get carboned to all other clients

Tobias: no. you'd get the message twice

on each resource (once as <sent/>, once as <received/>)

Tobias: first the 'sent' carbon, then the delivered message/carbon

except on the sending client, it would only get one copy

Ge0rG, "at least once" semantic is easier than "exactly once"

Tobias: but using the "most probably twice" semantics is just wrong.

What's wrong with PEP BTW?

redundancy!

and that would be the last XMPP related fosdem talk tweeted about

which reminds me: we could use a new post for the blog. Anyone interested in writing one?

Guus: what should it be about?

Ge0rG, federal reserve, rainforest, and that sort of thing

Tobias: xsf world domination plans? Because it's a greater challenge if we announce the plans in advance?

we already have a retracted XEP for that :P that should be enough of an announcement

Retracted? People don't even care about experimental...

Ge0rG: I have no specific agenda, other than trying to help make sure that the blog gets regular updates. So far, I've reached out to Daniel for an OMEMO post, and Rikard for an IoT one.

well..it's kind of hidde

*hidden

If you have a good idea, feel free to submit something. You can easily add a blog post via a PR on the website, or send it to me by text, and I'd be happy to post on your behalf.

Ge0rG could write about how snarky comments in open standards communities result in improved protocols ;)

Guus: sounds good to me. I'm sure nobody wants ME to write a guest post.

or more seriously, about his efforts on improving UX and usability

Ge0rG: guest? you're a member, right?

Guus: right. But I'm not a regular contributor to the blog.

Tobias: im sure that would get flagged immediately because of neutrality concerns.

Ge0rG, a blog without regular posts doesn't have any regular contributors at all

Ge0rG, we could neutralize it

Ge0rG: I wonder if anyone considers themselves a 'regular blogger' here. There's people that posted more than others, but that's more because of a lack of input by the others. :)

Tobias: also, what would be the target audience? It seems that it's widely irrelevant to users, and there are two camps of developers: the ones who don't care, and the ones who have no time to improve

yeah...try to channel that optimism into words for the blog post

(no response, which presumably means he's drafting a post!)

I feel a bit like Aragorn, having his motivational speech before the fight of helm's deep. Except there is no army. Actually, now that I think of it, it's probably more like Tyrion Lannister's "don't fight for your king" speech.

so, you're good with words...

Ge0rG: You might be making a bit to much of it :)

Guus: this is probably a sign that I'm overqualified ;)

Ge0rG: Perhaps. You should take this as a challange to see if you can lower yourself to our level!

Ge0rG, it might result in more users demanding better usability for their clients, who knows

Tobias: quite seriously, I'm not sure how to frame the whole thing. "Here is this new set of ideas how to make XMPP better"?

Tobias: the obvious question for the readers would be "why are they talking about it, instead of just doing it"

Ge0rG: perhaps frame the fact that we need a solution for a probem? "Clients look aweful, we could use an effort to stream line things. We've started doing that at xyz"

(but nicer)

Ge0rG, well..it makes little sense talking here about it, as you already made your point and few new people come here

i think our blog has a wider target audience than this room

Also more tweetable.

Tobias: do you have access to pageview stats?

no

i'd also would like to have access to xmpp twitter account analytics...to see if all that tweeting increased out followers (it did, but how much)

Guus: the next problem is: I'd really like to use specific examples of how things can be improved, namely conversations and (to a degree) yaxim. But then it'd result in something like https://yaxim.org/blog/2017/01/31/yaxim-0-dot-9-security-easy-xmpp/ and obviously violate XSF neutrality in a way that's hard to neutralize

Ge0rG: I'd almost consider that a follow-up post. I'm not to bothered by the neutrality thing (but others disagree), but, referencing to Yaxim as an example should be fine I think - more so if you can reference another implementation too

I fear that even mentioning https://github.com/ge0rg/easy-xmpp-invitation which is really client-agnostic (except for the hardcoded list of yaxim+conversations) would be seen as a violation

There's always goign to be someone that sees something as a violation of something. If that stops people, nothign would get done.

Guus: +1

Guus: I just extrapolate the previous feedback I've received from XSF members to my public statements about the state of XMPP.

Guus: if I disregard that, I can imagine writing a call-to-action post about Easy XMPP. And I'll try hard to make it as positive as possible

Ge0rG: you might generate more feedback than others here :)

Guus: I'm not sure if the feedback I generate is of the right sort.

Ge0rG: I'd love for you to draft a rough outline of a post. We can do a PR on that, and have some reviews.

Guus: deal

awesome, thanks!

and again - I think it might be a good idea to smear this topic out over a couple of posts. One that describes the problem and the approach taken to start working on a fix - another one that describes a few of the fixes, and more that illustrate how individual implementations are now improved. Then, a final one where you claim victory.

Ge0rG: there might be a handful of posts and world dominition in this for you ;)

Guus: I don't aim for world domination

Guus: all I want is a nice big yacht. :D

Ge0rG: if you want, I can put you in contact with one of my Nigerian royal friends who badly need to transfer money out of the country? Supposedly, that's a win/win and risk-free.

Guus: I think I'm already in negotiations with that person

:)

Ge0rG: I am sure then that your ship will litererally and figuratively come in any minute now.

Tobias: could you do a review of https://github.com/xsf/xmpp.org/pull/185 ?

I think it's ready to merge now (finally)

will do this evening

Thanks

is my dynamic list generation code live already?

jonasw: I think so, yes.

then we can start the attack on the quality of listed software, right?

I fixed the problem that prevented a bunch of commits to go live, after which the changes that were visible to me popped up.

with requiring projects to re-request their listing and so on

jonasw: I see a blogpost in your immediate future :D

ugh

pelican-based blog?

yup

can do

tx

but I might forget

add something here: https://github.com/xsf/xmpp.org/tree/master/content/posts/blog

I’m super tired right now, not sure if writes to my task memory persist currently :)

no worries, I'll be here to haun...remind you.

Guus: https://github.com/xsf/xmpp.org/pull/274 - I'm sure this will ignite a discussion.

Thanks Ge0rG. I responded on github

Guus: the verbatim tldr will get out, but I'm used to make the first paragraph of long posts effectively a tldr

Ge0rG: that might be a sign that the text is to long for a blogpost :)

but, a matter of personal preference, probably

My main point is that I really dislike 'tl;dr'

Guus: I'd say it is a sign of respect to the prospective reader. I tell them in a single paragraph if the remaining part worth reading.

*is

personal preference. :)

go for it - it's your text.

Guus: thanks for your feedback. I'll update the pr when I find some more time

Guus: you could call it "Abstract", is that better?

jonasw: what's wrong with an implicit "summary"

I don’t know.

So... The only point where mam:2 makes any difference is in the one place where the XML namespace is not used.

... and this has no impact *at all* on MIX.

Question, UX experts.

Hypothetically if you were writing an XMPP client and wanted the experience when opening a chat from within a MUC to not suck (i.e. to open to the real JID instead of the room JID) in the usual case, how (if at all) would you protect it against spoofing on untrusted remote MUC services?

Kev: you are talking about private chats?

Hypoethetically, if I were using an untrusted remote MUC service, how stupid would I be to be sending it messages anyway?

It depends on the trust, I think?

with my UX hat: I'd just open a chat wit the bare JID advertised in the MUC. with my security hat: what dwd said.

Kev, What are you trusting it to do and not do?

I mean, I may trust my inane discussions to something, but not want it to be able to lie about someone's real JID and have me spam a helpless person directly.

Kev: this is the same security concerns I'm pondering about for some weeks already, in the context of mediated vs. direct MUC invitations

Kev, That's not a security concern.

Turning occupants into a DDoS probably is :)

Kev, That's a concern you might annoy someone, not a concern about leaking information.

I don't think I said anything about it being a concern leaking information, did I?

(Or even security)

Kev, Hardly; you're reliant on having users PM people. And if you're a remote MUC, you can spoof the PMs directly, causing people to get any responses.

You can't spoof the PM as being from my server, though.

Kev, No, but I can spoof them as being from you, via a MUC.

Yes. I'm thinking about people not in the room at all.

Kev, Who isn't in the room?

You annoy me, so I tell all jabber.org MUCs to say that every occupant's real JID is yours, and then you get spammed every time someone tries to send a PM.

Kev, That was you?

Kev, You git.

I do.

Although I don't tend to use it as a verb.

Regardless, this feels like it might not be ideal, to me.

Kev, True, that would be subversion.

Very good.

Kev, OK. So I think the "real-jid" issue here remains irrelevant. It's one case where a (popular) MUC service could abuse trust.

I'm pondering possible options being "Meh, you're in the MUC, you're showing some trust", "Do it if it's someone in your roster" (so you can probably work through the social issue if it gets spoofed), "do it if it's a local service". (where 'it' is opening to the real JID).

Kev: I think the only sane solution to that is having MUC presence signed by the user's account key.

There's also revealing your own JID in the case that you're a moderator in a room.

Ge0rG, Seems fair.

How do you know what account key is the right one?

Kev, I think any of your options is fine.

Certainly the irritation of having PMs outside your normal flow is significant and I want to fix it.

Zash, By asking the MUC for the public key of its occupant of course. Duh!

MUC can't lie

MUC real-JID dial-back verification? When you want to verify a JID in a MUC you send them a token (through the MUC), and then they echo it back via their real-JID. I'm not sure this is necessary either, but it's fun to think about.

Zash, Evil-MUC-bit?

Zash: you query the bare JID for a signed presence, or check your roster

SamWhited: Sure, but that only works if you've running over jidnssec, which no-one is :)

Kev: may I point you to https://mail.jabber.org/pipermail/standards/2017-January/032021.html

Kev: jidnssec? Not sure if real thing or a joke I didn't get…

it's a DNSSEC deployment joke

Oh, heh, right

SamWhited: It's a joke. You mentioned dialback, which is a fine thing to use for S2S as long as you have dnssec.

(And you also use TLS).

and .im domains can't do DNSSEC because people from the isle of man are afraid of locsk

*locks

I think it works in this case though if you trust the s2s connection at all

(the s2s connection doesn't have to do dialback, I just used that name because they're echoing an HMAC or something back at you)

Yes, it's not a stupid idea.

You'd have to do it two ways though for mutual verification, so there's probably a better way

SamWhited: like... distributed MUCs

or maybe we need to replace JIDs with pubkey-based identities

Ge0rG: I'm assuming this was a question for a MUC implementation today, not for a future-widely-used-thing implementation.

or we just ignore the problem and pretend it doesn't exist.

Let's build an elaborate PKI!

The world needs more of those

Or we introduce a "security level slider" into our apps, ranging from "I don't care, just make it work" to "I'm ultraparanoid"

(And thanks all, BTW)

Ge0rG, Excellent. The world need more security options that users don't understand the implications of.

Kev: so have you come to a conclusion how to do it?

Ge0rG: Key based identity would be interesting, but I don't think that's even XMPP 2, that's gotta be something completely new.

dwd: most users don't understand the implications of any of the security options provided to them.

Ge0rG: I think the conclusion is "Meh, just do it"

Zash: TOX maybe. It's got an "X" in it at least.

Kev: this conclusion was also reached at the end of the lively security debate in the thread I pointed to.

FWIW, for mediated invitations, Swift shows it but warns that it could have been spoofed.

I can't remember if we replied to the thread or not.

But the whole mediated invite thing is horrid anyway and everyone needs to just use direct invites :)

Kev: direct invites don't auto-add the receiver to the MUC affiliation

Ge0rG, jet fuel can't melt steel beams

Ge0rG, i think setting up specific affiliations for participants is a quite rare use case

Tobias: I want to have a private group chat with my family members. Do you have an idea of the steps I have to perform to achieve that, client-side?

Hint: none of them are described in 0045.

Ge0rG: You open Swift, you choose 'start chat' and drag all of them into it? :)

just create a UUID MUC and invite the people you want to join

Tobias: but I need to make that MUC invite-only and hidden.

I think there are some forms to enable that.

hidden yes, invite-only (why, who will know the JID?)

Tobias: and then I need to add all the folks into the affiliation

Tobias: so you are using the JID as a password?

basically, yes

Am I the only one who thinks this is significantly worse than following invites from a remote untrusted MUC?

Ge0rG, what's your fear? people guessing the JID? that one of the participants leaks the JID?

Tobias: accidental leaking of the JID

how?

Tobias: pastebinned client debug logs, server bugs

what says the way you'd accidentially leak your JID wouldn't also leak the password if it were password protected?

Tobias: JIDs are not generally considered "secret"

Tobias: by violating that assumption, you are bringing your users one step closer to the abyss

Tobias: leaking a password requires gross negligence

User probably shouldn't see or know that a JID exists (especially if it's really just a UUID), so I don't see why it matters.

well...if you want to provide a true sense of security to your users you should do OMEMO in the MUC anyway

Tobias: my point is that it's good to have additional guards

and "closed affiliation" is one such

Tobias: For OMEMO you want to have the group members affiliated with the room anyway, though :-)

And simply for listing the offline members of your group chat.

And because you want that anyway, you can just as well make the room members-only (since *this* step is simple).

i wish there were a XEP for taht

*that

For what?

Holger: for creating a members-only private MUC, I suppose

I'm going to add that to yaxim soon, and write it down in the process. I'm interested in such an XEP as well

Sufficiently interested to actually write it, if nobdy else *cough*daniel*cough* jumps in.

https://wiki.xmpp.org/web/Easy_Group_Chats is the first iteration

I've had another crazy idea: to use the "long description" of the MUC to store a link to an http-uploaded avatar

I think it's all in 0045 even though it wasn't written with that use-case in mind.

Holger: you must be talking of https://xmpp.org/extensions/xep-0045.html#createroom-instant

(Except for an option to enable MUC MAM for servers who want to make this configurable.)

Ge0rG, no I wasn't suggesting an instant room. Maybe I'm missing something but what I have in mind is simply using a plain members-only room with MAM for private/presence-less group chat.

Holger: and where is that written down in the XEP?

I'm not quite sure what the use case of the 0045 "instant room" is, except for being comparably bad to instant soup.

Only the building blocks are there of course. It doesn't say "to create a private group chat, do this and that".

Holger: but I want it to be in there.

Holger: your statement is comparable to "all the building blocks for a group chat are in rfc 6120+21" :P

Ge0rG: I don't think that's comparable; 0045 adds protocol on top of the RFCs while my point is that you don't really need anything on top of 0045. But I see how a document explaining how to use 0045 to implement group chat would be useful.

Holger: I would even 1-up that and say that 0045 should contain it

maybe the council will not be strictly opposed to adding a new informational section to 0045

Sounds good to me.

But first, I need to sort out #418 and #436

Ge0rG: XEP-0280: Add 'Usability Considerations' section #418 https://github.com/xsf/xeps/pull/418

And maybe #204 should be sorted out first as well :-)

Holger: XEP-0045: Define option name for enabling/disabling MAM #204 https://github.com/xsf/xeps/pull/204

Holger: btw, being a server developer. Would you rather prefer more rules in 0280 clarifying what to do with [xep 0184] acks and [xep 0333] states, or have those two contain explicit <copy> hints?

I think adding more rules to 0280 modules is wrong.

+1

+2

https://xkcd.com/1810/ is sad.

+3

case in point: 0184 does not mandate to use type=chat

Indeed. I use local patches that add rules to fix such things :-/

but Kev said that we shall not rely on remote clients telling us what to do

And I disagree, at least when it comes to addressing accounts vs. individual devices.

Does anyone here have any idea how communication with IANA should work? I've been googling things like "IANA registration procedure" and "IANA expert review rules" and so far everyting is completely undocumented and worthless as usual⁢… *grumble, grumble*

Email someone. ???, PROFIT!

I found one old document that explicitly said that IANA procedures were currently not documented, so I'm just about ready to assume taht's still right, everything is tribal knowledge, and then just start spamming people until someone updaets the registry.

hargh - the US went to/from DST?

Yup.

Guus: Yup; be warned, everyone on this side of the pond is confused and grumpty today (actually, that's most days, but *more so* today)

Which explains why this meet is pretty empty...

They probably measure DST in furlongs per fortnight or something.

It's bad enough that we have DST in the first place - but everyone having a different date when it kicks in does not help either...

DST: collectively tricking your employers into accepting it's okay to start and leave an hour earlier.

on a slightly related note, I'd really love board meetings to be one hour earlier.

Oh typical, and the IANA contact apparently doesn't work for Cisco anymore so the only email listed is broken.

Found a personal email; let's try that.

Oh no, matt already forwarded it. Convenient.

https://xkcd.com/1810/

SamWhited: sorry, I can't help but feel this is all my fault :-)