XSF Discussion - 2018-08-02

18:38:57 lovetox> one could do it that way, but then you would have to check from time to time, if your db stored prekeys are really the ones that are published you have to do that anyways because PEP services tend to "forget" your stuff from time to time

Isn't it awesome how the xmpp and OMEMO identity models extend each other?

I sense sarcasm

Ge0rG, sarcasme? Nahhh...

Ge0rG, while it's trivial to change that?

flow: one of the strong opinions that I hold is: if you want cryptographic identities, you should have a protocol using those as a first-level citizen, not tacked upon another routing protocol

Ge0rG, I know. But what do you suggest an xmpp based e2ee protocol should do? Using the public key as one's JID localpart?

flow: I think there needs to be a stronger cryptographic link between the user identity, the key material and the JID.

flow: if I was doing things, I'd go with user keys that contain a signature of the JID, plus maybe an S/MIME like CA system

"signature of the JID"?

or a signed statement of the user's JID?

The latter.

I'm also not sure how that prove ownership of the JID

It doesn't. But it means you can't move a key to a different JID

And preventing that is desirable because?

flow: I'm not sure. It's just a bad gut feeling, nothing specific. Maybe abuse of sloppy implementations leading to impersonation of other users...

Ge0rG, So if you would be designing things, the main difference would be an additional signed statement of the JID and that only because of a gut feeling that it would possibly beneficial. Or did I miss something?

flow: the main difference is: I would go with a two or three layer architecture. A user has their identity key (or primary device key), and signs their secondary keys. Plus a means to have a CA signing user keys bound to JIDs

Let me focus on the CA thingy first: What is the advantage over a CA verifying the "identity" by signing user keys compared to the public key in PEP? If you consider Let's Encrypt, then LE just checks that you have control over a certain "namespace", which is pretty much what public key in PEP provides.

What additional benefit do you envison could a CA provide?

flow: good point. A public CA doesn't help in needing to trust the server, and no amount of OOB will help

A corporate CA might help, but then it's probably operated by the same people the server is

The major problem I see with OMEMO is multi-device key management. A client message of "You seem to have added a new device at 12:10, with the following fingerprint: ... - correct? [Yes] [No]" with a cross-key signing is vastly better than forcing every one of your contacts to manually verify that fact.

Ge0rG: I like the idea a lot! Has this been discussed before?

Syndace: I suggested that to daniel back when OMEMO was being designed.

The idea was not approved.

Hmm, is there a mailing list thread or do you remember the reason?

Apparently because automatically trusting a new key which is signed by your friend's old key is a security issue.

Or maybe because signing keys is not trivial. Or both.

Why not share the key?

That seems easier than cross signing

daniel: what exactly do you mean by "share the key"

Using the same key

Like OX

daniel: ah, a user key as opposed to a device key

How do you get the key to the new device

Syndace: QR code with a red border:P

Yeah. Or put it in the cloud

True, but then again, if one device gets compromised, all of them are

Syndace: yes

Syndace: but that doesn't matter in practice.

And that's the same as cross signing

Syndace: if one if your devices is compromised, the attacker gets the local history of that device and everything sent to you

The cross signing issues don't matter as well

daniel: as stated above, I prefer user keys to device keys.

daniel: I thought that OMEMO required device keys anyway, so a two-tier key arch was my second best suggestion

daniel, no, it’s not the same as cross-signing. a malicious key added by cross-signing can be removed individually and the damage is contained. if all your devices share the same key, you have to roll your key over entirely to fix the damage. right?

or cross-signing

How do you revoke a key though

start with a new user key.

I mean in case of device keys

What I'm saying is that I don't see the benefits of cross signing of sharing the private key

daniel: you *could* add revocations to cross-signatures.

hm

the point that I made in the beginning (and am still making) is: with the user managing their own keys, you have O(1) key management overhead. With the contacts managing the user's keys you have O(N) for N contacts, and you have zero decision agency

