jdev - 2026-02-07

are there any notable clients that use XEP-0080: User Location ? testing both cheogram and monocles they both seem to just send a raw geotag in the message body and don't seem to use the XEP at all

I think part of the reason is that XEP-0080 in PEP would not be encrypted, but a geo: link can be protected by OMEMO

It's not an unsolvable problem, but that's probably a factor (also geo: links are trivial to implement)

MattJ: maybe we should make encrypted PEP

or at least, an encapsulation of PEP data inside of OMEMO

For me the encryption should not be omemo, rather you encrypt with some symmetric key the pep node and share the secret with omemo

Also there should be a start message to the contact and a end message to indicate that location sharing started and ended

The question is also if pep really is useful here

Pep is useful if you broadcast to many contacts, which will be a rare case with location sharing

So why not simply send encrypted messages in time intervals, and skip all the pep encryption problems

> Pep is useful if you broadcast to many contacts, which will be a rare case with location sharing Not sure if that's a rare case ↺

Sharing location to multiple contacts not in a group?

lovetox: sending encrypted messages in time intervals would be garbage UX tbh

it'll clog the PM chat

unless the client can filter out the unnecessary messages in the frontend

also encrypting with some symmetric key and then sharing it wouldn't be forward-secret

which is why i recommended encapsulating data within OMEMO, it rotates keys per message, ensuring forward secrecy ✏

> Sharing location to multiple contacts not in a group? No, right, the case I have in mind has all people in a group ↺

Cynthia: what's the difference receiving a message from pubsub or in the chat ?

It's exactly the same amount of messages

Hello, I have a question as someone starting to read about the details of XMPP. Are identifiers the only way stanzas get related? Or is the total ordering brought by TCP necessary for the operations of the protocol? ✏

What's a identifier?

lovetox: the difference is that a legacy client will not be able to tell if it's a regular message or just an automated GPS location sending emssage

and will not be able to filter it out from regular messages

causing the PM conversation to be cluttered

Cynthia: of course it will that's what namespaces are for. Everyday clients receive a lot of messages with content they don't support, that's the nature of xmpp

> What's a identifier? hm from what i remember (i didn't save the file while i was prettifying and looking at stanzas), i saw something like `<message … id="68886607-a0ff-4be9-a6f8-9301f238c73d">…</message>` and then for replies something like `<message …><reply id="68886607-a0ff-4be9-a6f8-9301f238c73d" …/></message>` ✏ ↺

A client displays only what it understands and the rest gets dropped

okay well if the message is namespaced, that's a different thing

Évelyne: yes some message reference other messages via id

That's how we setup a relation between two messages

That's the only way to my knowledge

lovetox: yes i know and it's a classical technique for XML (i wrote some XSLT 1.0 for my own thesaurus, LIS style), but i was wondering if that was the only way xmpp established relations between messages, or if the order of arrival in the stream mattered, or some other technique was used too.

i mean between any stanza

> That's the only way to my knowledge ah didn't notice your last message before sending, thanks ↺

Order is important of course in a lot of cases

But if one message references another it will be explicit with an id

ah so the ordering brought by TCP matters too, there's an implicit logical relation between stanzas based on that (ie after/before) ✏

i think location sharing should be forward-secret

Because if order wasn't guaranteed i could have imagined that this could have been dealt with with pending operations, like "this message refers to an id i do not know, i'll keep it around until i get what it refers to, or drop it after X seconds". Which of course makes things more complicated.

For example if you send multiple corrections, all reference the original message but you must know which is the last

And this comes through the order of the stream

So many things depend on order

Évelyne: but what you say can still happen, because once you get into requesting messages from an archive you may reverse the order you want to receive messages from the archive, and then you hit this situation

lovetox, You can of course set the PEP node to be only available to a specific roster group, and then put (say) family and close firiends into that roster group.

dwd: of course, I can also whitelist single jids and make the node open

lovetox, That too, indeed.

> Sharing location to multiple contacts not in a group? yes, this is a use case that i currently use with friends on snapchat / apple find my ↺

