If I Could Make 1 Suggestion For Repbot

[snowjake]

It would be to somehow indicate whether sved games (or even a majority of them) were with the person ahead, even, or behind.

[burper]

when will your new server be ready? do you have a business plan in mind?

[don]

Jake, RepBot only has access to the saved games database, not the scores or positions of the saved matches.  See http://www.fibs.com/savedgames/list.html .

A FIBS lookalike had implemented what you want, with the "show saved <name>" command showing what you see when you do it to yourself on FIBS, as well as an "oldboard <name> <name>" command.  The server was NOBS but it doesn't seem to be up anymore.  Without more access to the FIBS database, which is unlikely, what you ask is not possible.

[burper]

It is possible, via the look command, but that is more complexity than don can handle.

[don]

burper Posted on Aug 28 2006, 10:17 AM
  It is possible, via the look command, but that is more complexity than don can handle. 

I'm not aware of any way to use the look command to view someone's saved matches.

[burper]

If a bot used look before it was saved... ah but I knew you wouldn't get it.

Oh wait, its' about you being right. So go ahead and re-define the problem statement to suit whatever argument you're trying to have, win it, and we'll all stand back and cheer. Well played. don beats don every time.

[don]

ROFL.  I was wondering if burper would bring up that possibilty:

burper Posted on Aug 28 2006, 07:44 PM
  If a bot used look before it was saved... ah but I knew you wouldn't get it.

It would be possible to have a bot hammer FIBS continuously, cycling through every game being played, to keep track of the most recent position available to the bot!  Without bringing up the "blind" command, I'd think such a bot might approach measurable levels of FIBS activity such that it might affect packet-transfer rates and general performance of FIBS in terms of speed for the rest of the users.  (hmm, right now about 30 matches being played on FIBS, and I'd assume for any kind of accuracy of such a bot, 30 packets into and out of FIBS per second?)  In any case, it is impossible for such a bot to achieve real-time capabilities.

Meanwhile, the question was, unless I am mistaken, how snowjake can can find out the current leader in saved matches.  Unless burper or someone else wants to write such a bot, the "look" command is useless, as I said before.  In any event, without access to the FIBS database, it's not practical.

This is particularly amusing coming from Burper, one of the worst abusers of RepBot.  In my short complaint list, other than the obvious duplicates I've got from HoneyGirl(2), NIHI(3), Mort(2) and vic(2), the last time I checked I had four from Burper:  aristoF, CantBuyAThrill, nutcracker, and thefog.  This was a few months ago, Burper may have added more fake IDs since then.  This also makes my point that the subjective factors of RepBot make it exploitable by the worst of FIBS.

--
don

[burper]

exactly the nonsense I predicted.

[burper]

Still no constructive information from don, so as usual, I will have to forge ahead myself.

ROFL

No justification given, just don laughing at himself I presume.  Or perhaps this makes a point and proves something inferiors such as myself don't understand (which I am sure is dons' perspective).

I was wondering if burper would bring up that possibilty

Ah yes, don is always 6 steps ahead of me. ROFL.

It would be possible to have a bot hammer FIBS continuously

Of course, but who said that was a goal? I don't doubt you can think of no better implementation don.

Without bringing up the "blind" command

Of course you don't want to bring up things you can't address.
If someone has blinded such a robot, that gives you great information, AND saves the precious bandwidth you think is in such short supply.

30 packets a second

Wow, you actually think there are 30 moves per second on FIBS with 30 games in progress?

for any kind of accuracy

That statement lacks accuracy. I don't think you would know what accuracy was if it bit you in the rear. How about an accuracy of "none"? Duh. And you call yourself a computer scientist. Tsk tsk.

real-time

Another term you apparently have no knowledge of. BTW, this bot would be communicating over something called the "internet".

Meanwhile, the question was, unless I am mistaken, how snowjake can can find out the current leader in saved matches

Exactly as I predicted, re-defining the problem statement to fit your argument.
As you are so fond of saying to everyone else: "scroll back". See the word "indicate" that snowjake used? Look it up.

Unless burper or someone else wants to write such a bot, the "look" command is useless

Of course the bot would be useless unless someone writes it first!!!! Wow.

as I said before

yes, we know you were being stupid before too. And you will again. Or was that supposed to add weight to your argument?

This is particularly amusing coming from Burper, one of the worst abusers of RepBot.