did Daniel just buy a new Pixel phone, or is the NSA impersonating? How am I supposed to know?

It's not news that trust is hard

daniel: and you are making it even harder.

Than?

Otr?

daniel: harder than needed

Otr allowed for funny questions that I didn't knew the answer to

That was pretty fun

daniel: are you still on holiday? Have a nice time and let's talk seriously when you're back

Ge0rG, I still don't know how "xmpp and OMEMO identity models extend[ing] each other" fits into the picture, and what you suggest should change

flow: apparently it wasn't clear to everybody. My statement was utterly sarcastic.

Ge0rG, so besides cross-signing keys, you are happy with omemo?

flow: I'm happy with ignoring its existence.

It appears you are not very good at it

flow: for practical matters, I am.

obviously, I can't completely ignore it with my Council member hat on.

alright honestly, why is the hate against omemo so huge in this whole community? I haven't had problems with it, not one single time.

because checking fingerprints is a pain? because "This message is OMEMO encrypted, your client does not seem to support it"?

A little bit of both probably. And people also like to complain about things

that's far from enough reason to spread such hate

That's the internet

I don't think anyone /hates/ it, it's a protocol. I think several people see there are issues with it.

And other people think that E2EE should be enforced upon everyone, which leads to hate indeed.

that isn't specific to OMEMO

E2EE by means of OMEMO.

And then non-technical users complain that their messages don't get delivered, and we have one *additional* place to look for.

Someone spent months trying to contact me once, but they had mod_require_otr enabled on their server and I couldn't reply

and the only contact I had for them was their JID

I had a similar situation where I logged into my account with Conversations to test something, and then a bunch of people couldn't message me anymore

MattJ: should've sent them "?OTRv2 hi please disable mod_require_otr"

Ge0rG, more than one place, because OMEMO is such a mess of moving parts

MattJ: yes, publishing an OMEMO pre-key wreaks havoc to all your other clients.

I don't consider myself an "OMEMO hater" though, I think I've rarely mentioned it... I've many other things to complain about before I could get to that :)

jonasw, is it such a mess?

> MattJ: yes, publishing an OMEMO pre-key wreaks havoc to all your other clients. What?

MattJ, with the unstable PEP implementations out there and inconsistency in handling of OMEMO messages with and without surrogate body (on all levels), yes

Both seem like things that could be relatively easily fixed

A non-PEP key distribution protocol would be pretty trivial

MattJ: > Both seem like things that could be relatively easily fixed The story of XMPP.

Ge0rG, some things are more easily fixed than others :)

OMEMO does not seem like our worst problem by far

Syndace, some of my clients don't support OMEMO, I don't particularly want to use OMEMO either

What about: When starting a new chat, the client sends the messages unencrypted in the message body AND encrypted using OMEMO at the same time and based on whether the response is OMEMO encrypted the client decides whether to stick with omemo or go on plaintext

Syndace, I think my problem is more with the way Conversations enforces it, than the protocol

Syndace: doesn't work in multi-client scenarios

What does mutli client scenario mean? group chat?

Syndace, multiple clients on the same account

which just about every XMPP developer has

True, all of them need OMEMO to receive the message

all of them need to support OMEMO and have their prekey published and trusted by the sender

that's a large number of moving parts.

yeah i see

especially if you test multiple desktop clients, multiple mobile clients and do web sessions from time to time

so you either end up with one client polluting your PEP with keys, leading to all your contacts sending you garbage, or with other corner cases of the protocol

As long as clients don't go enabling omemo for you automatically, which would obviously be broken, I don't see this as particular problem.

Or, rather, not something that can be solved.

Because once you hit the "I want to e2e" switch, you *want* to avoid non-e2e clients getting plaintext.

Kev: I've heard that Conversations will auto-enable E2EE.

And so you're just not going to flick that switch if you want to use non-e2e clients. Irrespective of whether that's omemo or other.

Ge0rG, Conversations *does* auto-enable E2EE

even if no keys are seen.