But via pep nothing is speced and it's complex. Sending location messages to my contact I can do immeadiatly

> Sharing location to multiple contacts not in a group? You could make a MUC and send your location in it ↺

whatsapp has that flow

It'd probably not be something you want stored in mam or so except for the last element, and the recieving client would want to subscribe to real time updates if the user is looking at that and only in that case probably

though for my use case it probably makes more sense to use something presence based

encryption over presence when 🧌

sunglocto, You're then just replicating PEP but in a different mechanism, surely?

jjj333_p (any pronouns): there are 2 different use case for me. One is sharing a location for x hours. The other is sharing without timelimit

For no timelimit I would use Google find device or apple find phone

> jjj333_p (any pronouns): there are 2 different use case for me. One is sharing a location for x hours. The other is sharing without timelimit i agree theres 2 use cases, thats not the line i would split it on though ↺

why not just have the users query you for location

> For no timelimit I would use Google find device or apple find phone that doesnt work so well without a) sharing your phone number b) if you dont all have the same kind of phone ↺

for me and my friends i usually end up location sharing on snapchat as i said

> why not just have the users query you for location less realtime, hence why you might want it to be something subscribable ↺

sure

But yeah for sharing without timelimit I would not use direct messages

subscription makes sense

IMO presence with some kind of last state serverside storage would probably be the best solution for what im wanting

And filling up mam is a good argument against it

like even if you go online, for the other user to be able to come online and get the data that came with last online

maybe that is pep, im not super solid on the details of pep

or how about presence with forward-secrecy encrypted location

like MLS

Ah mom we can send messages with a hint that it's not stored in mam

or OMEMO

> or how about presence with forward-secrecy encrypted location Nobody is going to implement that ↺

> Ah mom we can send messages with a hint that it's not stored in mam still a mess for clients that dont support probably ↺

sunglocto: people said that about OMEMO

> or how about presence with forward-secrecy encrypted location that doesnt help the offline issue, nor is forward-secrecy a good option for where you might have a lot of dropped data ↺

tbh pep or some kinda pubsub makes the most sense if you can set it to only store the last event or something

you're trusting the servers don't log your locations

anyway

> you're trusting the servers don't log your locations thats what the encryption is for ↺

or completely disregard your hint

> MattJ: maybe we should make encrypted PEP we've come full circle ↺

jjj333_p (any pronouns): but if someone manages to get the symmetric key (from a user you trust), they can decrypt all of your location notifications

> jjj333_p (any pronouns): but if someone manages to get the symmetric key (from a user you trust), they can decrypt all of your location notifications im not arguing against pfs. im saying pfs doesnt make sense in presence ↺

if that ever comes to be then God has left us and we are all living in hell ✏

i see

jjj333_p, Is that because there's no MAM etc to avoid lost crypto-state updates?

yes

though actually now that i think about it, it could just rebuild the session

honestly you should store a bit of your previous events

Right, thanks. So we could still ratchet, but the ratcheting needs to occur only over messages?

> honestly you should store a bit of your previous events this unfortunately doesnt happen in presence ↺

tbh presence is not meant for transmission of sensitive data

wthout compromising a bit of security

> Right, thanks. So we could still ratchet, but the ratcheting needs to occur only over messages? no, its that with presence you would need to re-ratchet every time both of you were online at the same time and otherwise it wouldnt be fetchable or decryptable ↺

maybe PEP or pubsub?

re-ratchet all the time would make the double ratchet systemm useless

> we've come full circle yes, back full circle to encrypted pep ↺

you might aswell go with a symmetric shared key

I know OMEMO explicitly ratchets on every message (or at least, I think I know!), but MLS for example doesn't, it's a distinct action. So we might be able to ratchet only over messages, where it's stable, but send presence without hanging epoch or whatever the terminology is.

>> we've come full circle > yes, back full circle to encrypted pep once again ↺

> if that ever comes to be then God has left us and we are all living in hell

> I know OMEMO explicitly ratchets on every message (or at least, I think I know!), but MLS for example doesn't, it's a distinct action. So we might be able to ratchet only over messages, where it's stable, but send presence without hanging epoch or whatever the terminology is. theres 0 utility in it being over messages ↺

