FIBS Board backgammon forum

QuoteA bot which talks to each player unfortunate enough to start a game with an identified dropper might be amusing, especially if it can charcterize the dropper's behaviour: "your opponent TRUST_ME passive drops when gwc falls below 30% and opponent pip count is less than 40. responds to requests to resume with tells of 'blow me'. 17 recorded offences (with 98% confidence) in the 2 days since the account was openned. 95% of acounts in the originating network opened in the last 2 weeks have been droppers.  Your chances of completing your match with a win are estimated to be 0.01%.  This has been a public service announcement, Thank you. Have a nice day."  

Oh yes - bring that on....    

Is this an actual serious discussion?
Give me a moment, noone usually takes me seriously.

Lots of great points padski. Let me try to flavor your thinking with some of my observations and beliefs. As you probably know, I have done lots of thinking and experimentation around this. I will provide more specific responses to your points later.

diversity
---------
One eye-opening thing about the internet, which FIBS really brings into focus, is what a large and diverse "mind-space" we inhabit. It really does take all types to make the world go 'round.

One thing I have learned from lots of stealthy dropper-watching I have done, is that there is no one "type". There are a few classes for sure, but the mere presence of any open strategy will cause some of those to change anyway (the "arms race" you refer to). BTW, there are some 'closed' strategies in place, apparently, but they are relatively weak. Don't ask me how I know this.

trust
-----
It all comes down to trust, doesn't it? Especially when you factor in the diversity. That is, if you are designing for all "good" users and not just yourself, which is an important and difficult goal to achieve.

For instance, even after pointing out that I have had nothing to do with RepBot for more than have its' lifetime, and that the code is open-source and can be viewed by anyone,  and that the  omplaints/vouches can be viewed easily, there are those that *say* I am somehow manipulating the data!

open
----
I tried to make RepBot be absolutely open, and that is part of the reason that I passed the running of it off to someone else. That person chose to change a few things about it, which I disagreed with, but I try to see that as a good thing in that it was meant to serve all and not just me. One thing that changed, which a lot of people were asking for, is the lifting of the 10-vouch/complaint
limit. That ushered in an era of "10k-ing" abuse, which I am blamed for. But I'm drifting off topic... refocus.

People still complain about the dice on FIBS being fixed, or that bots are cheating. Enough said. There is no absolute when it comes to trusting an entity, other than this: if you are playing backgammon on fibs, then you trust the dice by definition. If you are experimenting to see if they are
not, then you are not "playing" (my defintion).

Another thing that the current "owner" of RepBot changed is closing access to the database archives. This is unfortunate.


simplicity
----------
I believed then, and now, that whatever "solution" you provide, better be damn simple. That's why I made RepBots' metric be simple addition and subtraction of experience. And still, there are many who don't understand it.

The alternative we are talking about here has the potential of becoming too hard to explain, and therefore, would not be trusted. I am trying to end up with something that contains the complexity in the implementation, but in the end shows the user something really simple.

truth
-----
This isn't a return to flaming, but don continuously brings up "objectivity" when discussing RepBot. The bottom line is that there is no bottom line. People on FIBS will believe what they want, or say they believe what they want you to think you...er, who knows what is going on for sure. Maybe
everyone on FIBS is really a bot, or a dog, or something...

All you can do is provide data and let people decide for themselves. People who I believe are rational about RepBot understand this. It is just data, take it or leave it.

user-participation
------------------
So I tried once to make this data-surfer application for RepBot data, so people could dig in a bit more and uncover the social-circles behind a reputation. Noone used it. That goes back to my point about simplicity.

I pushed for the 'friends' feature, which the current owner implemented, but apparently not many people understand it or use it. An argument for simplicity here, as well as a point about people being motivated at the point of a drop.

The point is, any strategy that requires "un-motivated user participation" is relatively doomed.  RepBot requires participation, but it gets it because people are motivated strongly right after they are dropped, and somewhat motivated for other reasons.

So I think that "reputation" is one thing, and that RepBot has established a certain level of "brand" and ownership over that domain, for better or worse. I probably should not have used the name "RepBot_II" in my post,
as this other thing would be providing something different. More on that
later.