(you get a warninng and an option to disable when you send a message then)

Besides of this, there is no secure way to communicate the status of that hypothetical "I want to e2ee" switch.

't

Ge0rG: Well, there's HSTS-ish at least.

Ge0rG: You want to rhyme it to "to break free"

Then it works.

Kev: except that HSTS relies on a semi-corrupt CA hierarchy

Syndace, and here you get the problem described by XMPP developers. When we (e.g. I'm a server developer) have to deal with users who encounter these problems and want to know why their messages are not being delivered... it's extremely difficult to help them

Do I not mean HSTS? I mean "Ok, I'm telling you now, don't use me in the future if I stop encrypting", anyway.

I don't want to be used by Kev

irregardless of E2EE

Syndace, I think that could be solved with better tooling (as well as improving client UIs)

Ge0rG, lol

That's what you think, but you're mistaken (Ge0rG)

get a room

jonasw: if only MUC invitations were working reliably.

I think it's a very bad idea that clients enable encryption even if they know that one of the receiving devices does not support it. Silently dropping messages is a super bad idea confusing WhatsApp-level users

Syndace: there is no notion of "user's devices" so it's impossible to know whether all devices support OMEMO

Syndace, problem is: if you don’t do that, servers (which are the bad guys™ in the e2ee scenario) can trivially downgrade you to plaintext

jonasw: They have to do it from the get-go, though.

Kev, in your case, yes

Well, depending on exactly what's implemented :)

Right.

Made it just in time 🙂

The question is, who else did? :)

You, for one. 🙂

nyco, around?

ralphm seems to have been popping in and out, I think he's on mobile

nyco mailed that he was not going to be here today.

Martin?

Oh, missed that

Oh, Gmail marked that thread as "Not important" and I overlooked it

that'll teach you to have such a filter activated on my name. 🙂

Shall we try this again next week?

Yeah, I think so

btw, Martin != Martin Hewitt

ah. didn't know, tx

ok, I'm off for a bit then. ttyl!

See you :)

So, I collected the OMEMO issues that I was able to filter from the short discussion earlier and wrote down my thoughts and ideas about them: https://hackmd.io/x70DAtLgSHqBzke49_vBrg I'd like to hear whether I grasped the core of the issues and whether my thoughts/ideas make any sense lol. Also please tell me what's missing and feel free to add your own ideas and comments.

Syndace, Are you aware of the MLS work under way in the IETF?

Oh boy, I was not

Dave Cridland, I'm assuming you are following it because you keep talking about it. How far is it from something everyone can implement?

Syndace: we can't send some data becose there is not full stanza encryption. I'm specially missing xml:lang like I've explained on the @standard list (and some other like message markup).

Syndace, section 1, Idea #2 seems waaaay too complex

jonasw, well but I think it would fix all issues at once

MattJ, Early days. But it's got some serious people working on it. You can actually get libraries and work with the current design, but it's approximately as scary as using TLS 1.3 draft 3 - chances of everything interopping in the future are pretty low.

at the cost of UX, Syndace

MattJ, I'm not saying we should switch now. I'm just saying we should be prepared to write off OMEMO as an experiment in a year or so.

jonasw: True

Dave Cridland: Well great.

solving bad UX by making it worse doesn’t seem good to me :)

jonasw: Not worse I think

Dave Cridland, I don't think that's a reason to not attempt to fix problems we have today in parallel

If MLS is ready in a year, it's another 2-3 years before clients implement it widely enough

jonasw: Do you think it's a super UX killer if you have to select which devices you want to exchange encrypted data with?

meanwhile OMEMO is already quite popular today, even Pidgin supports it

MattJ, Well, I think we have an opportunity to show XMPP can be leading edge in this kind of thing.

Sure, I'm up for that

But the carousel of E2EE solutions is also a bit of a joke by now

Syndace, yes, other systems have E2EE without such annoyinaces

MattJ, Yes, indeed.

MattJ, no, pidgin *does not* support it.