...and here don goes into off-topic land, proving he has an axe to grind and nothing useful to offer.

So, ignoring don and his issues, one could write the bot a couple different ways at least: have it take requests from users that suspect they may be soon dropped. Or a bot that cycled through the games, at perhaps no more than a certain acceptable rate, collecting positions. It could also record the "toggle notify/record" messages to track when games start/end, as well as when people login/off etc...

The bot could might be made to skip matches recently started, where "recent" would be defined differently for different lengths of match. The bot might focus less on users with larger experience, assuming they already have established "reputation". It might focus less on users with no complaints. It might be made to keep tabs on playing speed, and on idle times to further skip matches where it is impossible or unlikely that there is any match update. How about skipping matches where one player has vouched for the other. See? Lots of ways to be "practical" if you *think*.

Yes, it is possible you won't get the very last position for every match, but you would know the score of the match so far, and a reasonably recent position, as well as a match length and duration. You would know when the position was obtained and when the match was saved, so you would know how close to the end it was. It could also show you who has the bot blinded. All of that would give a pretty fair indication of what you want, especially for habitual droppers, all without "hammering" FIBS at 30 packets a second. ROFL. Sorry don, *way* too much useful information for you to handle I am sure, but it was meant for useful people, not you.

[diane]

have it take requests from users that suspect they may be soon dropped

That certainly seemed useful to me - and was kind of on my mind when I made the post of the oldboard on here recently.  It is nice to have that record of the game you are left sat looking at  - wishing the world could see what you see (even if - like in that case - you arent certain it is a drop).  One classic MO at fibs is the passive drop - the 'I wont drop - I just wont move until you drop' (made infamous, I think, by janana), but to be able to call upon the bot to have a look and record the moment would  - I hope - help to eliminate that little issue.  One little issue down, a hundred to go - but as we all know - a journey of a thousand miles starts with one step.....

As for the don rubbish - cant we just have a sensible discussion and pretend he isnt trying to gain attention in the background??  

SOMEBODY call the firebrigade - I think I see *flames*    

[socksey]

SOMEBODY call the firebrigade - I think I see *flames*

That was a figment of your imagination!  

Imagine this burper.  Knock it off, please.  

socksey



"Television is the first truly democratic culture, the first culture available to everybody and entirely governed by what the people want. The most terrifying thing is what people do want." - Clive Barnes    

[burper]

ok, constructive from now on. at least in this thread.
just reading about padski's work with cocoafibs, and diane 'thousand steps' comment and it made me think:
if just the request based bot existed, and clients began adding a feature to sense the near end of a match and auto-request...

socksey: remove that "Way5" posting, it is spam.

[webrunner]

socksey: remove that "Way5" posting, it is spam.

A simple "please" would have done the Job Burper..

[burper]

socksey: remove that "Way5" posting, it is spam.

A simple "please" would have done the Job Burper..

Wrong. The "simple" command worked with much less typing.

[burper]

Initial experiments have been promising. The secret sauce will be the optimizing of priorities for which matches to look at during the next cycle.

So far, I assign a frequency metric to each match based on:

• -minimum experience of the two players (more exp means less chance of dropping. ok, somewhat weak, but easy to compute)
• -how often they have played each other before (stronger factor, but not enough accumulated data to have a large effect yet)
• -if blinded, frequency=0 (noone knows about the bot, or that it is looking, so noone has blinded it, but this should help a great deal if/when they do)
• -if either user is 'away' frequency=0 (not often, but easy to do)

Then, during each cycle, I factor this in with how long ago each match was last updated.

The bot gets board states of all "potentially dropped" matches (logoff/disconnect when player was engaged) no older then 30 seconds from the drop, and most are within 10 seconds.

The bot currently executes ~48 look commands per minute.

More frequency factors for improvement coming:

• -number of losses each player has had
• -matchlen,score,cube, i.e. less frequent for longer matches recently started, and more frequently for shorter matches with larger elapsed time and cube values (partially relies on previous board state)
• -adjusted higher based on player idle times
• -number of saved games (from fibs.com/savedgames of course)
• -reputation/complaints/vouches, but that's going to be harder to get in the short term

Webbie, would you like to host RepBot_II ?
It will probably require some web front-end for viewing the data in a nicely formatted way. Being able to access a summary line right on fibs would be nice, but I haven't thought about how that would look.

