Gajim - 2025-08-06

https://search.jabber.network/channels/2

i understand these are some of the public channels available. i am new to gajim and durare.org, so are there any safety issues in accessing these public channels?

is it like - you just join them like you join a google or yahoo group? Avoid clicking on suspicious links, is that all the precaution required?

Is there a separate list of public channels whitelisted by durare.org?

You can access global search in Gajim itself, click on the globe symbol in the start new chat dialog

okay

There is no curated list of chats

Nobody can say what people will send to you in these chats

You need to take the same precautions as when surfing the web on a browser

okay

kris: your JID will always be exposed to moderators, if the channel has the Non-pseudonymous flag your JID will be visible to all occupants

is that a good thing or a a bad things? :-)

it's like sharing your email address, your choice

okay

got it

> I am not finding it in the xep, so I am hesitant Christof, section 5.3 of XEP-0085 says: > Even if the user types continuously for a long time (e.g., while composing a lengthy reply), the client MUST NOT send more than one standalone <composing/> notification in a row. ... but clients are unlikely to explode over receiving two of the same chat states in a row

but doesn't that mean that the xep is violated by clients that apply a timeout to composing-notifications?

Not explicitly, but they shouldn't assume that composition has stopped unless and until they receive notice of that

Very questionable the MUST NOT there

Like it would break something..

It's hard to imagine a situation where it is a problem to send twice composing

This is just speculation, but permitting it might lead to normalizing it, which may lead to some clients expecting a periodic "hey the user is still typing btw" notification, which then would make it a de facto requirement to constantly be sending such notifications (how often? Well, the only way to be compatible with *all* clients is to send them as often as the most impatient client expects, so...)

We implemented the timeout for clients which went offline while typing etc., because then it would not reset to active

Goot the ticklegoblin!: in a XEP standard in my opinion MUST NOT should only be used if it breaks interoperability, I don't see this here.

Goot the ticklegoblin!: you think too much about this, no client can break if you send composing twice

> We implemented the timeout for clients which went offline while typing etc., because then it would not reset to active Is it based on time or detection of factors such as this? Sometimes people either have long messages to send or just take a long time to type, and there is otherwise no way to distinguish "still typing after X seconds" from "hasn't told us that they have stopped typing after X seconds"

Hi I’m very new to the xmpp wonderful world. Is there a possibility to call people on the phone who don’t use xmpp? It seems that only possible to receive the audio call… Thanks a lot!

fede: https://blog.jmp.chat/b/adventures-in-webrtc-making-phone-calls-from-xmpp-znLOT5

Goot the ticklegoblin!, i just checked, remote paused timeout is 30 seconds

if we dont receive something for 30 seconds we unset the compose state

of course there are other conditions also when we reset the chatstate, for example if we receive a going offline presence

but i guess you dont care about that

so not sure where you got the 10 seconds you mentioned at the start of the discussion

30 seconds should be plenty or?

Goot the ticklegoblin!, usually there is a way to discover that, if a user stops typing for a prolonged time, for example they think about something, the client can send the PAUSED state

we do that for example if you stop typing for 10 seconds

but there is still something in the message input

but yeah if a user in another client continously types for more than 30 seconds, yes the chat state will not be accurate anymore

but we thought in a IM use case which we have here, it should be an exception that a user types for half a minute

but obviously 30 seconds is not based on any real observations, if users would complain i would raise it to 1 minute

or even higher

but somewhere needs to be a limit, because not all clients are perfect and some just forget to send ACTIVE or miss some state, in these cases we dont want to give the user the impression a message will arrive soon

> so not sure where you got the 10 seconds you mentioned at the start of the discussion Goot never said 10 seconds

My messages where then for Christof

> but we thought in a IM use case which we have here, it should be an exception that a user types for half a minute IM is an incredibly broad use case and covers things from casual chit chat to in-depth discussions about technical standards in which at least one participant is using a phone keyboard that they're not used to

> but somewhere needs to be a limit, because not all clients are perfect and some just forget to send ACTIVE or miss some state, in these cases we dont want to give the user the impression a message will arrive soon Those clients would be out of spec then, and it shouldn't be on the receiving client to make up for the sending client's potential imperfection

>> but somewhere needs to be a limit, because not all clients are perfect and some just forget to send ACTIVE or miss some state, in these cases we dont want to give the user the impression a message will arrive soon > Those clients would be out of spec then, and it shouldn't be on the receiving client to make up for the sending client's potential imperfection :D if you knew how many fixes for quirks there are

Generally, processing the receiving side should be relaxed while the sending side should be strict

Goot the ticklegoblin!, but the receiving side has the trouble, and it does not help users if the sending side is out of spec, and further no human is perfect, there will always be bugs, so why not plan ahead for them

The solution prepares for the potential unintentional non-compliance and breaks in all actual cases where a user's conversational partner is taking a long time to type something

yes i got that, but its a consideration, weighing different pros and cons, not sure what you are on about, is there an actual problem you have?

Just been following the conversation naturally, not trying to argue anything

lovetox pushed 1 commits to branch gajim/master fix: Profile: Don’t escape nickname - https://dev.gajim.org/gajim/gajim/-/commit/54a86ded20cbda887e56edeca0b5f072038807c7

> Goot the ticklegoblin! wouldn't have chosen to implement it that way but it is Gajim's perogative and decision to make for Gajim Personally, I had more cases where the composing state wasn't reset correctly. Regarding real-world use cases: typically, people writing long messages make a pause now and then. This is reflected by chatstate "paused". As soon as the user is typing again, a new "composing" chatstate is sent. This means typically, there is a flow of composing and paused updates, resetting any timeout.

> Personally, I had more cases where the composing state wasn't reset correctly. That was before the timeout handling was added to Gajim

the beauty of the solution is that users notice very fast that a composing or paused state hangs, and rightfully complain. But they cannot complain when the composing state is gone after 30 seconds, because they cannot know if the other person really stopped composing, apart that nobody sits befor the screen and watches a minute long the chatstate label

does gajim support XEP-0174 (link-local/serverless messaging)? i noticed it was removed but couldnt find info about whether it had come back or if there were such plans

no, and there are no plans to bring it back

lovetox pushed 1 commits to branch gajim/master new: GroupchatRoster: Add total-count property - https://dev.gajim.org/gajim/gajim/-/commit/3821d3f2fccedb88fb78805065234b96f1e1e332

thank you for checking lovetox!

the use case here is a bot that is composing a message and it could be slow.

I'll probably have it resend. The 10s are from observation. (give it a 10 count and then the chatstate disappears)

it does so in profanity as well