Let's not leave what we have working today at 90% for the next 1-3 years

pidgin has two plugins both of which have their own quirks

and it doesn’t even "have" those plugins as in they’re distributed, no, you have to get them from somewhere.

jonasw, that worked against my argument, so I glossed over that (but yeah)

Dave Cridland, MattJ, if we’re going to do another round in the E2EE protocol carousel (good term by the way), I’d suggest to tackle (nearly) full stanza encryption, to at least give it a benefit over staying with status quo

jonasw: Is there a comparable system which allows multi-device e2ee where some devices do e2ee and some don't?

Syndace, I don’t know, actually. but users won’t care about that

in the end, you can have signal/whatsapp/whatever on botth your laptop and your phone and it works just fine -- even if on your laptop, you just view stuff which is on your phone via webrtc or something

and competing against that with a complex selection dialog whenever you want to do e2ee, just nope

jonasw: We could reduce it to "start private chat" which just starts the chat with all OMEMO-enabled devices and doesn't ask which devices should be included

That way it would be a button click

Syndace, and then we’re exactly where we are right now

but not by default

jonasw, Sure. But given MLS also handles group chat (in fact, it *doesn't* handle anything but), that shoudl also provide impetus.

Dave Cridland, OMEMO handles group chat today

jonasw: Not really, because it's two seperate chats: One plaintext and one encrypted and the important thing: The user is aware that not all devices will get all messages

jonasw: is there a spec for that?

jonasw, Sort of. It handles groupchats by keying M times. MLS does it in one.

goffi, dunno

Dave Cridland, sorry, I have no idea

I just know that it is possible

goffi, Good grief no. Did you think OMEMO was one of those *open* standards?

I know Conversation and Gajim handle it, but I think it's unofficial for now (i.e. no XEP)

Syndace, "but other systems do have e2ee by default, why can’t you?"

jonasw: Because we don't forve you to use it. You can though, by clicking this button right here

e2ee as an afterthought is going to be infinite pain whatever way you do it

goffi, I'm not sure a spec is really needed

Syndace, that doesn’t need any additional magic though. just *some* clients stepping back from the "OMEMO by default and everywhere" paradigm

goffi, it's just MUC, you fetch the keys of all participants

goffi, I think they just parse the MUC-style JID into the normal JID and then use OMEMO as usual

Zash, WhatsApp supposedly managed to do it as an afterthought

Gajim told me last time I was in a MUC for testing, that it was working with member only rooms something like that (don't remember the message)

jonasw: WhatsApp has one binary and forces usage of e2ee, would be easy with these preconditions

this should be explained in a XEP, even if it's short

(or three binaries for each OS, whatever)

jonasw: supposedly. also they're one company who do all the clients

I suspect we'll need an HSTS equivalent for E2EE, certainly, and then move plaintext->opportunistic->e2ee-always

if clients were registered and known by the server then maybe

we are still blocking a bunch of XEP with OMEMO by default

as long as there is no full stanza encryption

Zash, I suspect client registration has ot become a Thing, anyway. There's a whole lot of optimizations we could do if we had that.

no more last message correction, no more in band real time text, no more, no more language detection, no more markup.

goffi: but we have the markdown-ish thing now /s

goffi, but markup is in the <body/> nowadays anyways!!

goffi, Honestly, you needn't argue for full-stanza. ESessions had that a decade ago, I have no idea why OMEMO doesn't.

jonasw^5

Zash: don't tell me :'(

Dave Cridland, possibly because time-to-market mattered more than doing things right?

Zash, ^5

jonasw, Probably.

Dave Cridland, I’d love if we could maybe not repeat the same mistake with whatever MLS integration will happen.

jonasw, Yes. I'd like to do that one right.

Any info on how/whether MLS handles mixed plaintext-only clients and encrypting clients?

Dave Cridland, Zash, if it ever gets less hot so I can think straight for more than 5 minutes in a row, I’m going to try to make some device identification thing in prosody. I need per-device passwords anyways.

If we had device identification we could issue a simple warning: "If you send this message encrypted, only jid: phone and jid: laptop can receive the message. jid: web and jid: work can not."

I would argue that I rather use OX by default, I'm less interested in PFS that in mentioned features.

jonasw: I hear MattJ was working on that

and OX do full stanza encryption.

jonasw, er, yeah, I have a mod_device_tracker

I can publish it later today or tomorrow

MattJ, I’m thinking about doing things in SASL

MattJ: tracker!! I knew it

pep., it's ok, it asks for consent

jonasw: FWIW you could have per-device usernames too (or username+device), since they need have no relation to the bound JID

Zash, I was more thinking of using the second identity one can pass in sasl

if it’s a full JID with the bare JID equal to the one you’re authing for, the resource is the device ID

jonasw: modulo client support

Zash, yeah...

but do clients support getting forced to a different bare JID?

Sure

I need to have tests for that.

I’m not sure what aioxmpp would do

+1

Moar tests :)

Zash, fun fact, I’ll probably go for device@username for per-device-passwords in IMAP :)

jonasw, See https://tools.ietf.org/html/draft-cridland-kitten-clientkey-00

jonasw: Have you noticed the client-uses-full-bind-something pidgin sends in the stream start?

Zash, no

jonasw: Which had something to do with GTalk

Dave Cridland, in my scenario, the devices would never learn the actual account password

which is something I’d like to have

actually, this is uspposed to be client certificates lite

because client certs are hard

It could assign you a different hostname even, if you had whatever the hosted domain thing was

Zash, crazy stuff

need to keep that in mind; that might be useful to have to support legacy clients

sure

There are some modules in Prosody where the SASL username ends up differently from the JID localpart

interesting

Some PHP forum one for example

One where you can have characters in the username that don't pass nodeprep

jonasw, Do a PIN-check on another session? But anyway, I'm happy to knock around idea on that with you.

Dave Cridland, sounds good, but as I said .... it’s too hot here to think

Dave Cridland, my idea was somewhat like this: - to add a new device, you generate an auth-code on your first device and enter that in the new device. it performs either something SASL2 or a variant of IBR to set a password for itself (the password is never shown to the user) - it will always authenticate with that password (somewhat like your CLIENT-KEY I suppose) - server can now track the device, which also means that a user can revoke any device at any time (e.g. lost or stolen)

Dave Cridland, IIRC, client key had the issue that when the counter goes out-of-sync, you need to re-authenticate using the normal SASL mechanisms?

jonasw, Yes. It's designed as a "Remember this device" to go along with TOTP, and not exactly wehat you're after.

mmmhm

jonasw, But that counter is intentional - anyone stealing the credential from the client cannot use it from another device if the original device is still in use - the counter gets out of sync and the server-side token is killed.

I think CLIENT KEY is orthogonal to this, yeah. It could be used in a, as you say, "Remember this device" fashion to temporarily replace the SCRAM-with-device-password+TOTP flow if TOTP is used,.

Dave Cridland, yupp, that’s good

jonasw, Oh, and it's designed such that you can't DoS the token by guesswork or stealing it from the server.

it looked pretty solid when I looked at it back then, yeah

but IANAC

C = Cryptographer?

yes

Nor am I, but I play one on TV.

:D

Syndace: in your pad, section 4 before idea1, you are confusing omemo and e2ee. e2ee doesn't require PFS

pep.: Right.

people suggesting: > In general, a short “yo, please deactivate OMEMO” plaintext answer should be enough. But this can be annoying if it happens too often! clearly have no idea at which level of technological literacy some people operate

Indeed

Syndace, append to your list please "I re-installed Conversations and now I can’t access my history anymore", because people aren’t expecting PFS.

jonasw: lol, yes I know that some people don't know what OMEMO is and how to disable it, come on don't take this so literal :D

Syndace: this is a real world issue :x

jonasw: Better example of what to write?

Our take on encrypted conversations that we plan to implement soon is to have separate encrypted and decrypted chats. Like telegram's secret chats.

Syndace: after having implemented OX (OpenPGP for XMPP) I think one huge improvement that OX is having over OMEMO is the ability to encrypt arbitrary extension elements. I think full stanza encryption is rather unrealistic for xmpp, but you can put all the sensitive data into an encrypted container and be done :)