Cynthia, It's all symmetric key, of course, at the bottom.

that is at no point what i was saying, that the negotiation needs to happen over messages

yes true

but i'm talking about using one key long-term

im saying that you loose state if you dont store the things you miss while offline

instead of a rotating key short-term

jjj333_p, I'm saying ratchet (so key negotiation) over only message, but send encrypted data within that state over presence/PEP.

> jjj333_p, I'm saying ratchet (so key negotiation) over only message, but send encrypted data within that state over presence/PEP. that just makes no sense to do ↺

jjj333_p, You'll have to explain why, I don't follow.

aside from being a gross overcomplication it serves no security benefit

i mean ig MLS would cut down on it, but theres little reason to include enough traffic in storage for the crypto data and not just also include the event

> aside from being a gross overcomplication it serves no security benefit also this ↺

either store the whole hog or dont store anything and just rebuild the session

so it's either store the whole log or don't use ratchet at all :P

Cynthia, Apparently so. I'm not sure if I'm just too stupid to understand this, or if this has fallen foul of von Clausevitz's perfect dream vs good plan.

tbh an omemo transmitted symetric key such as aes is probably fine for presence data, just rotate it every so often, via an asymetric means

that's what i was about to type

jjj333_p, How does that differ from what i suggested?

sunglocto, "The enemy of the good plan is the dream of the perfect"

> jjj333_p, How does that differ from what i suggested? the best i understood your proposal was to split omemo or mls so that the key negotiation happened via messages ↺

my proposal is use the omemo you use for dms to renegotiate a static aes key which you use to transmit the data

jjj333_p, Key negotiation does happen by messages in OMEMO, aside from the prekey/initket - that's identical in MLS and OMEMO.

i think you and me are talking past eachother in a major way, and its 3am i cba to figure it out

jjj333_p, The "ratchet" that changes the underlying symmetric key happens in messages, and in OMEMO that's every message, whereas in MLS it's only mandatory when the group changes.

I suppose in that sense MLS would work perhaps, but from what ive heard MLS in XMPP isnt happening very soon

and it still doesnt make presence right for location, since theres no storage of last state

jjj333_p, I am suggesting - very loosely - that we could export a symmetric key from MLS and use this for presence/PEP. I assume something similar would be possible in OMEMO, though it'd be very much bolted on.

how do you know there's no storage of last state

Why do you need to store last presence state to handle this though?

lol

> how do you know there's no storage of last state offline presecne can have a reason/message ↺

but you dont see it because you only get it if your client was online

from my understanding, the client generally doesnt keep track of offline presences, and thats the only presence that is persisting

Sure... But that's the current state anyway. We don't need this for cryptography, is what I mean.

why does this have to be over presence or PEP if you're just gonna share a key over a MUC or even PMs

to everyone

you're going to be sending a message to everyone regardless, why not stuff the location in directly while you're at it?

we're talking about https://xmpp.org/extensions/xep-0080.html ? or something like that?

> from my understanding, the client generally doesnt keep track of offline presences, and thats the only presence that is persisting Don't clients randomise the resource on every connect ↺

>> from my understanding, the client generally doesnt keep track of offline presences, and thats the only presence that is persisting > > Don't clients randomise the resource on every connect no. quite the opposite ↺

Or do they use the same one every time

> we're talking about https://xmpp.org/extensions/xep-0080.html ? or something like that? > yeh ↺

this is part of why resource is private protected data

sending something that is useless to everyone else over PEP/presence sounds like an overcomplication

> you're going to be sending a message to everyone regardless, why not stuff the location in directly while you're at it? because you dont want to clutter up storage or chat with the entire history ↺

only the last state

> sending something that is useless to everyone else over PEP/presence sounds like an overcomplication PEP has access controls. so you can make sure it only sends to the people it's useful to :) ↺

jjj333_p (any pronouns): youre going to be cluttering up the storage or chat with keys to decrypt th locations

> jjj333_p (any pronouns): youre going to be cluttering up the storage or chat with keys to decrypt th locations which is why omemo doesnt make sense ↺