Quote
The client holds the oldboard as much as fibs istelf does - could a client be asked to send the 'oldboard' data to the bot?

I think that there are some that could manipulate data that a client    provides, but perhaps not many. You could perhaps improve on that    strategy by encrypting the data transfer. It goes back to trust.
   There are many good aspects of this strategy, and it should be    discussed more.

Quote
Adding a feature to send a request should be easy, and I would be happy to do so.

Adding to what? Are you offering to help code this thing?

Quote
Do you have something in mind for sensing that the end of a match might be near?

First off, bear in mind that don's concern for bandwidth preservation applies.Therefore, one initially has only the match length to work with. Over time,one can "learn" average times for the various match lengths, and averageplaying speeds per user and factor that stuff in.
If you use "show games" on occasion, you can get updated with match scoresfor all matches with one command, and N-matches lines of output.To do anything with cube, pipcount etc... you need the board. If you have a board, it is getting older by the second and therefore its' value/accuracy
is degrading over time, but still somewhat useful in determining the relative priority between matches.

But all that you know. What I would like to hear you comment on, is the overall strategy with respect to bandwidth-conservation:

[/li]
• How detrimental is it to have a clip-style login open to fibs, even if it generates no commands? I.e. fibs needs to send all those CLIP_Who's out to one more socket. Assume toggle ready, silent, notify and report are all off for this one.
  
  
• Same question as above, but add toggle report and notify on.
  
  
• What is (your opinion) the acceptable limit of "look" command (and subsequent response of either a board or blind notification) frequency?
  
  
• Now, bearing in mind the limitations I have noted, how valuable do you think a periodic "show games" would be, and what should that period be?
  
  

Quote
to a thorough analysis of winning chances for the full lifecycle of the game

Initially, I am focusing on collection of data in the form of a boardstyle 3 position as late in the match as possible, for all "saved games". I presume it is straightforward to convert to gnubg/sgf (or whatever that is) format for analysis by gnubg, or jf format, or whatever else.

If you are thinking of ways to present this data in some sort of summary form, I welcome your thoughts and help here. For simplicity sake, I would leave out the "thorough" part as it pertains to the queried summary statement, but certainly provide the "raw" data for anyone who wishes more detailed inspection, which addresses the "open" design goal.

Quote
I'm would guess that many/most drops will tend to cluster around a point which is a

Thus my point about diversity above. I don't think it is fruitful to try any sort of analysis, but I welcome any ideas and experimentation here. I guess my use of experience as a factor goes against this, but I am aware of its' limitation and am working toward using other stronger factors.

Quote
Or perhaps clients could use a request function to effectively 'bank' gains in position.

Was this an argument for or against?
I like the request option, as it opens the door for client participation. A FibsCompanion-module strategy could also be employeed, but its' use would be limited by user-participation. So I believe the request option can not be counted on, certainly during the "boot-strapping" process.

Quote
responses to requests to resume, etc. might help to bootstrap the effort of characterising dropping

Again, it is hard to profile dropping behaviour, but I think I get what you are saying. But here is where the diversity factor kicks in. Allow me some flame-leeway here for a moment.

You can not peer into the hearts and minds of men. Hypothetically, you could have a "well-known" dropper, or even one who openly admits to being a dropper, hell even a DropperBot, and maria would still vouch for it and probably play it. And the whole time don would be screaming that he has been treated unfairly, for what I can't predict because he has nothing to do with this particular story,
but he would.

So, I think that providing what history data you have, and letting the user decide what it "means", is better than calculating anything.

In the simplest possible example, userA shouts that they have been dropped by userB. userC tells LookerBot "ask userB" and gets something like: LookerBot tells you: "userB logged out 34 seconds ago while playing userA in a 5-point match. Last known score, 19 seconds before the log out, was
userA 4 - userB 1. Last known board position, 23 seconds before log out indicated 0.02% chance of winning: (gnubg game ID: <sgf-thingie>)"

Quote
What format would you want (if you wanted!) to take such reports in, something like the fibs output, yes ?

