Ticket #142 (new enhancement)

Opened 5 years ago

Last modified 5 years ago

Private chats should not open automagically

Reported by: melo Owned by:
Priority: normal Milestone: 1.1
Component: Multi-User Chat Version: version 0.8
Keywords: Cc:

Description

Inside a chat room, we can chat one-to-one with a participant, even if the participant JID is unknown.

The MUC acts as a intermediary.

The problem is that the private chat window pop's up without any request for confirmation, so it is a source of spam.

When a private message arrives we should display a pop window explaining "User X at Chat-room Y (real JID if known)" want to talk to you privately".

The following options should be available:

  • accept, the default: we accept this private chat;
  • refuse: we refuse the private chat, and send back a message saying so.
  • block: we block the user from opening private chats. No message is sent to the other user. Further attempts from the same user (see below) will not even display the pop up;
  • always accept: we accept this private chat, and future private chats from the same user (see below) will be accepted.

All decisions that require long term storage (block and always accept for now) should use local storage in the initial version. Future versions might push this to the network.

For those two options to work (block and accept always), we need to identify the user. There are two situations:

  • the chat-room is public and we have the real JID of the client: in this case the ban or acceptance uses this JID;
  • we don't know the real JID of the client: in this case we should use the JID the user is using in the chatroom.

In the second case, there are some extra rules. Given that this JID is temporary, the accept forever or block action is only temporary also.

If any of these things happens, we need to react:

  • if we leave the room, all temporary blocks/accepts should be cleared;
  • if one of our blocked/accepted always users leaves the room, we should clear the entry;
  • if one of our blocked/accepted always users changes the nick inside the room, we should update the entry to use the new JID.

There is already a "Gag list" in the chat room participants context menu. The gagged users should be part of the block list, but not the other way around: if we gag a user, he cannot open a private chat session with us, but if we block a private session with a contact, we should not gag him.

Change History

  Changed 5 years ago by dbcm

It's fine for me. About the local storage, i think it's more easy to use the server storage, this is already done in other aspects.

  Changed 5 years ago by melo

I said to use local storage to save some development time... I mention a future version where we would push this to the network.

I prefer to wait for a future version because we should really use PEP for this, not private storage.

  Changed 5 years ago by dbcm

  • milestone changed from Future to 1.1

follow-up: ↓ 5   Changed 5 years ago by dbcm

Pavão, you choose. What is harder, local storage or private:storage? If both have the same work, use private:storage since it's better for more than one desktop. Moving from private:storage or local storage to PEP should have the same work, i think...

in reply to: ↑ 4   Changed 5 years ago by jppavao

Replying to dbcm:

Pavão, you choose. What is harder, local storage or private:storage? If both have the same work, use private:storage since it's better for more than one desktop. Moving from private:storage or local storage to PEP should have the same work, i think...

Implementing it using private storage on the server would be a little more time consuming than using local storage, but just a little. It all depends on the state of affairs at the time this is implemented: if we're tight on time, and if the feature is expected to be upgraded to use PEP soon, then I think we could simply use local storage. Otherwise, we can go for private storage on the server.

  Changed 5 years ago by spike411

I think it should behave just like normal chat (outside of MUC). For me, it means to show Growl notification about new message…

If you want to block certain room nicks because they are spamming really hard, you could/should use Privacy Lists, instead of inventing some private XML storage protocol. Of course, this is not real solution in (semi)anonymous rooms – the solution would be to (ask a moderator to) ban the spammer. In non-(semi)anonymous, you can block real JID using Privacy Lists, but still, the sucker should be banned by moderator.

  Changed 5 years ago by spike411

I did not realize that normal chats are also opened by default (even in Do not disturb mode), which is constantly driving me crazy, because I have to first focus this chat window and then switch back to my movie. (Mac window management is “strange”. I'm also constantly searching for various applications' modal windows which don't show up in Dock or clicks on their Dock icons are ignored and don't put this window in front… D'oh)

Note: See TracTickets for help on using tickets.