perhaps something like MLS might make more sence since theres less key renegotiations

okay but you're still cluttering up the chat with keys

according to dwd it would only be on key changes

like adding/removing a device

that's internally, we're talking about sharing a key with everyone over MLS/OMEMO

and tbh, reusing keys directly from MLS/OMEMO would be a security nightmare on its own

what i think i figured out is dwd was saying that you could literally just use mls for that, like just another session

like i think we were just badly describing how mls works

also no server really stores the entire history

i'm assuming the location messages will be namespaced (so that client that can't handle it, ignore it)

so the server will prune out old messages

generally at least in the case of prosody i only see storage pruned in a time based mannor

yes

that's better, isn't it?

also in the case of realtime thats near constant events, you dont want to store that much

> that's better, isn't it? not at all ↺

worse both for ux and the work of both the server and client

you still need a way to tell everyone to advance their ratchets

PEP will only store one event (the most recent) if that's how you set it. Which I assume you would in this case

so you really can't avoid it

> PEP will only store one event (the most recent) if that's how you set it. Which I assume you would in this case yeah okay so just need to make mls or omemo work over that ↺

you can't

i feel like im discussing with a wall

you need a way to tell everyone to advance their ratchet, or a way to tell them which changes have occurred

otherwise the double ratchet system will break

> you need a way to tell everyone to advance their ratchet, or a way to tell them which changes have occurred do the rachet over messages, which in the case of mls would be way way way less frequent ↺

like if you have a lot of friends with a lot of clients that will only happen like a couple times a day at worst really, rather than literally anythhing approximating realtime being stored

sooo.. why not do the whole thing over messages then

unless your retention is like 1 hour that would quickly baloon insanely

> sooo.. why not do the whole thing over messages then mf i just explained that ↺

are you not reading my messages

i am

just confused

key negotiation happen once when client list changes

I guess the prior art is https://xmpp.org/extensions/xep-0477.html and https://xmpp.org/extensions/xep-0473.html maybe others. goffi is the one to talk to

location update happen potentially tens of times a minute

way way way different

ooh, so you're just talking about MLS exclusively

> perhaps something like MLS might make more sence since theres less key renegotiations literally said that ↺

> sooo.. why not do the whole thing over messages then sure you could easily. but PEP is also "over messages" and handles some stuff for you *shrug* ↺

i feel like im going cray

you said MLS/OMEMO

about a fw mssages back

sorry

not since i said the emssage i referenced

singpolyma: i'd like to see XEP-0477 be a thing

then we wouldn't need to argue over encryption for locations :P

> then we wouldn't need to argue over encryption for locations :P i mean that would just be solving the issue that we're debating ↺

... exactly?

i think i need to lie down, it feels like im speaking a different language than everyone else, and if its everyone than its probablyh me

it is 3am and im not sober

sorry

>> >> Don't clients randomise the resource on every connect > > no. quite the opposite So if i see `gajim.3728292rhde` it will stay like that on reconnect? ↺

yes

noted. in my client i've been randomising it on every reconnect...

once you use sasl2 you lose control of the resource string anyway. I'd suggest doing it that way for any new work

For some reason I don't remember I have a random part in go-sendxmpp… I think it was related to FAST or SASL2.

Bind2 rather than SASL2, but yes - you only control the first part.

I think it was because a stable ressource per installation would break parallel use of go-sendxmpp which can easily happen if you use it in several scripts for notifications.

you don't need to bind a resource at all to just send messages

Really? TIL

> After a client authenticates with a server, it MUST bind a specific resource to the stream so that the server can properly address the client —RFC 6120, §7.1

I guess "properly address the client isn't needed to just send messages then? ✏

> If, before completing the resource binding step, the client attempts to send an XML stanza to an entity other than the server itself or the client's account, the server MUST NOT process the stanza and MUST close the stream with a <not-authorized/> stream error

So, sure, it's not needed unless you want to send a message to anyone other than yourself

oops I think I confused sending presence with binding lol

I wanted to say that, but didn't.