Maybe don has some constructive ideas?

[socksey]

Wrong. The "simple" command worked with much less typing.

Wrong.  Sorry to disappoint you, but your "command" had nothing to do with my doing my job.  I removed the spam when it was convenient to me to do so.  

Burper, I'm sure your work will be appreciated eventually.  Thanks for your efforts.  Wish I was bright enough to understand most of what you are expaining.   ^_^  

socksey



"The men that American people admire most extravagantly are the most daring liars; the men they detest the most violently are those who try to tell them the truth" - H. L. Mencken

[diane]

The bot currently executes ~48 look commands per minute.

More frequency factors for improvement coming

It will probably require some web front-end for viewing the data in a nicely formatted way. Being able to access a summary line right on fibs would be nice, but I haven't thought about how that would look.

Because we are all agreed that once dropped, it is no longer possible for the bot to 'look' at the match, and that most fibs users use a 'fancy' client of some sort   rather than just telnet - and actually it may even be easier with telnet..The client holds the oldboard as much as fibs istelf does - could a client be asked to send the 'oldboard' data to the bot?  Obviously if this is possible it requires the goodwill of all the programmers who have written and maintain clients - but could this be the next step towards accurate and unbiased dropper information?  Or is it too possible for a user to manipulate what the client sends to be a good way to go (course I am still assuming it is possible at all )

Oh, and WOW to what you have done already...  

[padski]

just reading about padski's work with cocoafibs, and diane 'thousand steps' comment and it made me think:
if just the request based bot existed, and clients began adding a feature to sense the near end of a match and auto-request...

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

Do you have something in mind for sensing that the end of a match might be near? The first thing that comes to mind is to use some match/game position evaluation, and then perhaps tune from there.  

Is there any reasonable simple counting technique that provides a reasonable approximation to a thorough analysis of winning chances for the full lifecycle of the game (as opposed to being optimised towards, for example, bearing-off) ?

I'm would guess that many/most drops will tend to cluster around a point which is a function of mwc and pip count, where pip count would be fairly low, so likely just pip-count would make a good first cut, and may even turn out to be the better guide in the long run.

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

There is some overlap here with the idea of having types of reports.  Even information gained after the event, without the gold standard of fibs or a bot being the observer, could be very helpful.  A report which included the match position, game position (or even just pip count), and/or info like style of drop, responses to requests to resume, etc. might help to bootstrap the effort of characterising dropping behaviour to know better when to sample or request a witness.

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

A 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."  

I would think that with enough data your system would also have the potential to do a good job of distinguishing between malicious droppers and those with lousy networking.  The same data would enable a number of other possible analysis, like move rate for example.  That would be handy for when donz goes on holiday

It is heartening when you see a dropper change his/her ways, which is something the community does with some success, but which this tool so far addresses only indirectly.  I can't help wondering what goes on in the mind of a dropper?  

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

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

[padski]

could a client be asked to send the 'oldboard' data to the bot? .... Or is it too possible for a user to manipulate what the client sends to be a good way to go?

As I've indicated, I think this is a good idea

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.

In the worst case I can immediately think of, such a facility could lead to an arms-race with a clever prankster, which might cause commotion and divert attention from more pressing needs, but in the long run a good reputation service should be fairly robust even in the face of such an attack.

Similarly, it's hard to see how abuse of such a facility could be used as effective weapon in an attack on an individual or group.

The positive benefits of such a facility would seem to me to outweigh this risk, and I think the existing repbot facilities have already been shown to have bigger holes.  It would be prudent to consider the possibilities further, but there will be ample time for that should such a service start to come on-line.

Such a facility does raise the important question of how the service can best present such data to users and clients?  It's not hard to imagine an api that would make all the data accessible, or even client support that would make surfing around the rep data, viewing positions, etc. 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.  The strength of that web of trust then becomes quite important to the abuse question.

[padski]

One more thought: it's interesting to note the paralells between droppers and spammers.

[diane]

A 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....    

[burper]

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.

[burper]

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.

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?

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?
  
  

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.

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.

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.

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>)"

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.

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.

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.

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

Yes.

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.

[burper]

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...

[burper]

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.

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.

[burper]

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.

[diane]

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...

Either 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    

[burper]

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.

[padski]

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

[sixty_something]

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

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:

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

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

[burper]

You can lead a fibster to water...