Hi!

Message
I would like an option to send / receive a short message to /from peer or seeder. In Peers menu will be added an attribute Msg before Address. It will be very short like an attribute Flag. There should be a different icons and colors for no message, sent message (if we sent message) and received message. If we click on icon a frame will open where we can read an post the message. Like a chat. This chat will be stored as long peer is connected. When torrent is removed messages are removed too.

Sometimes we need some communication between peers like: Hey a am only 100% seeder and I would like to go away. Please open your speed for this torrent so you could download complete movie. I will redirect all upload to you. So torrent will stay alive.


Token
There is another option for torrent to stay alive. It's call Token and menu attribute T. There will be a give token and receive token.

Give token: In case when are just three seeders or less, seeder get possibility to give a token. Token icon is normally dark grey. When possibility for give token is open, icon became green with letter S or G (means seed or give). Once seeder clicked icon, icon became blue. If any of peers accept token, icon became red.

Receive token: Normally icon is normally dark grey. There is a letter R (receive). When one seeder click a S icon, icon on peer side became green. If peer click on icon, icon became red, that means peer accepted a deal. If peer want to offer a deal, he/she can click on dark grey icon and R icon became yellow. At same time S icon by the seeder side became also yellow, that mean peer offered a deal.

Once deal is closed software (Tixati) will redirect all traffic to this specific torrent between those two who cut the deal. This connection is given UH priority. You can have token only in one torrent at the time. Once you made the deal, you can not terminate or stop the deal especially you are the seeder. Token is real business. Until seeder complete a deal, software will not allow to start another torrent or stop this torrent until specific peer who cut the deal has 100%. When peer reach 100% deal is complete. Seeder is of the hook. Now is on peer side who became a seeder to complete his wow, that means he will seed until at least one of peers complete 100% and he send at least amount of data he received. Deal is terminated if there are no peers at least 3 days. In case the connection on peer side is really slow seeder will be able to start another torrents, but this one still stay priority. In case of really slow connection for the time of 5 minutes seeder get option to offer another deal. In this case icon became orange and when seeder click icon icon stay orange with blue S. At the same time other peers who's connection has been tested as sufficient get an offer, their icon became green. If another peer with faster connection make a deal, previous peer is released.

I think these are good ideas and I appreciate the amount of thought you put into them but one major issue I see with this is compatibility. Other clients will have to implement these features for it to be more useful. If the developer decides to add this, these should be made into open standards(in this case BEP / BitTorrent Enhancement Proposals) to encourage other clients to adopt them. While helpful, an open standard does not require code to be made open source. It just has to be very well documented and explained. Example code is very helpful but not absolutely necessary. I would understand if the developer doesn't want to release any Tixati code even if it's just for these BEPs. I'm calling it a BEP because it should become standardized and not remain just as a feature exclusive to one client. I think a messaging BEP is somewhat important because the decentralized chats some torrent clients offer are all fragmented. For example, BiglyBT offers a DHT based chats/messages(similar to Tixati) but Tixati users can't talk to BiglyBT or other clients. This is going to take a lot of work, planning and testing. It would be nice to have and I don't like sounding pessimistic but I don't think it will happen unless enough people work on it. If someone else made the BEP and it reached accepted or draft status than the Tixati developer would be more likely to implement it. I think this goes without saying, but the messages should support Unicode(any language) and not just ASCII(a-z, special characters).

Here is a list of BEPs if you're curious: http://bittorrent.org/beps/bep_0000.html
You are probably familiar with some or most of these like UDP trackers, uTP, DHT, etc..

For the messages, I think there should be some sort of limits to mitigate spam. I think message filtering should only be done by the client. If there is any message filtering in the BEP it should be very very minimal because if it's too much it would feel too restrictive in my opinion.

general filter example for everyone: (ignore FROM any) individual messages exceeding 200 words
specific filter example for a spammer: (ignore FROM specific IP FOR 24 hours) block/ignore all messages
rate limit filter example: (ignore FROM any) messages exceed 65 per minute

whitelist: (accept FROM specific IP) ignore above filters

This is a little bit off topic but it's still sort of related. Speaking of BEPs, something else that should also be considered is BEP 52(aka BitTorrent v2).

more info:
http://bittorrent.org/beps/bep_0052.html
https://blog.libtorrent.org/2020/09/bittorrent-v2/