[Twisted-Python] Words.Participant capabilities
So, I was looking at doing /whois for words.ircservice, and found that lots of accessors weren't available, and there may be a bunch of questions as to whether they should be. One central question is "Do queries about a participant get answered by the server, or by the participant's client?" Having the server answer the questions is faster and cuts down on traffic, particularly if it's a question that everyone is frequently going to be asking about everyone else. But letting the client provide the answers gives the client more freedom to protect their privacy by refusing to answer, or lying, etc. ("No... she's not home. Really. You just missed her. No, that's not her voice in the background, that's just the TV.") More specific points: There's no way for a Words client to determine the online status of another Participant without adding that person to their contact list. Should there be? Almost definately. Unless for some reason you *want* them to have to go through the hurdle of getting you added to their contact list. More user information. Should a Words client be able to look up another Participant and maybe find out what their Identity is, and maybe get a few bits of meta-data out of that? Anything from a single IRCNAME-style string to a contact-manager VCard. Server descriptions. The best I've seen is something like self.service.serviceName, which in practice always yields "twisted.words". How can we get something more descriptive, like "The Official Words Service Of The 2002 Olympics" or "pb://192.168.0.2/twisted.words/"? When we get inter-server connections going, do we want to disclose which server a participant initially signed on to? Do we want to disclose the internet address of the participant's client? Away messages and idle times. Words doesn't have these. Should it? That's all for now, - Kevin, (who is still NOT wasting coding time on IRC servers.) -- The moon is new, 1.9% illuminated, 28.2 days old.
Some quick notes. They're really ideas and opinions, even though it sounds like I'm telling you what to do. :D On Mon, 2002-02-11 at 00:06, Kevin Turner wrote:
One central question is "Do queries about a participant get answered by the server, or by the participant's client?"
Let the server handle user-status queries, but let the client tell the server how to respond to them.
More specific points:
There's no way for a Words client to determine the online status of another Participant without adding that person to their contact list. Should there be? Almost definately. Unless for some reason you *want* them to have to go through the hurdle of getting you added to their contact list.
Let the user-who-is-being-queried specify how they want this to be answered.
More user information. Should a Words client be able to look up another Participant and maybe find out what their Identity is, and maybe get a few bits of meta-data out of that? Anything from a single IRCNAME-style string to a contact-manager VCard.
Again, let the client specify. OK, I'm noticing a pattern here. This "capabilities" issue has been popping up a *lot* recently, so maybe some sort of generalized "capability system" might crop up out of this (ie, a way to grant or deny capabilities between perspectives (or identities?)). something to think about.
Server descriptions. The best I've seen is something like self.service.serviceName, which in practice always yields "twisted.words". How can we get something more descriptive, like "The Official Words Service Of The 2002 Olympics" or "pb://192.168.0.2/twisted.words/"?
I'm not sure where you're going with this point, but I get an odd pleasure out of seeing "pb://".
When we get inter-server connections going, do we want to disclose which server a participant initially signed on to? Do we want to disclose the internet address of the participant's client?
I *definitely* don't want to allow clients to get IPs of other clients without explicit consent. After living on dalnet for a few years, where kiddies DDoS you for looking at them the wrong way, I've been locked into this opinion. And the server thing - I don't see any harm, but why does it matter? (that is, if you can think of a reason to do it, I don't think there's any problem with doing it)
Away messages and idle times. Words doesn't have these. Should it?
Yeah.
That's all for now,
So yeah, unless there's some reason to give access to information about a user/server other than "because it's in /whois", then I don't really see the point.
- Kevin, (who is still NOT wasting coding time on IRC servers.)
We believe you. Keep up the good work on hacking not-IRC, anyhow. :-D -- Chris Armstrong << radix@twistedmatrix.com >> http://twistedmatrix.com/users/carmstro.twistd/
On Sun, 2002-02-10 at 23:14, Christopher Armstrong wrote:
On Mon, 2002-02-11 at 00:06, Kevin Turner wrote:
One central question is "Do queries about a participant get answered by the server, or by the participant's client?"
Let the server handle user-status queries, but let the client tell the server how to respond to them.
Does that provide enough flexibility? Your possible configurations would be limited by the things the server can think of. That means you probably can't program a configuration like "If it's during working hours and I don't have anything scheduled on my appointment calander and I don't have a personal chat session with Cindy open and I'm not listening to my deth metal playlist, then let Ross see my status as 'available'."
There's no way for a Words client to determine the online status of another Participant without adding that person to their contact list.
Let the user-who-is-being-queried specify how they want this to be answered.
More user information. Should a Words client be able to look up another Participant and maybe find out what their Identity is [...]
Again, let the client specify.
Ok, that at least means "Yes, we need to add this to Participant's remote interface" for each of those features.
OK, I'm noticing a pattern here. This "capabilities" issue has been popping up a *lot* recently, so maybe some sort of generalized "capability system" might crop up out of this (ie, a way to grant or deny capabilities between perspectives (or identities?)). something to think about.
Server descriptions. The best I've seen is something like self.service.serviceName, which in practice always yields "twisted.words".
I'm not sure where you're going with this point,
I just want to stop seeing "welcome to twisted.quux" on whatever service I sign on to, and instead see something that identifies whose service I'm connected using.
I *definitely* don't want to allow clients to get IPs of other clients without explicit consent. After living on dalnet for a few years, where kiddies DDoS you for looking at them the wrong way, I've been locked into this opinion.
You're right about client IPs, I think. There are only two reasons those are useful on IRC. 1) to help identify the user, which you have a hard time doing due to IRC's non-existant authentication 2) DoS attacks. Since we'll actually have authentication, reason #1 goes away.
And the server thing - I don't see any harm, but why does it matter?
I can think of two reasons for publishing the server address. One is for advertising, you might be thinking "Gee, my server sucks. What are other people using?" The other might be to help track down problems. "That server is administered really poorly. Lets add it to our blacklist."
Away messages and idle times. Words doesn't have these. Should it?
Yeah.
On Mon, 2002-02-11 at 18:43, Kevin Turner wrote:
On Sun, 2002-02-10 at 23:14, Christopher Armstrong wrote:
On Mon, 2002-02-11 at 00:06, Kevin Turner wrote:
One central question is "Do queries about a participant get answered by the server, or by the participant's client?"
Let the server handle user-status queries, but let the client tell the server how to respond to them.
Does that provide enough flexibility? Your possible configurations would be limited by the things the server can think of. That means you probably can't program a configuration like "If it's during working hours and I don't have anything scheduled on my appointment calander and I don't have a personal chat session with Cindy open and I'm not listening to my deth metal playlist, then let Ross see my status as 'available'."
Interesting. Maybe we could have an option to say "let the client respond to this query", but maybe that would just be a bunch of added complexity. *shrug*. [snip...]
Server descriptions. The best I've seen is something like self.service.serviceName, which in practice always yields "twisted.words".
I'm not sure where you're going with this point,
I just want to stop seeing "welcome to twisted.quux" on whatever service I sign on to, and instead see something that identifies whose service I'm connected using.
That probably shouldn't be the service name, but some sort of MOTD feature.
I *definitely* don't want to allow clients to get IPs of other clients without explicit consent. After living on dalnet for a few years, where kiddies DDoS you for looking at them the wrong way, I've been locked into this opinion.
You're right about client IPs, I think. There are only two reasons those are useful on IRC. 1) to help identify the user, which you have a hard time doing due to IRC's non-existant authentication 2) DoS attacks. Since we'll actually have authentication, reason #1 goes away.
Not allowing viewable IPs allows DoS attacks? Hmm. I guess when it comes to ops trying to ban a join-flood, or something. Of course, you can always have programmed DoS-stoppers, as well as "wordscops" who can see the IPs of participants. Or am I way off?
And the server thing - I don't see any harm, but why does it matter?
I can think of two reasons for publishing the server address. One is for advertising, you might be thinking "Gee, my server sucks. What are other people using?" The other might be to help track down problems. "That server is administered really poorly. Lets add it to our blacklist."
OK. -- Chris Armstrong << radix@twistedmatrix.com >> http://twistedmatrix.com/users/carmstro.twistd/
participants (2)
-
Christopher Armstrong -
Kevin Turner