We should really port this to OMEMO / put it in a standalone XEP and let OX and OMEMO depend on it

Telegram also solves multidevice e2ee quite simply: secret chats are one on one device only.

Andrew Nenakhov: Interesting, who is "our"?

Xabber.

Andrew Nenakhov: the single device part is one of the things that keep me from using secret chats :/

I also hate pfs obsession

nobody has a pfs obsession

its just what we have

Publish a pgp key, share it to all devices, have your history everywhere.

Moxie does :D

we cant just snip our fingers and invent super secure encryption protocols

Andrew Nenakhov, yes you can do that with OX

If you care that much about privacy, don't lose that key.

Omemo was just there first, and its easier to implement

> Moxie does :D A lot of other guys do too. Constantly bombard our issue trackers with demands.

:D I have heard of that infamous bug report ;)

What about a mechanism to synchronize local history from another device? xD

:-D

That bug report is, yes, epic

Syndace, that has been discussed in the past - the protocol is already there - XEP-0313 could work between clients just as it does between client and server

Btw, why would people want "full stanza encryption"?

If you encrypt whom you address stanza, it'll never be delivered 😂

At FOSDEM I heard the idea of establishing encrypted XML streams between clients :D

obviously not the top element..

vanitasvitae, that has also been discussed and done before

MattJ: gajim recently removed this feature