Again, I haven't thought much about this, but perhaps other commands could provide more detail. Boardstyle 1 is problematic, as multi-line tells are ugly. I think all this is better served by having the data in a DB and making it accessible via web pages using PHP, which is where
webrunner comes in. The reason I asked webbie to start storing savedgame reports had to do with providing some data in this regard, but for whatever reason, the man does not trust me.

Quote
A bot which talks to each player unfortunate enough to start a game with an identified dropper

RepBot did this (unsolicited tells) early on and was ridiculed for it. Patti demanded it stop, so it did. Yeah, people can perma-gag it, and/or you could provide a command to register users that don't want it,
but that won't fix it in the minds of the features detractors.

It held back RepBot a bit, for those users that did want to use it but could not figure out how to interface to it. Typically, users don't see non-ready players in their list, so they don't know how to
initiate a 'tell'. spielberg's confusion about repbot being "another program running on the fibs server" speaks to my simplicity argument.

I suggested a feature where a helpful repbot user could command repbot to initiate a dialog
with someone who needed help, but it was never implemented. Its' potential abuse could have been mitigated in certain ways, but it is useless to get into those now.

Quote
It is heartening when you see a dropper change his/her ways, which is something the community

Agree that allowing and encouraging this should be a design goal. I don't think that RepBot is particularly good at this, for the reason of requiring non-motivated participation.

Quote
Does having a "Droppers Anonymous" forum on fibsboard sound like a silly idea?

Yes.

Quote
I'm also thinking that implementing an auto-drop feature in a client might help to make dropper  ehaviour more predictabl

I don't understand what this would do.
Again, I don't believe predicting dropper behaviour is worthwhile.

Quote
Coupled with a bot (or other third parties) already capturing information about the game, forging a plausible game or position is a significant hurdle, and the bot only needs to retain the fact of where the data came from for it's authenticity to be open to scrutiny later.
Certainly the fact that the data is what a player claims, rather than unquestioned truth, remains important.

Oooo, brainstorm. Think P2P. A client could make requests to other clients for them to look at their position, which they do and either cache the result or send to a central bot.
The data for these other clients is coming from FIBS, not the requesting user.
Hard to spoof since the data is replicated.
Efficient bandwidth use, since requests and looks are only done near end of match.
A central bot could collect and verify these positions, OR simply provide a list of other clients that have it from which you retrieve and verify for yourself.

This requires its' own thread...

Quote
In the worst case I can immediately think of, such a facility could lead to an arms-race

Yup. I don't think it would happen much, but there are a few, and the number is growing.

Quote
but in the long run a good reputation service should be fairly robust even in the face of such an attack.

Agree, however I am trying not to restrict myself to the "reputation" thing.

Quote
easy, but the primary use case has to be for accepting/declining invitations, yes?
at which point some kind of summary is required, presumably using some kind of web of trust type caulculation.

Either that or your client auto-filters what it determines to be 'bad' invitations.
But that requires client coding, which won't come immediately.

Another short term goal might be to provide data upon request
so people start using the existing RepBot in a more informed and responsible manner.
But that requires user participation.

However, your point is taken. Assuming low user pariticpation and low control over
what client code is out there running, your statement is correct.
I think it is do-able, using gnubg analysis if drops exist, and by adding other data.
A summary value could be computed ("PERFECT RECORD", "3 SUSPECT DROP CASES OUTSTANDING")
Vouches could be used to clear outstanding "cases".
Its' useful to think in terms of legimate 'saves'. If someone cares about their LRM
(LookerBot Recommendation Metric), they could request the opponent vouch/clear
before they drop, or after they reconnect etc... I'd rather think about all this
later, those are just my initial thoughts.

For now, I am just experimenting with the short term goal of seeing if "interesting"
saved games are publically viewable with any useful accuracy and without consuming
a noticable amount of bandwidth.o

If that much succeeds, perhaps some summary recommendation thing could be worked on.
I think that whatever this ends up being, it might help if it was end-user configurable.

It also strikes me that, fibsboard might be able to calculate and store a
recommended "villains" list that could be imported/merged into popular clients configuration.

Quote

Quote
Adding a feature to send a request should be easy, and I would be happy to do so.

Adding to what? Are you offering to help code this thing?

He meant coding clients - at least those which are open source and allow tinkering and patching...

