XSF Discussion - 2023-11-26

mdosch: automatic encrypted backups on some cloud space wouldn't be bad in this case. Element or Threema offer this functionality for instance.

How do they encrypt? Symmetric with account password as key? That's not PFS anymore, so we could just use Ox instead which doesn't have the complicated PFS theater and doesn't need PFS breaking workarounds. :)

the benefit is that its opt-in, so you get the benefits of both for people that want them

(this from a person that also plans to do a backup thing like that)

mdosch: looks like Matrix keeps an (with a recovery passphrase) encrypted backup of your secret keys on the server (p2 2nd column) https://nebuchadnezzar-megolm.github.io/static/paper.pdf > This allows a user's new device to gain access to old messages the user has access to I don't know if they have any other backup mechanism. ✏

the problem is they also use dark patterns to do it. at least element

Signal does the same, how can XMPP be taken seriously until it does dark patterns like the rest :troll:

It's too bad that XEP-0191 is not a simple PEP node, maybe could be an evolution ?

Then clients can be aware of other clients changing the list, with a simple +notify

Blocking has notification

A yes indeed, oversaw it, my bad.

But does it have BIND2 integration yet? :) ✏

Does it need one? There isn't exactly a race condition with blocking command

Might save a few bytes traffic

why would i need the blocking list immediately after connecting to a server?

server handles blocking, the client requests it only in the case the user wants to see or modify it

UI things mostly, also in Movim the admin is aware of the blocked JID of all its users, then he can make decisions based on it

my reply was to Zash's response, and "UI things mostly" are not convincing for integrating it into the connection process to a server

> UI things mostly, also in Movim the admin is aware of the blocked JID of all its users, then he can make decisions based on it Yes. Conversations for example closes the corresponding chats when another client blocks a jid. This for example gets rid of spam chats

What Daniel says.

Maybe you don't need the list itself, but the subscription to changes might be useful for such things.

lovetox, also, you might want to close tabs of conversations with people who were blocked in the meantime

or un-notify for them

And if you really don't want it, don't ask for it in bind2, if it becomes an option to ask for it there

i never questioned why someone needs the list

i said "immediately"

but i see, so bind2 will be somekind of pool of things i want from the server, and to save IQs i add a list of things he should send me

question for me is then, does it delay the connection process?

is bind2 complete only if i receive a blocking list?

so the more data i request the slower the connection process becomes?

seems contrary to what bind2 wanted to achieve

bind2 lets you ask for a session with a particular state. "wants roster updates" and "wants blocklist updates" is part of that state. seems natural to me to allow for such things to be covered. with or without requesting the corresponding data.

roster and blocklist are hit often enough that they're generally cached in memory all the time, so I doubt it would be slower to include them, over spending some network roundtrip asking for them later

im really confused, neiter roster updates nor blockist updates are optional to my knowledge

why would i need to add something to bind2 to tell the server "i want them"

roster updates are optional; if you don't ask for the roster, you don't get updates.

blocklist updates are also optional; if you don't ask for the blocklist, you don't get updates.

ok, i dont find it in blocking XEP, can someone point to the paragraph where it says that?

lovetox, > The server MUST also send an IQ-set to all of the user's resources that have requested the blocklist, containing the blocked item(s):

i never read that as MUST NOT send IQ to resources that did not request a blocking list

but i guess i learned today how that was interpreted by server implementations

that's not written there, indeed, but it also doesn't say that everyone who requests the blocklist should get a unicorn, which is why we still don't have unicorns.

in that case, it would make sense to add at least this notificaiton mechanism to bind2

> that's not written there, indeed, but it also doesn't say that everyone who requests the blocklist should get a unicorn, which is why we still don't have unicorns. How can XMPP ever be taken seriously without unicorns ↺

Huh, with XEP-0016 you sent pushes to all resources allways?

but then again, i need to request the list anyway, so adding this would actually increase the traffic

what i thought you suggested was, that in the bind return, it includes the whole blocking list

and this would be very different thing then, going from little flags that enable this and that on the server to and also send me this 200 blocked contacts

Since there's no roster versioning equvialent in xep-0191, sending the whole blocklist in the bind result is probably how it would have to look like.

.. yeah it would have been easy to version this .. not like we had no idea this is useful, after using roster versioning forever