MattJ: Wondering how serious to take this idea

What is there to encrypt besides top element 😂😂😂

every child element?

Would be pretty cool to have history even on fresh OMEMO devices

Andrew Nenakhov, OOB element for file transfers, for example

> Would be pretty cool to have history even on fresh OMEMO devices As I understand OMEMO, this wish goes against all it stands for. :-/

Not if you can sync the local history from your other devices or your chat partners

Andrew Nenakhov: Signal has synchronization between start vices

Between devices*

it can provide this, because it does not have to deal with different clients

lovetox: Doesn't sound very hard to throw the serialized XML into OMEMO instead of a plaintext message for nearly-full-stanza-encryption

this would mean making a protocol for exchanging databases

who said full stanza encryption is hard? as some people point out this exists probably for a decade in xmpp

What about substanzas that are meant for the server (like hints)?

you obviously cant encrypt them because then they are useless

I was wondering whether to treat them in a special way or to just ignore them

with full stanza encryption we dont mean full like everything

we mean all data that are not necessary for the server to function

> Andrew Nenakhov: Signal has synchronization between start vices Doing that is definitely possible in a number of ways, every single of them denying all advantages their protocol has over PGP.

You can sync history directly between devices. You can share keys and download and decipher messages from server archive

But why bother using omemo if you plan to do that?

signal uses omemo aswell (basically)

why do you think they do it that way? because its convenient probably

If you do the backup exchange using OMEMO, you dont lose any advantages of OMEMO

if you do it via OpenPGP however, your whole history is on the server twice, once OMEMO encrypted and once via OpenPGP. In that case you lost pfs due to the OpenPGP copy which can in theory be decrypted in the future.

So for backup exchange you'd want to generate a single-use key.

Why twice? One openpgp is enough.

Backup exchange is also bad ux by the way.

You want your messages everywhere at once.

So in the end if you want security and convenience , just run your own server.

Then you need OpenPGP and you cannot have pfs

Because in xmpp the only ones who are affected by e2ee are server operators.

ho Gajim removed direct stream encryption? What a pity, I find it the most secure way if you have something really sensitive to say

I guess same effect can be achieved with XEP-0396 nowaday

Gajim never head direct stream encryption

and why is it a pity if no client supported that?

