jdev - 2021-12-01

Wow fun

Telegram is synchronising "in redaction" messages

Basically i started to type a message on my phone and saw it appearing on desktop. So basically they sync up a draft.

That's actually quite a nice UX.

I've had that situation multiple times, that I wanted to send a message from the PC enriched with a link from my phone, or to switch typing in the middle of things because typing on the PC is so much easier

I'm wondering how this could be replicated on XMPP 🤔

I can actually sync it in Movim easily between the different tabs :p

edhelas: write a XEP to send message drafts as a custom element in the <message> to your own JID, implement it together with XEP-0352 to prevent constant flooding on each typed letter

why not use a pep node and store draft messages there :p

with itemid = JID of the future receiver

Implement XEP-0301!

> I'm wondering how this could be replicated on XMPP 🤔 Maybe stuff from RTT could be reused. Afair Dino has something.

<message from="georg@yax.im/desktop" to="georg@yax.im"> <draft xmlns="urn:xmpp:message-draft" to="jdev@muc.xmpp.org"> I was thinking abo </draft> </message>

edhelas: the big challenge is how to E2EE your drafts

Multi-Device Support to sync input between different instances of Dino. With this, a user can start composing a message on one device and finish on another. (Details, see here) https://wolfieanmol.github.io/gsoc-blog/support-for-multiple-devices-muc/

Sending RTTs to the MUC might not be such a wise idea

Ge0rG, how e2ee your drafts? At first glance I don't see this particularly hard

pep., one issue could be that as you know a former draft is very likely to be a prefix of a latter one, it could weaken the encryption.

With OMEMO you're not sending to yourself (the same device) so that's fine. If you send to your own jid you might want to include in clear that it's a draft, or not even since you'd be able to know with the id that it comes from you..

hmm

The more the attacker knows about your plain text, the more your encryption could be vulnerable.

Although I’m not aware of any such issue in current algorithms.

If you append some salt to the draft before encryption, you can easily make sure it's not a strict prefix

Maybe even better to prepend some salt?

There is an rpad element in SCE already. If oldmemo is used maybe it can be specified where to put that pad (and that's where I bail out, don't know much about that)

Nice things only being available if you move forward might help push forward nice things?

The endless loop of going forward(tm)

Something something wheels and turning.

bitlbee code comment about caps in presence

it doesnt send the hash attr

/* The XEP wants this hashed, but nobody's doing that. */

i think they didnt really get what the xep was about

ok so i get it they didnt want to hash their disco info, because it was too much work

now they put in just the client version so ver=3.6.1

How old is that line?

but obviously this is not sha-1 hash

so they dont add the hash attr

Very very very old things don't

would it still be an improvement if we add hash=sha-1?

if they only change disco features between released versions, this would still work

no it would not for gajim, as it hashes the disco info itself and would report it if it does not is the same

... so i still get a warning in logs

https://xmpp.org/extensions/xep-0115.html#legacy

Huh, this was only done in 2007?

And then we have https://xmpp.org/extensions/xep-0390.html