Users should be able to change password for their accounts. This is part of XEP-0077 and support on a majority of servers.

https://xmpp.org/extensions/xep-0077.html#registrar-formtypes-changepassword

All other people that are currently in a room should see a notification when someone is added as admin. This should be visible in the conversation view, but also be updated in the roster. The message might look something like this: "user1 gave admin status to user2", or something like that. If a reason is given, that should also be displayed.

Note: Please see the reference on https://xmpp.org/extensions/xep-0045.html

Whonix 15 going to be released soon based on Debian Buster. Im testing CoyIM and i discovered its not connecting either its freeze up on registration or shutdown itself.

steps to reproduce very easy just try to make it work/connect normally and it just wont continue. Terminal log:

user@host:~$ coyim 

(CoyIM:3353): dbind-WARNING **: 17:17:40.507: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x8c6487]

goroutine 9 [running]:
github.com/twstrike/coyim/gui.requestAndRenderRegistrationForm(0xc000026640, 0x19, 0xc00006a0c0, 0xd77bb0, 0xde9460, 0xc0000948a0, 0x0, 0x0)
	github.com/twstrike/coyim/gui/registration.go:83 +0x1a7
github.com/twstrike/coyim/gui.(*gtkUI).showServerSelectionWindow.func1.2(0xc000068180, 0xc00006a0c0, 0xc000182750, 0xdf9540, 0xc00001f5b0, 0xc0001aa0c0)
	github.com/twstrike/coyim/gui/account.go:170 +0x7f
created by github.com/twstrike/coyim/gui.(*gtkUI).showServerSelectionWindow.func1
	github.com/twstrike/coyim/gui/account.go:169 +0x6c6
user@host:~$ 

Screenshot where it freeze:

In a discussion @brl proposed that OTR should be mandatory in CoyIM - we shouldn't even have the option to turn it off. Thinking about it, I like it more and more. Thoughts/comments/discussion here, please!

Including possibility of manually trusting a cert. These are the specific pieces of functionality I think we need:

• [x] Trusting the certificate temporarily
• [x] Setting for manual approval of everything
• [x] Show connection info per account, right click or something
• [x] Look at parents of certs
• [x] Save more than one valid cert
• [x] Pin certs
• [x] Recognize the google situation
• [x] Edit list of saved certs
• [x] Certs are saved per account

As a user, when I get prompted to import user data and I see my accounts listed which I want to import and I click on adding these accounts, nothing happens.

I was expecting that these accounts would be imported as I clearly added them explicitly.

This happens on Coy 0.3.1. I run: Ubuntu 14.04.4 LTS \n \l ii pidgin 1:2.10.9-0ubuntu3.2 amd64 graphical multi-protocol instant messaging client for X

This functionality allows an owner to destroy a room they are in. The destruction can take an optional reason, an optional alternative room, and an optional password for this alternative room.

After the destruction, the room view should display in the same way as described as in #657 - except there should be an option for the owner to have the room view window be closed directly after the destruction.

If the destruction fails, a notification should be shown to the owner - probably not in the conversation view, but somewhere else.

