This feature refers to the ability to control who can and who cannot send you telegrams. Currently, any citizen can send you a telegram, as many times as they like, whether you want to receive them or not. Oddly, some people find this annoying. :)

When it comes to implementing this feature, the first design question is: should the blocking be implemented by the browser or by the uniserver? For the browser-based approach, the browser would maintain a list of blocked citizens on your PC, and when your browser receives a telegram from one of those users, it would simply ignore it. For the uniserver-based approach, the blocking would occur at the universe server at the moment the sender tries to send you the telegram.

The browser-based approach is much simpler to implement, because it would require no changes to the universe server and no changes to the network protocol. However, it has some serious drawbacks. One is, as is currently a problem with the contact list, if you have more than one installation of AW (say on two different PCs in your house) you'll either have to block everyone twice, once on each PC, or else you will have telegrams blocked on one PC but not on another.

The other drawback of the browser-based approach is the question of what you want the sender to see when they try to send you a telegram but get blocked. It would be very nice to know, as a person sending a telegram, that the person you just telegrammed has you blocked, so there's no point in telegramming them further. In fact, the simplest solution of all would simply be to have "Send Telegram..." automatically disabled in the menu when you right-click on their name. So, you would like the system to immediately tell you that you can't send this person a telegram. However, if the blocking is browser-based, and the other user is not online at the moment, there's no way to do this because that information isn't available.

OK, you say, fine, just queue up the telegram and notify them later that it was blocked, when they get online. Ah, but then a new problem arises! If we ever get around to providing a way of removing that pesky green check mark (a feature that is closely related to this one in many ways) then this would become a way to test if someone was online. Just send them a telegram...if you get a blocked message right away, then they must be online!

That leaves us with implementing blocking in the universe server, which is almost certainly the way we would approach adding this feature. A server-based approach allows the sender to be immediately notified of the block regardless of whether the recipient is online or not. This requires implementing a new database on the universe server side that stores each citizen's blocked user list, and adding new messages to the protocol for adding and removing citizens from the list. It also requires implementing new windows and controls in the browser for adding to, removing from, and viewing your blocked list. A browser-based approach would require that as well.

Complicating things even further are several obvious extensions... if I blocked someone's telegrams, don't I also want to mute them whenever they show up and try to chat with me? Or maybe I don't? Should there be an option for one or the other? Maybe I don't want a blocked list at all, maybe I just want to only *accept* telegrams from people who are on my contact list, and automatically block everyone else. This approach, which also has merit, requires moving the contact list up to the universe server, for the same reasons as above. This opens up a whole new can of worms. Maybe the blocked user list and the contact list should be the same list, all stored on the uniserver. Each individual citizen on your list would have flags indicating whether or not you want to receive telegrams from that person. So then blocking someone would become a matter of adding them to your contact list and marking them as blocked. But wait, you say, I don't want to waste a slot on my contact list just to block some jerk from sending me telegrams. Well then, obviously we are going to have to increase the maximum length of the contact list well beyond its current limit of 100, which just happens to be another frequently requested feature.