QuoteEither that or your client auto-filters what it determines to be 'bad' invitations.
But that requires client coding, which won't come immediately.

Hehehehehe, I have it on good authority that a client side filter patch already exists for cocoafibs    

That's awesome news diane. I'll have to check that code out for myself and see what hope it has for linux.  If there is hope for penetrating the client market on fibs, then let me propose something like this:

The following is a *very* rough draft of a FIBS "C2C" (client-to-client) system that detects "saved game" board state with a high level of accuracy and trust.

By accuracy, I mean it is captured at a point in the match which is a minimal number of moves from the point at which the actual match was saved on fibs. By trust, I mean that when viewed by a third party, that third party has some assurances that the position is not a manufactured one.

This "C2C" system uses:

• cooperating clients
• a (cooperating) central bot ("lookerbot")
• "silent tells" to communicate i.e. use fibs "tell" command with automatic filtering at the other end so the user is not bothered with it (unless they choose to monitor).

Once detected, there are several automatic actions that can be configured, including local analysis and database persistence for later retrieval.

This first explanation is in the form of an example dialog, with details left out for clarity:

you (padski), playing a "qualifying" opponent (see config below), "near the end" of the match:

   - tell LookerBot "request clients 3"
   - LookerBot tells you "clients: socksey Mort vegasvic"
   - LOCK (see below)
   - tell socksey "LB cookie1 board:padski:opponent:5:4:0:..."
   - tell Mort "LB cookie1 board:padski:opponent:5:4:0:..."
   - tell vegasvic cookie1 "LB board:padski:opponent:5:4:0:..."
   - tell LookerBot cookie1 "LB board:padski:opponent:5:4:0:..."
       (optional?)
       - socksey tells you     "padski:cookie1 retrieved padski:opponent:5:4:0:..."
       - Mort tells you        "padski:cookie1 retrieved padski:opponent:5:4:0:..."
       - vegasvic tells you    "padski:cookie1 retrieved padski:opponent:5:4:0:..."
       - LookerBot tells you   "padski:cookie1 retrieved padski:opponent:5:4:0:..."
   - LookerBot tells you   "padski:cookie1 retrieved (matches socksey Mort vegasvic) padski:opponent:5:4:0:..."
   - UNLOCK (see below)

padski's client detects normal match finish
   - nothing happens locally

padski's client detects a "potential drop" (leave, log off, connection drop...), followed by timeout to allow for resuming
   - tell LookerBot "remember cookie1 board:padski:opponent:5:4:0:..."
   - LookerBot tells you   "padski:cookie1 matching (socksey Mort vegasvic), saved"