(should we have a different functionality for destroying a room you're not currently in? Is that even possible?)

Note: Please see the reference on https://xmpp.org/extensions/xep-0045.html

When a person has their role changed to being a moderator, a notification should be displayed to any other user in the conversation view. This should include who changed the status, what the new status is, and the optional reason.

Note: Please see the reference on https://xmpp.org/extensions/xep-0045.html

Hello,so i add all my 3 XMPP Accounts,i close and then open CoyIM and only 1 is left when i reopen it.The really weird thing is that in my accounts.json all my accounts are there,and if i try to readd it i get that this account is already added but i cant see/connect to it.

Any tips?

Thank you!

An administrator or owner can add administrator privileges to a person, changing their affiliation to "administrator". For now, for ease of development, we should give access to this functionality from the user panel in the roster. We should also consider how to do it for a user who is not actively in a room. For now, this could be a standalone dialog.

When adding administrator privileges. you should be able to provide an optional reason for it.

Note: Please see the reference on https://xmpp.org/extensions/xep-0045.html

A room can have a lot of configuration options to set. Exactly what these are depends on the server and how it's configured - you will basically get a form to fill in. However, most other clients will show the form directly. This isn't necessarily great for usability, so for this story I think we should break up the different configuration options into different areas, or tabs, or something else that helps the user. We should show the most important or most common options first, and then the more advanced or weird ones. We also need to provide some kind of explanations and help for these.

This story also needs to include validations of all the options and helpful feedback if you don't give the right values.

Basically, this story extends the simple creation of a room, allowing you to add configuration options. We should probably not add a new menu option to access this, but instead allow you to add configuration options from the basic room creation dialog.

Note: Please see the reference on https://xmpp.org/extensions/xep-0045.html

For now, we can't publish a Cask in the main Homebrew repository. This is partly because of #853. So in the meantime, we should consider creating our own Tap, as outlined in https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap

For more information about Homebrew, see #178 and #241

It seems like signing DMG's is a requirement for Homebrew these days, and it might also be necessary for ARM Mac's - which we also need to build for. For more information about the Homebrew side, #178 can be referenced. For the thoughts on signing, #703 and #241 are useful.

Can you add the support of RFC 9266: Channel Bindings for TLS 1.3?

• https://datatracker.ietf.org/doc/html/rfc9266

Little details, to know easily:

• tls-unique for TLS =< 1.2
• tls-exporter for TLS = 1.3

Thanks in advance.

Linked to:

• https://github.com/coyim/coyim/issues/536
• https://github.com/coyim/coyim/commit/872cc35d7f7ed80c143fb931915e6415512dc9a1
• https://github.com/coyim/coyim/commit/a91ae187324ecf7f4e2d6ed16337484c45eab57d
• https://github.com/coyim/coyim/pull/845

RFC 9266 will change the default channel binding type for TLS 1.3 (previously no channel bindings were defined and -PLUS SCRAM mechanisms were not available over TLS 1.3). This patch sets the new tls-exporter channel binding if the TLS version is >= 1.3 and uses the old tls-unique binding otherwise.

Here is the full list of uncompleted questions in this comparison, which currently does not include CoyIM. I was able to fill out some of them already. It would be great to hear from you guys and get some answers.

About the app Price: free Repository: GitHub Software license: GPLv3 Availability: GitHub Client is available since: 2015? Comes without proprietary libraries:

Platforms Available on Android: No Available on iOS: No Available on Windows: Yes Available on macOS: Yes Available on Linux: Yes Available via web client: No

Privacy / Security / Anonymity Encryption protocol / library: OTR 3 Cryptographic primitives: End-to-end encryption: Yes End-to-end encrypted 2-user chat: Yes End-to-end encrypted group chat: E2EE is turned on by default: Local message encryption: Perfect forward secrecy is enforced: Certificate pinning is used: Directory service can be modified to enable a MITM attack: Contact verification possible: Contact can be added without needing to trust a directory server: Notification if contact's fingerprint changes: Contact's fingerprints can be verified manually: Yes Avoids / Protects metadata during use: Yes via onion routing Native Tor support: Yes (if installed) Last security audit: - Tracker integration (Exodus): No mobile app Use without phone number possible: Yes Use without Google Play Services possible: No mobile app Reasonably useful without sharing the contact list: Yes

Ecosystem and developers Centralized / Federated / Decentralized: Federated Infrastructure hosting: Distributed server Open Source server: Transparency / Financing (Including donations): Transparency report: Legal jurisdiction: Jurisdiction of the devs/company: Funding:

Functionality Visible if contacts are online: Audio-/Video-chats: Group chats: Voice messages: File exchange: Yes Read receipts: Editing sent messages: Self-destructing messages: Deleting sent messages locally: Deleting sent messages for both (2 user chat): Synchronization between multiple devices:

Backup Storage location: Automated: Encrypted:

We have a large amount of places - especially in interactions with other parts of Coy - where the GUI uses the interface{} type and then casts it in different ways. Sometimes, we also use more specific types, but then do type-switches anyway. We should try to rely more on the compiler to help us give advice when we're doing things that are problematic by reducing use of type switches.

There are two big areas where we should be extra careful with this. The first one is with all the MUC message code. Here, we wanted to separate the implementation of the data-types from the session/muc/data package from the representation of messages and other actions. For this reason, type-switches are used a lot - and in some cases just regular switches but based on pseudo-types, such as IsOwner, etc. We should move to using the Visitor pattern for most of these places.

The other place is where we are interacting with different parts of GTK that is untyped. For example, in the ListModel storage, and also using GLib properties. In this places, we should implement wrapping structures or methods, and reduce the place that calls the untyped functionality as much as possible.