XSF Discussion - 2024-03-29

Is there a client that supports "automatic message deletion" that can be set on individual chats and not only a global setting? Thanks

You're looking for https://xmpp.org/extensions/xep-0466.html and it seems no client implements it

I guess it was more of a question like, conversations can be set up to delete all messages after x. And if there is a client that can do the same per chat. No need for a xep for that. Just local...

Afaik there is no client that implemented message deletion on both devices/servers for older messages.

and no client implements ephemeral messages yet sadly

I mean only client, but that one does not have one setting (f.eks, never, one day or one week) for all chats. But one chat can be never, another one day, another one week for example

> This would only make some-what sense if you've also disabled archiving of messages Or your server's retention time is less than your client's retention time

This would only make some-what sense if you've also disabled archiving of messages. If not your client will at some point fetch those (locally) deleted messages from the server. But yeah you're right there is no option to set (local) message deletion on a per chat basis. ✏

Ok👍

E.g. Snikket servers default to 7 days, so if you want to clear after 7+ days locally, the message is gone from everywhere after 7 days

It also makes sense if you have a phone that gets slower and slower to the point of becoming unusable if you don't have messages set to delete after one week 🥲

moparisthebest, Does this happen to you?

> E.g. Snikket servers default to 7 days, so if you want to clear after 7+ days locally, the message is gone from everywhere after 7 days Ok I see😊 ↺

I can't imagine it slowing down that much even with a huge db of messages

gooya: yup!

The problem with ephemeral messages is an open ecosystem is that if you don't implement it everywhere, it doesn't do what it advertises

This was also the problem for message moderation and a ton of other potential great features.

MattJ: yeah I see that argument. Different server setups would be a problem. But would it not be as easy as to make everything in the client? So if set to delete after 7 days, there would be no fetching of new messages of that chat after 7 days either?

Yes, clients could do that

Ok, and then I dont see the problem making this work for individual chats as well. Cant the fetching also be on an induvidual chat basis making what I ask for possible?

Another unrelated question I've been thinking about, Would something like message pinning in 1:1 and MUC's need a XEP, and if so only client client-side or also server-side? (as in pinning a message for everyone in the conversation whether that is a muc or 1:1 chat) ✏

MSavoritias fae.ve: conversations IM/Cheogram implements this

Do you want to pin many messages or just one? Because for one we have dhad arlaedy some places call it "topic"

singpolyma, More than one but not many

Kind of how telegram handles pinning and displaying of pinned messages. Something like that would be pretty neat

> MSavoritias fae.ve: conversations IM/Cheogram implements this ephemeral messages you mean? it doesnt afaik

> Do you want to pin many messages or just one? Because for one we have dhad arlaedy some places call it "topic" it doesnt work in any client like that tho. gajim and cheogram and dino for example dont show topic there. plus you dont pin messages you have to copy paste the message

never mind that the topic/subject is used to post the description of the room as it is now. not pinned messages

Topic is not a description of the room

Gajim Shows the topic on join and in the room info

Right. We have a seperate field for description

so topic is the subject then? either way same thing

no client shows it. and its even less useful

I'm not sure what you mean no client shows it? Is there any client that does not?

Id like to make Cheogram Android do more like gajim and also show it as a card on join. If I can decide when "join" is

iirc Conversations only shows one, Dino only shows the other, and sjn shows both

if you open telegram the pinned messages is *always* shown there everytime. the only way to remove it is for the person to manually interact with it. and when it changes it appears again

so gajim and cheogram and the rest do nothing like it at this point

its more of a "welcome message" to show the rules of the room

which is supposed to be that

moparisthebest: you're saying dino doesn't show topic?

I just remember having to edit different fields in both to get sjn to display something sensible, I'll look later

> if you open telegram the pinned messages is *always* shown there everytime. > the only way to remove it is for the person to manually interact with it. and when it changes it appears again And if you have more than one they all show? That seems like it would take up a lot of screen space on mobile, but I could try it ↺

moparisthebest: oh yes. Sjn doesn't show topic of course it shows description

you cant have more than one afaik but i can see again

in telegram its basically a "third field"

where you can attach messages you want or have a poll to appear on anybody

So telegram has description, topic, *and* a single pinned message?

what about title? name? gotta have those too! :)

Didn't MIX solve this by removing subject and having arbitrary pinned messages as a separate feed?

it fills the usecase of: something was said or we need to do something as a room (poll, anouncement, whatever) and we want to make sure people dont miss it

and without having to scroll on the backlog or whatever

> Didn't MIX solve this by removing subject and having arbitrary pinned messages as a separate feed? ah another reason i guess to go with MIX :P

But its always just one and they do have bith topic and description seperatly?

Having more than a single topic was a mistake 🤣

We only have one but we're discussing adding either one more or n more

https://share.loqi.im/upload/e6ae9a3c-e850-43eb-9409-a8dbbb793ef3/8226ff38-65d6-4f82-a170-2fa5ca31f646.png

Multiple message pinning in telegram ^

So the banner tells you there is more than one but it only shows one or part of one

Can you dismiss it?

seeing here it has title and description and pinned messages are seperate https://telegram.org/tour/groups

and it allows multiple messages to be pinned https://core.telegram.org/api/pin