socksey's client (same for Mort and vegasvic):
   - padski tells you "LB cookie1 board:padski:opponent:5:4:0:..."
   - look padski
   - board:padski:opponent:5:4:0:...
   - tell padski "cookie1 retrieved board:padski:opponent:5:4:0:..."
       (optional?)
       - LookerBot tells you   "LB confirm padski:cookie1 board:padski:opponent:5:4:0:..."
   - tell LookerBot "confirm padski:cookie1 board:padski:opponent:5:4:0:..."
       (socksey's client detects normal match finish)
           - configurable flush of that match
       (socksey's client detects match drop)
           - configurable automatic actions (see below)

LookerBot:
   - padski tells you "request clients 3"
   - tell padski "clients: socksey Mort vegasvic"
   - padski tells you "cookie1 board:padski:opponent:5:4:0:..."
   - look padski
   - board:padski:opponent:5:4:0:...
   - tell padski "cookie1 retrieved board:padski:opponent:5:4:0:..."

More details (but still far from what is needed):

"LOCK":
   Rather than re-sending if a move happens in between the time you request
   a look from another client and when the other client looks, the client
   locks your move from being sent (and picks a time near the end of the
   match when it is your turn...) until responses are received.
   There is a timeout, backup clients, all configurable etc...

configuration (just some):

   This is where you can adjust your definition of a 'qualifying' opponent

   Note: with reasonable defaults, most users won't adjust these, but their mere presence helps thwart/mitigate advanced prankster strategies.

       LookerBot functionality configuration panel:

       Don't bother to check on:
           CHECKBOX: friends
           CHECKBOX: players with experience > [WIDGET 5k]
           CHECKBOX: players who have finished [WIDGET 2] matches with me in the last [WIDGET 2 weeks]

       Number of redundant clients: [WIDGET 3]
       Number of client retries: [WIDGET 1]

       "looker bot" usernames: [WIDGET: LookerBot, RepBot_II, lookerbackup]
       "looker bot" timeout: [WIDGET 3] seconds

       If none of the lookerbot's are logged in or responsive,
       select my own peers based on:
           [CHECKBOX] prefer friends
           [CHECKBOX] maximize experience
           [CHECKBOX] minimize idle time

       Locking timeout: [WIDGET 3] seconds

       Automatic actions:
           If dropped match has < [WIDGET 10]% chance of winning:
               CHECKBOX: add to villains list
               CHECKBOX: register complaint with RepBot

blinding:
   What happens when a client is blinded by the target user?
   Maybe LookerBot, when 3 clients are requested, responses with twice that number for use by the client as alternates
   Same thing goes for clients that are non-responsive/timed-out

cookies:
    two that I am waving my arms about:
       -one for protocol (knowing which response belongs to which request)
       -one for identifying boards.
   timestamp (fibs clock) should probably be part of them
   In general, an open standard for inter-client communication should be
   defined so that other clients/bots could participate, similar to the
   javafibs profile thingie.

replication "forward":
   if more trust/replication needs to be built in,  and bandwidth is available,        perhaps the above could be enhanced to notice when clients that have  saved matches logout/disconnect, to request additional replication,  with the ultimate goal of keeping saved matches "alive" and stored  within the currently logged-in and responsive clients.
       But I leave this as an exercise to the reader...

Who knows, maybe internet P2P traffic outside of FIBS could be used for
some of this, but that probably requires opening ports on client/user machines.

Before refinements are discussed, let's try to poke holes in the basic approach.
Yeah, I know I'm still leaving off any part about how third parties make use of this information. Assume for now that they "tell LookerBot ask <user>" and get some useful summary line in response.

burper,

a quick response from me right now, to express my enjoyment of and interest in this conversation.  You raise a lot of points and I may not be able to digest and address much more tonight.

I was initially drawn into the conversation by your kind words on the subject of cocoafibs, and the main thrust of my comments was that I would happily pick up the coding on the client end of a worthwhile project, which is what you your current investigations look like.

On the general philosophy of software you outline, I think we are largely in agreement: I will go through it in detail again later. Certainly I favour an approach based on openess, freedom, and choice for the user which are pretty much the fundamental values here for me. I am keen to revisit the question of what might make for sucessful uptake in reputation services (or software and technology for that matter), but I fancy that will come in time

On the question of what might make an acceptable load for a bot to place on fibs I am willing to proffer an opinion, when I have had a chance to look more closely.  At first glance the numbers you mention don't sound unreasonable.  But I have to say that the answer to these questions must ultimately lie with our hosts, fibs

I have spent a few days working with cocoafibs, and to my initial concerns about portability (see thread in cocoafibs forum) I have to add that I am currently trying to reach the original author(s) with regard to access to the sourceforge project and clarifying the copyright and license status. I also plan to look into whether the beta expiry date of oct 2006 in the sourceforge cvs is in the binary that's in general circulation.  While I'm having a pile of of fun playing with cocafibs, I've yet to catch the ObjC bug, and the reality of portability will soon bite. So, while I want to support the cocoafibs community and create a future there, and I'm not ruling out the possibility of a port, the best current option I've seen on linux is kbackgammon [which runs on my mac too, but athena is not aqua ;-( ], but coding modules in C for use from both seems like a potentially promissing avenue.

This evening I implemented a very primitive invitation filter for cocoafibs, and saw that it was good  After chewing over this mornings thoughts I came back to the fact that this was one of the things on my todo list while I was guest in the land of a client-without-sourcecode, and that in a similar way to the way that RBLs were the main stay of spam filtering for some time, a personally tuned invitation filter should practically solve the "dropper problem" (I basically concurr with patti on this one I think).  That's not to say I have lost enthusiam for our conversation, quite the opposite!

I agree that there is plenty of mileage in the P2P question, more than enough for a thread of its own

Anyway I'm gonna go back, refresh, and try for more in a next post

excellent points, Burper .. discovering this thread, i'm further impressed with the depth of thought that has gone into creating RepBot and considering future enhancements .. thanks to all for the good work creating and supporting RepBot and those others who have contributed to the conversations on its improvement

i especially like the three key points you raise here, simplicity, truth, and user-participation .. IMO, they are worth repeating

Quote from: burper on September 05, 2006, 04:37:39 PM
simplicity
----------
I believed then, and now, that whatever "solution" you provide, better be damn simple. That's why I made RepBots' metric be simple addition and subtraction of experience. And still, there are many who don't understand it.

The alternative we are talking about here has the potential of becoming too hard to explain, and therefore, would not be trusted. I am trying to end up with something that contains the complexity in the implementation, but in the end shows the user something really simple.

truth
-----
All you can do is provide data and let people decide for themselves. People who I believe are rational about RepBot understand this. It is just data, take it or leave it.

it's evident from the history of RepBot that rational behavior is not a given .. additionally, the recent gBOT RepBot abuse problem highlights again the amount of emotional energy that can be stirred up by RepBot issues that have nothing to do with its metrics .. truth is one thing, trust is another

regarding the metrics, i'm a numbers oriented guy, but really had no clue what the numbers associated with RepBot mean .. it is fundamentally simple but somehow has been lost to even me with over a year of fibs experience and now over 12,000 games .. i'll skip repeating an explanation of it here, but will come back to it in another post

this is what i'd like to focus on here:

Quote
user-participation
------------------
So I tried once to make this data-surfer application for RepBot data, so people could dig in a bit more and uncover the social-circles behind a reputation. No one used it. That goes back to my point about simplicity.

I pushed for the 'friends' feature, which the current owner [of RepBot] implemented, but apparently not many people understand it or use it. An argument for simplicity here, as well as a point about people being motivated at the point of a drop.

i've only recently discovered the friends feature, its not obvious at all .. having spent several hours with it, i can understand why .. yet, now confident in understanding it, i realize it's fast becoming my favorite RepBot tool

i've discussed (at length) the friends feature, as currently implemented, with a number of experienced Fibsters, almost ad nauseum .. the responses have been mixed ranging from "yawn" to "neat, i didn't know that" .. i believe this confirms your simplicity point .. for whatever reasons, the friends feature appears to be NOT understood at all .. i'm summarizing my understanding of it for another post now .. because its also fundamentally simple

Quote
The point is, any strategy that requires "un-motivated user participation" is relatively doomed.  RepBot requires participation, but it gets it because people are motivated strongly right after they are dropped, and somewhat motivated for other reasons.

i'm not yet convinced about that doom comment, but it's quite clear "RepBot requires participation" is spot on .. it's self evident we are all strongly motivated by droppers .. "somewhat motivated" in light of the recent gBOT vs. RepBot wars, Sinderbot's dropper alerts, and past debates and crisis over pulling the plug on RepBot makes that almost humorous

frankly, i'm very motivated to introduce and promote the existing friends feature to new and longtime fibs users alike .. it's clear that many of us have implemented programmable buttons in JavaFIBS and use them regularly to screen invites from players with whom we're not familiar .. i'm now beginning to use the friends feature in that same way to not only pre-screen invites, but find other players i may not know to invite to play myself with increased confidence over metrics alone

after countless successful references to saved games and RepBot ratings, i'm now coming to understand that this third tool, the friends feature is potentially VERY useful .. it ain't the be-all-end-all perfect solution, but it both enhances RepBot's value and in itself encourages proper RepBot usage .. so, thanks, burper for suggesting it, and thanks to Avi for implementing it .. i'll be posting later a summary of what i've found and hopefully encouraging others to use the friends feature regularly

what i'm discovering is the friends feature is a self-motivating one which has caused me to step back and reevaluate my vouches and come to appreciate those of my friends in a completely different way .. one that in my opinion encourages self-regulating and responsible use of RepBot .. check my post on the friends feature and hopefully you'll agree with me .. it should be ready at a fibsboard near you soon

You can lead a fibster to water...