Hi, what should happen with MAM when a client did a <query/> without specifying a @queryid? Should the <result/>s also not contain one?

So far I made it required in my parser but I guess it should be optional due to that.

yes Link Mauve correct

dont add a query element if the client doesnt set one

makes no sense, because its a identifier for the client

if it set none it doesnt need it

Yup.

Wut, the changelog of RSM says that the <index/> element has been removed, but it is still present thrice in the text (including twice in examples).

maybe a different <index/> element? *hope*

Link Mauve, attribute vs element?

Nope, I checked already.

flow, nope.

ahh right, the elemnt still appears in the text

Hmm, I think I should split my RSM element into query and result, that would make it a lot easier to understand what’s going on.

Who is 'vm'?

Someone from before my time, I guess.

This one just came up in another room: https://xmpp.org/extensions/xep-0238.html

do we maybe want to deprecate/obsolete/reject that?

it seems to be ... way out of date

and there doesn’t seem to be any interest in refining it

jonasw, +1, although in the past we’ve considered deferred as a tombstone.

But I’m still +1 to explicitly obsolete it.

yeah, deferred isn’t explicit enough

And I think we shouldn’t let XEPs stay in limbo like that forever.

If I implement deffered XEP in my software, may it change its status?

Yagiza, you should send an email to standards@ to explain why imo, then someone will most likely revisit it.

Yagiza: Possibly, especially if you write to the standards@ list or the author with feedback

Yagiza, there are two types of deferred XEPs (and you cannot tell them apart by the status): those which are abandoned, and those which are "good enough" and which are silently implemented everywhere

Yagiza, so if you implement a deferred XEP, post any feedback you have to standards@ (even if it’s just "implemented it, it solves my issue X"), that might trigger advancement to Draft

You may also send a change, anything, something you found missing/misformulated/anything in the text, which would automatically put it back to Experimental.

jonasw: I'd say there's some gray area inbetween, where the author just happens to be busy with other stuff

Zash, I’d call that "abandoned", even though that’s harsh

Zash, can confirm. :-°

jonasw: sounds intentional then, which it might not be

hm, ok

I just want to try implementing XEP-0371 in my client as a good solution for file transfer.

Yagiza, uh... in combination with XEP-0234?

Yes, of course

Also, its implementation may increase chances of successful Jingle RTP session.

This one is an instance of the good kind of deferred XEP.

Link Mauve, so, if I implement it, it may make things better?

yes

Ok. Sounds good.

Higher chance of things becoming better if you send feedback to standards :)

In pubsub#event, I see @node being defined on item, but I don’t see it used anywhere in the XEP.

What and where could it be used for?

Section?

XML Schema.

https://xmpp.org/extensions/xep-0060.html#example-2 that @node ?

This is on items, not on item.

Wait where do you see a node attr?

Line 7007 of the XML file in the xeps repository.

Which object? :)

What do you mean?

https://github.com/xsf/xeps/blob/master/xep-0060.xml#L7001

Link Mauve, might’ve been a mistake

node doesn’t make sense on item

semi-serious reference to git object

hm, unless items from different nodes are batched in a single event

I’ve never seen that done.

But everytime I read this XEP, I learn new things.

everybody seems to say that about '60

And items@ver isn’t specified in the schema. :|

lovely

https://xmpp.org/extensions/attic/jep-0060-1.7.html#schemas-event https://xmpp.org/extensions/attic/jep-0060-1.8.html#schemas-event

Oh no, this is commented in the XML file.

Link Mauve, where?

ah nevermind

Is it actually possible to have a <{pubsub#event}items/> with neither <item/>s nor <retract/>s inside?

Zash, that's implied

“19:09:00 vanitasvitae> At FOSDEM I heard the idea of establishing encrypted XML streams between clients :D”, yes, XEP-0246, XEP-0247 and XTLS. ^^

Link Mauve: yeah I think we talked about it right?

Yes, on the last day, outside K.

Right :D