Forums » Suggestions
Secured chat channels
Allow chat channels to be created and "owned" by a player, where said player can restrict access via authentication (password?) or other means.
Reasonings:
1. Provides a means to have secure communication without using guild or group chat which have their own requirements and restrictions.
2. Allows users more control over troublesome spammers.
3. Allows the creation of groups of unlimited size that contain players who are related in otherwise arbitrary ways without uninvited guests.
3. Allows plugins to post data using the internal VO chat system securely instead of connecting via TCP externally.
4. Continues to provide accessibility to developer monitoring services where complaints are made about behaviors and inappropriate chats.
Please consider this addition to the chat functionality in VO !
Reasonings:
1. Provides a means to have secure communication without using guild or group chat which have their own requirements and restrictions.
2. Allows users more control over troublesome spammers.
3. Allows the creation of groups of unlimited size that contain players who are related in otherwise arbitrary ways without uninvited guests.
3. Allows plugins to post data using the internal VO chat system securely instead of connecting via TCP externally.
4. Continues to provide accessibility to developer monitoring services where complaints are made about behaviors and inappropriate chats.
Please consider this addition to the chat functionality in VO !
Humm. I do generally support improving player-communication and collaboration, that's generally beneficial to the game.
I don't see any problematic or exploitative capabilities inherent to this that don't already exist in the current "number-channel" model: the only benefit is "certainty of audience" as opposed to the possibility of an adversarial "listener" (or "spammer") on a public numbered-channel. People have used numbered-channels for sharing plugin data for decades, as well, so that's not really any different either.
Playing out how something like this might work: It would probably be reasonable to attach it to the Key System. So, basically, possession of a user key would give ability to participate in an associated channel. People with owner keys could administer the channel (add/remove access), and would be able to see who had access at any given time.
Attaching this to Keys would probably be more accessible and have better long-term value than doing some kind of "password" thing. Plus, it gives a fixed and certain attachment between a given character and channel-access, which could be directly administered by the players; while a "password" for read-access would provide little benefit beyond the existing "random channel-number" (passwords get leaked quickly).
Anyway, I think this merits further community discussion and feedback.
I don't see any problematic or exploitative capabilities inherent to this that don't already exist in the current "number-channel" model: the only benefit is "certainty of audience" as opposed to the possibility of an adversarial "listener" (or "spammer") on a public numbered-channel. People have used numbered-channels for sharing plugin data for decades, as well, so that's not really any different either.
Playing out how something like this might work: It would probably be reasonable to attach it to the Key System. So, basically, possession of a user key would give ability to participate in an associated channel. People with owner keys could administer the channel (add/remove access), and would be able to see who had access at any given time.
Attaching this to Keys would probably be more accessible and have better long-term value than doing some kind of "password" thing. Plus, it gives a fixed and certain attachment between a given character and channel-access, which could be directly administered by the players; while a "password" for read-access would provide little benefit beyond the existing "random channel-number" (passwords get leaked quickly).
Anyway, I think this merits further community discussion and feedback.
Overall I'm very much for this. Though i have a few comments about OP's reasoning
Allows the creation of groups of unlimited size that contain players who are related in otherwise arbitrary ways without uninvited guests.
This would fall under a different suggestion, but wouldn't expanding group limits also cover this?
Allows plugins to post data using the internal VO chat system securely instead of connecting via TCP externally.
Question: Would there be a way for a plugin user to have that channel not echo that info to their public chat window? Because if not, things could get spammy.
Comment to inc on this:
Playing out how something like this might work: It would probably be reasonable to attach it to the Key System.
This would be a perfect solution. I love it. And it means that players don't need to keep updating passwords every time there is a change.
Allows the creation of groups of unlimited size that contain players who are related in otherwise arbitrary ways without uninvited guests.
This would fall under a different suggestion, but wouldn't expanding group limits also cover this?
Allows plugins to post data using the internal VO chat system securely instead of connecting via TCP externally.
Question: Would there be a way for a plugin user to have that channel not echo that info to their public chat window? Because if not, things could get spammy.
Comment to inc on this:
Playing out how something like this might work: It would probably be reasonable to attach it to the Key System.
This would be a perfect solution. I love it. And it means that players don't need to keep updating passwords every time there is a change.
Plugins already have methods to hide data spam sent to 'secret' channels, by filtering the chatreciever function to ignore input from (insert used channel here).
my apologies for the late reply.
Incarnate's suggestion for implementation is far better than what I had suggested. It's brilliant!
The next thing to consider is how the channel might be named.. course if it's attached to the key system, that does seem to imply the channel could have a name that is something more meaningful than a number. Don't you think this seems to be the case?
Incarnate's suggestion for implementation is far better than what I had suggested. It's brilliant!
The next thing to consider is how the channel might be named.. course if it's attached to the key system, that does seem to imply the channel could have a name that is something more meaningful than a number. Don't you think this seems to be the case?