Right so as I suspected this is what they use for topic, they don't have topic as a seperate thing

singpolyma, I don't think you can dismiss it, which imo should be possible. And if I remember correctly you could swipe the banner to get a preview of the next pinned message.

Doesn't Slack have both topic and pinned messages, or?

Zash: yes. Slack does

here is where they did the update https://telegram.org/blog/pinned-messages-locations-playlists/world#multiple-pinned-messages

> Right so as I suspected this is what they use for topic, they don't have topic as a seperate thing i mean if we can make the topic more interactable theoretically you dont have to show the rules to people again besides the first time

or you can have it as yet another of pinned messages

I expect the main difference between our topic and their pins is media

I mean from a protocol pov

Our topic is _only_ <subject> yeah.

agreed. they can attach pretty much anything and its interactive

Personally, I have a interest in having the ability to pin messages in conversations (especially MUCs) but I don't know how much of an interest there is in this feature in general in the instant messaging/xmpp ecosystem

i would like to implement it for sure

i didnt remember that you cant remove them tho

Doesn't matter how much interest, if you are interested, do it

Do they need to outlive message retention?

Yes

Or no?

Hmm

I assume that with Slack and such, you just have long enough retention that it wouldn't matter

I think so

I don't think they do in slack

For private (read: OMEMO) chats it's ... werid

Right. Generally infinite retention is the thing g anyway ✏

i dont think for private chats pinned messages make much sense anyway

If you want jump to context then you need the id anyway

telegram has the nice thing that depending on the the group it has different capabilities

But yeah if you have expiring history who knows

Something about perfect being the enemy of good

MSavoritias fae.ve, What about private groups that have omemo enabled

Maybe that's jumping ahead to protocol design (but when in xsf@ ...) but it influences whether you'd need some separate channel/storage or if a list of stanza-ids somewhere is fine

Protocol design is all that's interesting here yeah

> MSavoritias fae.ve, What about private groups that have omemo enabled idk. i dont plan to implement OMEMO either way. but probably it needs to be added to a "container" so that it cant be deleted and can be referenced

A list of stanza-ids should work for OMEMO too, as you need to have client-side storage anyway for the decrypted messages.

Yes

Can you even re-send an old message?

Time to implement muc-pep

> Can you even re-send an old message? you cant?

Server could be aware of pinned messages and not remove from mam

So considering all the factors mentioned above, does it make sense to have a XEP for pinned messages?

i mean if a person wants to scroll or is clicing on a reply or something shouldnt they request the messages again

As a special case in their expiry

singpolyma, complicated!

maybe as a security consideration too

because the message can contain a lot of things

gooya: need someone to prototype muc pep first ✏

what do we need muc pep for?

singpolyma, `prosodyctl shell module load pep muc.xmpp.org` ??? PROFIT!

Zash: does that actually work? I havent tried it

> maybe as a security consideration too > because the message can contain a lot of things Possibly only allow message message pinning by certain roles

MSavoritias fae.ve: for storing the pins

ah.

wait isnt that basically MIX?

No

It's just normal pep

okay

Where the jid happens to be a muc

cram a comma seperated list of message IDs in some muc config field, done

moparisthebest: no

> > maybe as a security consideration too > > because the message can contain a lot of things > Possibly only allow message message pinning by certain roles yeah for sure

MUC config fields are for humans

And also comma seperated fields are always wrong in xmpp

singpolyma, IIRC it mosly needs a different affiliation integration, i.e. some code that looks at room affiliations instead of rosters (which don't exist)

Zash: right. So if I load it now probably it'll crash loiking for roster?

Standardize a flag on muc config fields that says "not for humans" while you are at it

moparisthebest: well, I guess we have type=hidden

You can make it \0 separated if you want 🤣

Oh, let's get back to my peev about XEP-0004 not having an array type! :D

It does?

NOT

Um. What is list-multi?

Select from a list of options?

Not quite array of arbitrary strings

So use <open/>

Is that what <open/> means?

It means you can add any options you want yes

> The <open/> validation method applies to "text-multi" differently; it hints that each value for a "text-multi" field shall be validated separately. This effectively turns "text-multi" fields into an open-ended "list-multi", with no options and all values automatically selected. Hmm or that?

Yes

And define a stanza-id datatype

This is what I proposed for multi language the other day also

> i dont think for private chats pinned messages make much sense anyway Yes, they do! Small communities pinning for example pictures of their latest "everybody should have that on quick-access". Could be schedules of their team in sports, song lyrics for a music band chat, you name it ↺

or funny moments. especially funny moments

if there is Yunohost users/admins in the room https://forum.yunohost.org/t/prosody-xmpp-server-for-yunohost-12/29128 🙂

Very nice

Slightly better attacks against sha2 https://eprint.iacr.org/2024/349

We haven't even migrated from sha1 yet 😛

moparisthebest: do you have a favourite next? Sha3? Blake? Other?

I don't

Is this attack against sha2 generally or sha256 specifically?

both

in practice does jingle file transfer ever have more than one <content>

like would C or Dino work if they were sent such

as i understood it its far away from an attack

lovetox: it's an improvement on a past attack, and schneiers law says attacks only improve :)

Go forth implement caps2 and whatever supports hash agility!