Who do you trust?
- Thread starter DuaneJackson
- Start date
- Original Poster
- #42
I think it's a good idea and it has legs - as do most others by looking at the poll.
My problem is that I am inundated with client work atm as well as having KashFlow to mantina and further develop and another in-house spin-off service for early next year. So I simply don't have the time and I don't want to make a half-hearted attempt at it.
I'd need to pull together a good to team to pull this off, and I know who I'd use. It's just a matter of not having the time. I really don't mind if someone else wants to run with it. Failign that I may re-visit it next year when I have more free time.
Improve Search Listings - Don't worry about Daves explanation being complicated. He's a 'back room boy', and would be my first choice to do the required back-end calculations but I'd never let him lose on writing the 'how it works' copy : )
My problem is that I am inundated with client work atm as well as having KashFlow to mantina and further develop and another in-house spin-off service for early next year. So I simply don't have the time and I don't want to make a half-hearted attempt at it.
I'd need to pull together a good to team to pull this off, and I know who I'd use. It's just a matter of not having the time. I really don't mind if someone else wants to run with it. Failign that I may re-visit it next year when I have more free time.
Improve Search Listings - Don't worry about Daves explanation being complicated. He's a 'back room boy', and would be my first choice to do the required back-end calculations but I'd never let him lose on writing the 'how it works' copy : )
Upvote
0
A
amo crafts
I would have thought the best route to chose would be the one which includes nodes that the originator has the highest trust in. This would cause problems when the originator has no trust in one or more nodes on the route. Three methods to cope with such a situation would be:
So, in the example given:
Obviously that's a fairly simple example. If more nodes were added though the trusted route calculation would become more useful.
- the value is given a pre-defined trust value, 0.4 for example;
- the node is ignored and removed from the calculation, with a caveat supplied in the results; or
- the whole route is removed from the results, which gives users more reason to enter more trusted members (and more honest values).
So, in the example given:
- route A->B->C has a trusted route value of 0.85;
- route A->E->C has a trusted route value of 0.77; and
- route A->B->E->C has a trusted route value of AVG(0.85, 0.77) = 0.81
Obviously that's a fairly simple example. If more nodes were added though the trusted route calculation would become more useful.
Upvote
0
M
Mortime Business Software
Yes, teaching is definitely not one of my strong points. I have no patience at all in that area and sometimes end up losing my temper! But the diagram is very easy to understand, it's just that I'm not explaining it adequately. I'll try again at an explanation later as I'm watching the cricket. DO NOT tell me what happens in the cricket. I reckon we have already established a 600 run lead for two or three wickets, and we are now planning to declare at the end of day three. 
Dave
Dave
Upvote
0
M
Mortime Business Software
amo crafts wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I would have thought the best route to chose would be the one which includes nodes that the originator has the highest trust in.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Suppose X is an outsider, and asks A how much trust he has in C, then X would want to know the worst case too.
amo crafts wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This would cause problems when the originator has no trust in one or more nodes on the route. Three methods to cope with such a situation would be:
1. the value is given a pre-defined trust value, 0.4 for example;
2. the node is ignored and removed from the calculation, with a caveat supplied in the results; or
3. the whole route is removed from the results, which gives users more reason to enter more trusted members (and more honest values).
Note those calculations would be for determing which route to chose and would have no effect on the route value.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I think option 1 would be the best because just as nobody is perfect (i.e. deserving of 100% trust), everybody can be trusted to some degree. An assumption similar to 0.10 sounds reasonable to me at the moment because the route ADBC (see below) has route value 0.30 resulting from a perfectly reasonable collection of node values.
amo crafts wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
So, in the example given:
1. route A->B->C has a trusted route value of 0.85;
2. route A->E->C has a trusted route value of 0.77; and
3. route A->B->E->C has a trusted route value of AVG(0.85, 0.77) = 0.81
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
All the possible routes from A to C and their route values are as follows:
ABC = 0.85 x 0.67 = 0.57
AEC = 0.77 x 0.95 = 0.73
ABEC = 0.85 x 0.94 x 0.95 = 0.76
ADEC = 0.93 x 0.82 x 0.95 = 0.72
ADBC = 0.93 x 0.48 x 0.67 = 0.30
The way in which route values are calculated is at the heart of Duane's original concept. This is what I have used to calculate the route values above. I think it works because trust diminishes between the first and last members in the system as the route grows longer (as we multiply the numbers along the route, we are taking fractions of fractions). This happens in real life too. You might be able to trust a friend of a friend, but would you place as much trust in a friend of a friend of a friend?
Dave
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I would have thought the best route to chose would be the one which includes nodes that the originator has the highest trust in.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Suppose X is an outsider, and asks A how much trust he has in C, then X would want to know the worst case too.
amo crafts wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This would cause problems when the originator has no trust in one or more nodes on the route. Three methods to cope with such a situation would be:
1. the value is given a pre-defined trust value, 0.4 for example;
2. the node is ignored and removed from the calculation, with a caveat supplied in the results; or
3. the whole route is removed from the results, which gives users more reason to enter more trusted members (and more honest values).
Note those calculations would be for determing which route to chose and would have no effect on the route value.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I think option 1 would be the best because just as nobody is perfect (i.e. deserving of 100% trust), everybody can be trusted to some degree. An assumption similar to 0.10 sounds reasonable to me at the moment because the route ADBC (see below) has route value 0.30 resulting from a perfectly reasonable collection of node values.
amo crafts wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
So, in the example given:
1. route A->B->C has a trusted route value of 0.85;
2. route A->E->C has a trusted route value of 0.77; and
3. route A->B->E->C has a trusted route value of AVG(0.85, 0.77) = 0.81
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
All the possible routes from A to C and their route values are as follows:
ABC = 0.85 x 0.67 = 0.57
AEC = 0.77 x 0.95 = 0.73
ABEC = 0.85 x 0.94 x 0.95 = 0.76
ADEC = 0.93 x 0.82 x 0.95 = 0.72
ADBC = 0.93 x 0.48 x 0.67 = 0.30
The way in which route values are calculated is at the heart of Duane's original concept. This is what I have used to calculate the route values above. I think it works because trust diminishes between the first and last members in the system as the route grows longer (as we multiply the numbers along the route, we are taking fractions of fractions). This happens in real life too. You might be able to trust a friend of a friend, but would you place as much trust in a friend of a friend of a friend?
Dave
Upvote
0
- Original Poster
- #47
Dave Mortimer said:
outsiders (meaning those that haven't given a trust level to another member/node) can't trust anyone in the system anything other than neutrally (woudl neutral be 0% or 50% based on an earlier comment that everyone should be half trusted to begin with).
as an outsider the system would be of no value to you until you have dealt with someone and stated how much you trust them. From this level of trust you can then establish how much they trust others when going via the node to which they have assigned their own trust level.
You shouldn't be worry about a general level of trust for any node. All trust levels are totally subjective.
Upvote
0
A
amo crafts
Essentially the trusted route is the same as saying "I trust X's opinion over Y's." Outside of algorithms, in the real world though we trust X's opinion more, Y's difference in trust would affect us to a certain degree. In effect Y's trust is acting as a weight, but in my opinion should not be used in an averaging. So rather than AVG( Xtv, Ytv ) we use a weight algorithm to adjust Xtv up or down with Ytv. (tv = trust value). The weighting may make more of an impact when Xtv is being decreased than it is when being increased.
0.4 was just an example value for an outsiders trust value, it could of course be configurable by each user. I would agree that it should be lower than 0.5, but I'm a cynic! Now assuming we don't allow configurable outsider trust values, 1.0 is definetly a no go IMO --- the value should decrease as the route is traversed as you have already proposed. I'm unlikely to lend a tenner to a friend of a friend I had just met, and absolutely not going to lend a tenner to a friend of a friend.
The calculations I wrote were examples of the route trust value I was proposing for the examples you had written. I agree with the method you had proposed, but those calculations I wrote were a precursor. I was proposing that not only do you need to know how much you feel you can trust someone, you need to know who's opinion of that person you can trust more.
Now, just throwing thoughts up into the air and seeing were they land, would it be beneficial to be able to calculate alternate routes? Can't think of the right term right now. Essentially, if a route takes a more than average number of hops (say thirty) but can be reduced to very few hops (say three) by introducing an outsider, then can that route be more trusted? If not, is it legitimate enough to display to the user? Or just used when no other route can be found without outsiders?
0.4 was just an example value for an outsiders trust value, it could of course be configurable by each user. I would agree that it should be lower than 0.5, but I'm a cynic! Now assuming we don't allow configurable outsider trust values, 1.0 is definetly a no go IMO --- the value should decrease as the route is traversed as you have already proposed. I'm unlikely to lend a tenner to a friend of a friend I had just met, and absolutely not going to lend a tenner to a friend of a friend.
The calculations I wrote were examples of the route trust value I was proposing for the examples you had written. I agree with the method you had proposed, but those calculations I wrote were a precursor. I was proposing that not only do you need to know how much you feel you can trust someone, you need to know who's opinion of that person you can trust more.
Now, just throwing thoughts up into the air and seeing were they land, would it be beneficial to be able to calculate alternate routes? Can't think of the right term right now. Essentially, if a route takes a more than average number of hops (say thirty) but can be reduced to very few hops (say three) by introducing an outsider, then can that route be more trusted? If not, is it legitimate enough to display to the user? Or just used when no other route can be found without outsiders?
Upvote
0
A
amo crafts
Hmmm, when I said "outsider" in the post above and with regards to the idea being tossed up (i.e. final paragraph), I was referring to an outsider to the total route, not just the originator. Essentially it's glueing two route strands together.
Sorry if the post wasn't clear, just had a heated debate about foreign policies which I feel passionate about! No guarentee I could have made it clearer otherwise though.
Sorry if the post wasn't clear, just had a heated debate about foreign policies which I feel passionate about! No guarentee I could have made it clearer otherwise though.
Upvote
0
A
amo crafts
Ho-k, stop me when you want me to stop! Another thought just occurred to me though.
If I were to meet a person who I knew to be trusted by fifty people with their lives, I'd consider that person to be quite trustworthy. Perhaps not as trustworthy as those fifty people, but trustworthy nevertheless.
On the other hand, at the other end of the extreme, if I were to meet someone who fifty people had told me had ripped them off and run away with their loved ones, I'd not trust him/her at all.
This can be applied to the algorithm of course, most obviously to outsiders. Rather than attributing each person with a fixed value the above rationality can be taken and applied in an algorithm. The resulting trust value can then be modified if necessary, either by a fixed/configurable value, or by following further routes. This can also be applied to people unknown to the originator. If A wants to know Gtv, should he/she trust B's opinion of 0.90 if C, D, E & F have all applied a tv of 0.1 (regardless of A's tv of B)?
Okay, I don't know how complicated you want this to be, though so far it's all fairly simple repetition with simple AI thrown in for path traversal (which you'll need anyway). No idea how much procesing power you want this tool to take either. However, it's better to throw ideas in the air for them to be rejected, than keep them to myself.
If I were to meet a person who I knew to be trusted by fifty people with their lives, I'd consider that person to be quite trustworthy. Perhaps not as trustworthy as those fifty people, but trustworthy nevertheless.
On the other hand, at the other end of the extreme, if I were to meet someone who fifty people had told me had ripped them off and run away with their loved ones, I'd not trust him/her at all.
This can be applied to the algorithm of course, most obviously to outsiders. Rather than attributing each person with a fixed value the above rationality can be taken and applied in an algorithm. The resulting trust value can then be modified if necessary, either by a fixed/configurable value, or by following further routes. This can also be applied to people unknown to the originator. If A wants to know Gtv, should he/she trust B's opinion of 0.90 if C, D, E & F have all applied a tv of 0.1 (regardless of A's tv of B)?
Okay, I don't know how complicated you want this to be, though so far it's all fairly simple repetition with simple AI thrown in for path traversal (which you'll need anyway). No idea how much procesing power you want this tool to take either. However, it's better to throw ideas in the air for them to be rejected, than keep them to myself.
Upvote
0
- Original Poster
- #51
amo crafts said:
Yes, but only if you trust those 50 people yourself. If they're just 50 random people then it should mean nothing to you (it could be fake people (ie: multiple accounts) or it could be rigged (collaboration to cheat the system))
Isn't that covered by my original proposal?
Upvote
0
A
amo crafts
True, but without modification I'd feel the system would still be viable for a lack of trust. I understood (perhaps wrongly) though that only selected people be able to enter trust; be that by manual selection, member election, number of posts and/or so on. I had mentioned also (in not so many words) that further routes could be followed to verify trust of those people (where you can ensure none of those members influence the trust of eachother).
I don't think it was mentioned originally. Let's say that a route needs checking to see how much the route can be trusted. A wants to check the trustworthiness of E, and the route can be traced A->B->C->D->E. The trust values are (with A's trust in B being traced horizontally from A, vertically from B):
... [A] [C] [D] [E]
[A] --- 001 --- --- ---
--- --- 001 --- ---
[C] --- --- --- 001 ---
[D] --- --- 0.1 --- ---
[E] --- --- 0.1 --- 001
Obviously I've kept the values simple to keep it easier.
Without verifying the route and trustworthiness, A can trust E with a value of 1 --- as good as it gets. However, B's trust in C seems incorrect. Perhaps B was lucky, is too optimistic/trusting, is a dupe id of C and so on. By taking into account the trust that D & E have in C the result would be substantially reduced.
Okay, in case you're thinking this wouldn't occur if we traced all routes and took an average:
... [A] [C] [D] [E]
[A] --- 001 0.1 --- ---
--- --- --- --- 001
[C] --- --- --- --- 0.1
By taking the average of all routes rather than selecting the best route, the trust that A can put in E is dropped from 1 to 0.505. Should someone that A has almost no trust in whatsoever (B) have such a big impact on the trust calculated for A to apply to E?
Forgive me if I'm talking carp. Let me know and I'll go away in a huff, perhaps cry a little, then come back tomorrow bleary eyed but smiling! But I'm happy to keep making suggestions if you want them, and if you'd like more description/diagrams let me know.
I don't think it was mentioned originally. Let's say that a route needs checking to see how much the route can be trusted. A wants to check the trustworthiness of E, and the route can be traced A->B->C->D->E. The trust values are (with A's trust in B being traced horizontally from A, vertically from B):
... [A] [C] [D] [E]
[A] --- 001 --- --- ---
--- --- 001 --- ---
[C] --- --- --- 001 ---
[D] --- --- 0.1 --- ---
[E] --- --- 0.1 --- 001
Obviously I've kept the values simple to keep it easier.
Without verifying the route and trustworthiness, A can trust E with a value of 1 --- as good as it gets. However, B's trust in C seems incorrect. Perhaps B was lucky, is too optimistic/trusting, is a dupe id of C and so on. By taking into account the trust that D & E have in C the result would be substantially reduced.
Okay, in case you're thinking this wouldn't occur if we traced all routes and took an average:
... [A] [C] [D] [E]
[A] --- 001 0.1 --- ---
--- --- --- --- 001
[C] --- --- --- --- 0.1
By taking the average of all routes rather than selecting the best route, the trust that A can put in E is dropped from 1 to 0.505. Should someone that A has almost no trust in whatsoever (B) have such a big impact on the trust calculated for A to apply to E?
Forgive me if I'm talking carp. Let me know and I'll go away in a huff, perhaps cry a little, then come back tomorrow bleary eyed but smiling!
But I'm happy to keep making suggestions if you want them, and if you'd like more description/diagrams let me know.
Upvote
0
I skimmed through all the complicated stuff on this thread (head hurts) but I think this is a fantastic idea. It is quite simply bringing a process used subconsiously for thousands of years into the technology age. Referral based business, and it happens every day. You ask people you trust for the number of a plumber they trust, and so on.
My gut says that this idea would take off and be widely used, and revenue could be earned from the traffic the site would generate. Duane, contact Crossguard and get this idea patented quick Even if you dont do it yourself you could still make money from the idea. Hell if I had time I would do it, it would make a great bolt on to UKBF
My gut says that this idea would take off and be widely used, and revenue could be earned from the traffic the site would generate. Duane, contact Crossguard and get this idea patented quick
Even if you dont do it yourself you could still make money from the idea. Hell if I had time I would do it, it would make a great bolt on to UKBF
Upvote
0
- Original Poster
- #59
I think as Coling says, already in the public domain now, so I couldn't patent it.
I've no problem is you want to do something with it to integrate with UKBF Ozzy. I can post in a year or two and have a whinge in the "Ideas you had but did nothing with" thread" when someone makes the milions : )
Amo - I'm not sure I understand what the issue is. Can you explain further? If it was implemented on the forums and I only put in that I trust Ozzy and no one else - then any trust ratings I see from others will be based on my level of trust for Ozzy and then OZzys level of trust for others. I don't see how it can be abused?
I've no problem is you want to do something with it to integrate with UKBF Ozzy. I can post in a year or two and have a whinge in the "Ideas you had but did nothing with" thread" when someone makes the milions : )
Amo - I'm not sure I understand what the issue is. Can you explain further? If it was implemented on the forums and I only put in that I trust Ozzy and no one else - then any trust ratings I see from others will be based on my level of trust for Ozzy and then OZzys level of trust for others. I don't see how it can be abused?
Upvote
0
A
amo crafts
Abuse is more of an issue when people have used fake id's to increase their trust rating which I've suggested a solution for already, but a potential problem in your example is when Ozzy is wrong to trust someone.
Let's say I rip everyone off, a few dodgy dealings before disappearing and popping up elsewhere on the net. For the sake of argument, I come here and see that Ozzy has a lot of clout and people place a lot of trust in him. I can provide a fantastic service to Ozzy, he takes up my offer and I provide that fantastic service fantastically. Over time he trusts me more and more, increasing my rating all the time.
One day you decide the time has come for you to muscle in on Ozzy's sector, and looking for the same service you look to see if you can trust me. You trust Ozzy without a shadow of a doubt and he trusts me, so you get in touch.
Having been around for a while I know you don't have any clout in these parts (don't take it personally, it's only make believe!). I know that most people trust Ozzy over yourself so I couldn't give a doodle what you think of me. I rip you off big time, take your cash and laugh all the way to my bank account homepage. That's the umpteenth time I conned money out of people, and all I had to do was gain the trust of Ozzy.
By checking the validity of routes this problem can be plugged, but it's not so simple as averaging as that would bring it's own problems. Besides, in the example you gave averaging wouldn't make any difference at all (only one route). It doesn't take someone to be so scrupulous either, Ozzy may have been plain lucky or just too trusting.
The solution would be to check how much third parties trust any person you do not know, which requires several routes being traced backwards to different people. To prevent an obvious hole there those third parties should be verified, and they must not verify eachother in any way. Obviously the further back those routes go the more processing required, but the more trusted the results. An absolute minimum length of each back traced route is two hops.
So following on from the example, you've decided you can do a better job than Ozzy and now looking for a supplier and seeing how much you can trust me. Ozzy trusts me 90%, but by this time I've ripped off Creospace, Cjd and others. They don't trust me at all. I did a right proper job of taking their money and they trust me 10%. The system verifies it's routes and because you don't know me, it verifies me. Straightaway it sees that I cannot be trusted and the trust value of the route plummets. At this point, it's entirely up to the system to ignore the route, or display the result with a caveat basically saying "Do not trust." (Note: If I were only an intermediate on the route and you trusted more people than only Ozzy, all routes would be checked and the one with the highest trust value of the route would be returned.)
And to take the example further, I've forseen this feature and have placed several users into the system to verify myself. Because those users are not verified though the system does not take them into account when verifying the route. I could also forsee this, but the wider you throw the net (i.e. the number of hops in each back traced routes) the more users I would need to create, and being exponential it wouldn't take long to be too many fake users required to be not worth the time. Of course, each hop addition to the back traced routes/net would also increase the processing time required exponentially.
There's a few different issues I've outlined already which came uninvited into my head while watching telly, I'm sure there would be more if I did some brainstorming. I just want to highlight that unless thought about carefully it can place too much or too little trust in another person.
Let's say I rip everyone off, a few dodgy dealings before disappearing and popping up elsewhere on the net. For the sake of argument, I come here and see that Ozzy has a lot of clout and people place a lot of trust in him. I can provide a fantastic service to Ozzy, he takes up my offer and I provide that fantastic service fantastically. Over time he trusts me more and more, increasing my rating all the time.
One day you decide the time has come for you to muscle in on Ozzy's sector, and looking for the same service you look to see if you can trust me. You trust Ozzy without a shadow of a doubt and he trusts me, so you get in touch.
Having been around for a while I know you don't have any clout in these parts (don't take it personally, it's only make believe!). I know that most people trust Ozzy over yourself so I couldn't give a doodle what you think of me. I rip you off big time, take your cash and laugh all the way to my bank account homepage. That's the umpteenth time I conned money out of people, and all I had to do was gain the trust of Ozzy.
By checking the validity of routes this problem can be plugged, but it's not so simple as averaging as that would bring it's own problems. Besides, in the example you gave averaging wouldn't make any difference at all (only one route). It doesn't take someone to be so scrupulous either, Ozzy may have been plain lucky or just too trusting.
The solution would be to check how much third parties trust any person you do not know, which requires several routes being traced backwards to different people. To prevent an obvious hole there those third parties should be verified, and they must not verify eachother in any way. Obviously the further back those routes go the more processing required, but the more trusted the results. An absolute minimum length of each back traced route is two hops.
So following on from the example, you've decided you can do a better job than Ozzy and now looking for a supplier and seeing how much you can trust me. Ozzy trusts me 90%, but by this time I've ripped off Creospace, Cjd and others. They don't trust me at all. I did a right proper job of taking their money and they trust me 10%. The system verifies it's routes and because you don't know me, it verifies me. Straightaway it sees that I cannot be trusted and the trust value of the route plummets. At this point, it's entirely up to the system to ignore the route, or display the result with a caveat basically saying "Do not trust." (Note: If I were only an intermediate on the route and you trusted more people than only Ozzy, all routes would be checked and the one with the highest trust value of the route would be returned.)
And to take the example further, I've forseen this feature and have placed several users into the system to verify myself. Because those users are not verified though the system does not take them into account when verifying the route. I could also forsee this, but the wider you throw the net (i.e. the number of hops in each back traced routes) the more users I would need to create, and being exponential it wouldn't take long to be too many fake users required to be not worth the time. Of course, each hop addition to the back traced routes/net would also increase the processing time required exponentially.
There's a few different issues I've outlined already which came uninvited into my head while watching telly, I'm sure there would be more if I did some brainstorming. I just want to highlight that unless thought about carefully it can place too much or too little trust in another person.
Upvote
0
- Original Poster
- #62
I understand now. I'm sure it could be sorted rather simply though.
Firstly - I wouldn't expect the system to always show me the most trusted route to a end user. This is too optimistic. If I have various routes to the end user then some form of avg should be calulated - with different weightings on each route dependent on my trust of the next node and the number of hops involved.
Some sort of warning mechanism should be built in if an end-user has more than x number of 'distrust' links into him. x could be determined by the starting node, ie - me, on a per user basis.
Also, you have to bear in mind that people talk. If Ozzy heard about your antics from others then he'd manually adjust his trust level in you.
Firstly - I wouldn't expect the system to always show me the most trusted route to a end user. This is too optimistic. If I have various routes to the end user then some form of avg should be calulated - with different weightings on each route dependent on my trust of the next node and the number of hops involved.
Some sort of warning mechanism should be built in if an end-user has more than x number of 'distrust' links into him. x could be determined by the starting node, ie - me, on a per user basis.
Also, you have to bear in mind that people talk. If Ozzy heard about your antics from others then he'd manually adjust his trust level in you.
Upvote
0
A
amo crafts
By the system's nature each route would only have one known (trusted/distrusted) node, i.e. the first one. The system would be ignorant (and random) to choose the route A->B->C->D->E->F->G when A knows E (B, C and D are redundant). Therefore it's impossible to weight by the number of distrusted nodes on a route.
Taking an average is also flawed. If you trust Ozzy 100%, and only trust myself 10%, and want to know how much you can trust Creospace. If both Ozzy and I have trust with Creospace then by taking an average the final result is heavily influenced by someone (i.e. me) you don't trust. This is further excacberated the more my trust toward Creospace differs to Ozzy's. If another person you do not trust has trust with Creospace then the results are even more useless. They get more and more useless to you the more distrusted people you have, were it would be most useful for you to have no distrusted people, which in turn has a negative impact on the system as a whole.
There are workarounds to this by ignoring certain nodes (and hence routes in the secondary) but this would soon get messy and doesn't reflect the real world. I don't believe it's optimistic for the system to select the best route, the solution I've already suggested would quite literally take just a few lines of code (by reusing path finding logic which would already be required). The important thing in my opinion is to spot those holes and plug them.
Personally I don't like systems which rely upon ad hoc human nature (i.e. talk). It's a fair cop for belts and braces, but when the system is to help determine trust in others it becomes all the more important that the system itself can be trusted.
Taking an average is also flawed. If you trust Ozzy 100%, and only trust myself 10%, and want to know how much you can trust Creospace. If both Ozzy and I have trust with Creospace then by taking an average the final result is heavily influenced by someone (i.e. me) you don't trust. This is further excacberated the more my trust toward Creospace differs to Ozzy's. If another person you do not trust has trust with Creospace then the results are even more useless. They get more and more useless to you the more distrusted people you have, were it would be most useful for you to have no distrusted people, which in turn has a negative impact on the system as a whole.
There are workarounds to this by ignoring certain nodes (and hence routes in the secondary) but this would soon get messy and doesn't reflect the real world. I don't believe it's optimistic for the system to select the best route, the solution I've already suggested would quite literally take just a few lines of code (by reusing path finding logic which would already be required). The important thing in my opinion is to spot those holes and plug them.
Personally I don't like systems which rely upon ad hoc human nature (i.e. talk). It's a fair cop for belts and braces, but when the system is to help determine trust in others it becomes all the more important that the system itself can be trusted.
Upvote
0
- Original Poster
- #64
amo crafts said:
I wouldn't expect the system to include long paths to creospace that pass through a node already used to calculate a previous path.
I'm sure there are lots of little things like this that need to be worked out and catered for. And I agree the system itself needs to be trustworthy.
If it was a simple undertaking to get something like this up and running and working how I want it to then I'd taking on the project myself. But becuase of the complexities that I knew from the outset would be involved I'm not going to be doing anything with this idea myself in the immediate future.
Upvote
0
A
amo crafts
Hmmm, I was talkimg about two separate routes (you->Ozzy->Creospace and you->me->Creospace) and why not to take the average of those results. Anyway, sounds like that's by the by for the moment.
I agree, no doubt there will be lot's of little things which would need catered for. The only reason I brought up the ones I did was because it was commented upon a few pages ago (can't remember who/where) whether a route average would be an adequate solution.
I agree, no doubt there will be lot's of little things which would need catered for. The only reason I brought up the ones I did was because it was commented upon a few pages ago (can't remember who/where) whether a route average would be an adequate solution.
Upvote
0
M
Mortime Business Software
Hello trusters and trustees.
I've been away to the lakes for a few days with my brother. I arrived home about two hours ago and have just skimmed over the additions to this thread since I last looked in. At the moment I have about 2/3 of a bottle of wine in me, so I will read again tomorrow morning and post the work I did on the "trust-web" idea while I was away. I still think it is a good idea. I spent about 11 hours on it yesterday (plus a few hours over the preceding days), and I am very apprehensive about what you may have to say about my work. (I'm not as bullet-proof as some of you might think!)
I think it should be understood that an abstract idea such as this is never going to be perfect. But neither is the Intelligence Quotient. In fact the IQ of a person is notoriously questionable because there are so many different forms of intelligence. Likewise, the "Trust Quotient" should not be regarded as a general indication of a person's or a company's reputation. It should be understood that it is a scheme for internet business first and formost. If others want to try and apply the idea to real people in everyday life, then they may have a problem, and we should not let them blame us if it does not work for them.
I will read from page 5 of this thread tomorrow morning to see if anyone has already punched any holes in my system, then I will post my work. (The system itself is mathematically and programatically sound; I just want to see if anyone has mentioned anything which dents the underlying concepts and justifications on which the maths is based).
I have tried to improve the "how it works" aspects of the article for you Duane, but there is some stuff which requires some A-level maths. However, this can be skipped if you trust me, and the rest of the maths is pretty simple, but there are a few calculations involved. It may seem complicated on a first reading, but trust me, after the second or third you should get it.
I have not altered Duane's simple, but very elegant, idea in any way. I think this is the reason why it works so well - because it is simple. My implementation is also simple if you read it thoroughly and ask me to clarify anything which you do not understand (probably because I have not explained it adequately).
Right - finish bottle - go to bed - night-night!
Dave
I've been away to the lakes for a few days with my brother. I arrived home about two hours ago and have just skimmed over the additions to this thread since I last looked in. At the moment I have about 2/3 of a bottle of wine in me, so I will read again tomorrow morning and post the work I did on the "trust-web" idea while I was away. I still think it is a good idea. I spent about 11 hours on it yesterday (plus a few hours over the preceding days), and I am very apprehensive about what you may have to say about my work. (I'm not as bullet-proof as some of you might think!)
I think it should be understood that an abstract idea such as this is never going to be perfect. But neither is the Intelligence Quotient. In fact the IQ of a person is notoriously questionable because there are so many different forms of intelligence. Likewise, the "Trust Quotient" should not be regarded as a general indication of a person's or a company's reputation. It should be understood that it is a scheme for internet business first and formost. If others want to try and apply the idea to real people in everyday life, then they may have a problem, and we should not let them blame us if it does not work for them.
I will read from page 5 of this thread tomorrow morning to see if anyone has already punched any holes in my system, then I will post my work. (The system itself is mathematically and programatically sound; I just want to see if anyone has mentioned anything which dents the underlying concepts and justifications on which the maths is based).
I have tried to improve the "how it works" aspects of the article for you Duane, but there is some stuff which requires some A-level maths. However, this can be skipped if you trust me, and the rest of the maths is pretty simple, but there are a few calculations involved. It may seem complicated on a first reading, but trust me, after the second or third you should get it.
I have not altered Duane's simple, but very elegant, idea in any way. I think this is the reason why it works so well - because it is simple. My implementation is also simple if you read it thoroughly and ask me to clarify anything which you do not understand (probably because I have not explained it adequately).
Right - finish bottle - go to bed - night-night!
Dave
Upvote
0
M
Mortime Business Software
I'm going to have to post this in sections because this forum program will not accept such a long message. Please do not post anything until after you see section 5 appear.
1 Overview of technical aspects
Here is an updated diagram of an example of a trust-web.
You do not have to read the notes in square brackets [...].
There may be some slip-ups in the arithmetic. If you spot any, then please PM me with them and I will post an erratta sheet. If you find any slip-ups in the modelling (which is naturally subjective), then please post your arguments in this thread so that we can discuss them.
My diagram is drawn according to Table 1 (below) which lists all the outgoing arrows for each member (refer to Table 1 and the diagram). Table 1 is a kind of "grammar" for the system because we can trace all the existing routes throughout the system, (we can even produce the diagram from Table 1).
[In fact, from Table 1, we can trace all possible routes throughout the system, but you don't need to know about that.] For example, the first row of Table 1 shows that:
A trusts B by 0.85
A trusts D by 0.93
A trusts E by 0.77
Table 1. Outgoing arrows from each member.
----------------------------------
A ---> { B|0.85, D|0.93, E|0.77 }
B ---> { C|0.67, E|0.94 }
C ---> { B|0.88, D|0.39 }
D ---> { B|0.48, A|0.59, E|0.82 }
E ---> { B|0.75, C|0.95, D|0.51 }
----------------------------------
[This grammar needs some rules if it is to be used in the "trust" system, but they are not required yet.]
[Each member name in any particular right-hand-side collection in Table 1 is unique to that collection. Therefore the collections are true sets.]
[Table 1 will also help later when we want to program the system because it is a kind of linked list.]
(Refer to the diagram now). In my opinion, it is not sufficient to average the trust values around a member's node in an attempt to estimate the "trust" that the member receives. Doing this would ignore the trust that the member receives from indirect sources. For example, C has 0.67 of trust from B, and 0.95 of trust from E. But members A and D also trust C via indirect routes.
I think this indirect trust should be considered and calculated in with the direct trust values because, for example,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
if we can answer the question of how much A trusts C, then it follows that C is receiving trust from A, and this trust should be accounted for.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The amount of trust that the entire system, as a whole, places in a member is called the "Trust Ratio" for that member. You could also call it the "Trust Quotient", or the "TQ" of a member, if you really want to, which would mean that a member has a "TQ" just as he has an "IQ". Well, why not? A person's Intelligence Quotient is notoriously questionable and difficult to measure because there are so many different forms of intelligence. For example, how would Wayne Rooney, an obvious genius who is an outstandingly intelligent footballer, perform on a quiz such as University Challenge?
If scientists can assert that we each have an IQ, then we can certainly assert that a person can have a TQ.
1 Overview of technical aspects
Here is an updated diagram of an example of a trust-web.
You do not have to read the notes in square brackets [...].
There may be some slip-ups in the arithmetic. If you spot any, then please PM me with them and I will post an erratta sheet. If you find any slip-ups in the modelling (which is naturally subjective), then please post your arguments in this thread so that we can discuss them.
My diagram is drawn according to Table 1 (below) which lists all the outgoing arrows for each member (refer to Table 1 and the diagram). Table 1 is a kind of "grammar" for the system because we can trace all the existing routes throughout the system, (we can even produce the diagram from Table 1).
[In fact, from Table 1, we can trace all possible routes throughout the system, but you don't need to know about that.] For example, the first row of Table 1 shows that:
A trusts B by 0.85
A trusts D by 0.93
A trusts E by 0.77
Table 1. Outgoing arrows from each member.
----------------------------------
A ---> { B|0.85, D|0.93, E|0.77 }
B ---> { C|0.67, E|0.94 }
C ---> { B|0.88, D|0.39 }
D ---> { B|0.48, A|0.59, E|0.82 }
E ---> { B|0.75, C|0.95, D|0.51 }
----------------------------------
[This grammar needs some rules if it is to be used in the "trust" system, but they are not required yet.]
[Each member name in any particular right-hand-side collection in Table 1 is unique to that collection. Therefore the collections are true sets.]
[Table 1 will also help later when we want to program the system because it is a kind of linked list.]
(Refer to the diagram now). In my opinion, it is not sufficient to average the trust values around a member's node in an attempt to estimate the "trust" that the member receives. Doing this would ignore the trust that the member receives from indirect sources. For example, C has 0.67 of trust from B, and 0.95 of trust from E. But members A and D also trust C via indirect routes.
I think this indirect trust should be considered and calculated in with the direct trust values because, for example,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
if we can answer the question of how much A trusts C, then it follows that C is receiving trust from A, and this trust should be accounted for.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The amount of trust that the entire system, as a whole, places in a member is called the "Trust Ratio" for that member. You could also call it the "Trust Quotient", or the "TQ" of a member, if you really want to, which would mean that a member has a "TQ" just as he has an "IQ". Well, why not? A person's Intelligence Quotient is notoriously questionable and difficult to measure because there are so many different forms of intelligence. For example, how would Wayne Rooney, an obvious genius who is an outstandingly intelligent footballer, perform on a quiz such as University Challenge?
If scientists can assert that we each have an IQ, then we can certainly assert that a person can have a TQ.
Upvote
0
M
Mortime Business Software
2 Calculating how much one member trusts another member
We start by using Duane's fundamental "diminishing trust" concept to calculate, for example, how much trust A has in C (refer to the diagram). Tracing through the diagram we find there are nine possible routes from A to C:
Table 2. Routes from A to C
-----------------------------------------
(1) A -> B|0.85 -> C|0.67
(2) A -> B|0.85 -> E|0.94 -> C|0.95
(3) A -> D|0.93 -> B|0.48 -> C|0.67
(4) A -> D|0.93 -> B|0.48 -> E|0.94 -> C|0.95
(5) A -> D|0.93 -> E|0.82 -> B|0.75 -> C|0.67
(6) A -> D|0.93 -> E|0.82 -> C|0.95
(7) A -> E|0.77 -> B|0.75 -> C|0.67
(8) A -> E|0.77 -> C|0.95
(9) A -> E|0.77 -> D|0.51 -> B|0.48 -> C|0.67
-----------------------------------------
Each row represents a route, and each arrow within a route represents a "hop" in a route (compare Table 2 with the diagram). In Table 2 the nodes in a particular route are labelled with the member name and the trust value that the preceding member has assigned to that member. These two values are separated by a pipe, ( | ).
Now for each route, multiply together the numbers at the arrow heads. So, for example, the following route (row 2 in Table 2):
A -> B|0.85 -> E|0.94 -> C|0.95
gives a value of:
0.85 x 0.94 x 0.95 = 0.76
This is called the route value [amo crafts coined this term] of a particular route which began at A with destination C. There are a number of routes from A to C; we say that the "relation" AC has a collection of route values. Working through the other routes for the relation AC in the same way, we find that there are nine possible routes for AC (refer to the diagram and trace through all nine routes to convince yourself). Thus, after calculating in the way described above, we find that AC has nine route values:
Table 3. Route values for AC
--------------------
(1) 0.57 over 2 hops
(2) 0.76 over 3 hops
(3) 0.30 over 3 hops
(4) 0.40 over 4 hops
(5) 0.38 over 4 hops
(6) 0.72 over 3 hops
(7) 0.39 over 3 hops
(8) 0.73 over 2 hops
(9) 0.13 over 4 hops
--------------------
Table 3 represents all the "trust" that C receives from A. Later we will think about all the trust that C receives from B, D and E. Then, later, we must think about the trust that every member in the system receives from all the other members.
Note that each time we multiply the numbers along a route, we are taking a fraction of a fraction. Therefore, for any particular route, successive route values within the route get smaller and smaller as we approach the final hop. That is, as the "hop order" of a route increases, (i.e. from 1-hop to 2-hop to 3-hop and so on), the value of the product (the result of each multiplication) tends to zero.
From AC's route values in Table 3, it would seem that route value (8) is just about as good as route value (6), because they differ by only 0.01. But (8) was done over two hops whereas (6) was done over three hops, so intuition alone here seems to suggest that (6) is significantly better than (8). But intuition, although essential for forming conjectures, is not enough to build systems on. We need to prove it.
We must find a way to combine a member's route values into some value which indicates how much A can trust C. We have to be careful because we know that a particular route value will always decrease towards zero if it was to undergo further hops. (This means that a general curve for AC will approach 0 all the time, but will never reach it unless there is a 0.00 trust value on the route). Therefore the "rate" (i.e. the gradient of the line between two hop points) at which a trust value falls from one hop to the next generally gets smaller and smaller (proabably with some exceptions) as the hop size increases, and a curve for these rates will eventually approximate to a straight line which is approximately parallel to the x-axis.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Two routes of different hop order with the same nominal trust value are not equal.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For example, a trust value t1 with a nominal trust value of 0.74 over 3 hops, is better than another trust value t2 with the same nominal trust value of 0.74 over 2 hops. This is because if t2 were to undergo a further hop and become a 3-hop type, it would have to decrease below 0.74 (because we take a fraction of a fraction) (providing of course that this further trust level is not 1, which should not be allowed because perfection implies God status).
The argument in the previous paragraph can be taken as a proof by example, and should serve to explain why we have to type routes by different numbers of hops.
It follows that it is highly likely, in a large enough system, that an average hop line on a graph (a line joining two nodes) will have a smaller gradient than its preceding hop line.
It should be noted that, in my opinion, a 4-hop value implicitly contains a 3-hop value, a 2-hop value and a 1-hop value. Likewise a 3-hop value will contain a 2-hop value and a 1-hop value (I have taken hop values in this way reasoning that the resulting averages will be tighter. However, this is intuitive at the moment, and could very well turn out to be an unacceptable source of error. If you feel uncomfortable with it, just use the seperate values. My reason for doing it this way is because there are only a few members in the system, and the number of possible routes between them is small).
So from Table 2 above, we can see that the relation AC has:
three 4-hop values,
seven 3-hop values,
nine 2-hop values,
nine 1-hop values.
Therefore, in the above data for AC in Table 3, there are four types of data; 1-hop, 2-hop, 3-hop and 4-hop. If we try to compare or rank values of these different data types, it would be like trying to compare apples with oranges (because of the reasons given in the preceding paragraphs). Also, the number of route values will vary for different members, and they will have different combinations and different numbers of instances of the different hop types. All this would make comparison of members virtually meaningless.
You should now appreciate that there are different "types" of trust that a member can receive. There are 1-hop types, 2-hop types, 3-hop types, etc., and these different types cannot yet be compared.
But what we can compare are values of the same hop type. This means we can take the average of a collection of values if they are of the same hop type.
The 1-hop values for AC are:
0.85
0.93
0.77
The average of these is: 0.85.
[This may represent another wrinkle in my reasoning. By my earlier reasoning there are nine 1-hop values, but here I have formed a set from them so that there are three unique 1-hop values for AC. Why should we not calculate all nine? This does not matter for now. The overall calculation logic is unaffected.]
The 2-hop values for AC are:
0.85 x 0.67 = 0.57
0.85 x 0.94 = 0.80
0.93 x 0.48 = 0.45
0.93 x 0.82 = 0.76
0.77 x 0.75 = 0.58
0.77 x 0.95 = 0.73
0.77 x 0.51 = 0.39
The average of these is: 0.61
[Again I have formed a set of the 2-hop values.]
The 3-hop values for AC are:
0.85 x 0.94 x 0.95 = 0.76
0.93 x 0.48 x 0.67 = 0.30
0.93 x 0.48 x 0.94 = 0.42
0.93 x 0.82 x 0.75 = 0.57
0.93 x 0.82 x 0.95 = 0.72
0.77 x 0.75 x 0.67 = 0.39
0.77 x 0.51 x 0.48 = 0.19
The average of these is: 0.48
The 4-hop values for AC are:
0.93 x 0.48 x 0.94 x 0.95 = 0.40
0.93 x 0.82 x 0.75 x 0.67 = 0.38
0.77 x 0.51 x 0.48 x 0.67 = 0.13
The average of these is: 0.30
The averages above are called the "type averages" for the relation AC. The summary for AC is:
Table 4. Type averages for AC
------+-------+-------+------
1-hop | 2-hop | 3-hop | 4-hop
------+-------+-------+------
0.85 | 0.61 | 0.48 | 0.30
------+-------+-------+------
Now we must find the other routes from the other members to C, and, using the same method as above, tabulate the type averages for the relations BC, DC, EC:
Table 5. Type averages for BC
------+------
1-hop | 2-hop
------+------
0.81 | 0.89
------+------
Table 6. Type averages for DC
------+-------+-------+------
1-hop | 2-hop | 3-hop | 4-hop
------+-------+-------+------
0.63 | 0.51 | 0.40 | 0.34
------+-------+-------+------
Table 7. Type averages for EC
------+-------+-------+------
1-hop | 2-hop | 3-hop | 4-hop
------+-------+-------+------
0.64 | 0.35 | 0.21 | 0.17
------+-------+-------+------
These tables can now be collapsed into one table of type averages for C. That is, take the average of all the 1-hop values, then of all the 2-hop values, and so on. So the type average table for C is:
Table 8. Averages of type averages for C
------+-------+-------+------
1-hop | 2-hop | 3-hop | 4-hop
------+-------+-------+------
0.73 | 0.59 | 0.36 | 0.27
------+-------+-------+------
[At this stage we have enough information to compare the members of the system because these values for each member can be plotted on a graph with a hop-axis and a trust-axis to see the different rates at which the trust level is falling, and a particular member's curve can be compared with those of other members in the system.]
We start by using Duane's fundamental "diminishing trust" concept to calculate, for example, how much trust A has in C (refer to the diagram). Tracing through the diagram we find there are nine possible routes from A to C:
Table 2. Routes from A to C
-----------------------------------------
(1) A -> B|0.85 -> C|0.67
(2) A -> B|0.85 -> E|0.94 -> C|0.95
(3) A -> D|0.93 -> B|0.48 -> C|0.67
(4) A -> D|0.93 -> B|0.48 -> E|0.94 -> C|0.95
(5) A -> D|0.93 -> E|0.82 -> B|0.75 -> C|0.67
(6) A -> D|0.93 -> E|0.82 -> C|0.95
(7) A -> E|0.77 -> B|0.75 -> C|0.67
(8) A -> E|0.77 -> C|0.95
(9) A -> E|0.77 -> D|0.51 -> B|0.48 -> C|0.67
-----------------------------------------
Each row represents a route, and each arrow within a route represents a "hop" in a route (compare Table 2 with the diagram). In Table 2 the nodes in a particular route are labelled with the member name and the trust value that the preceding member has assigned to that member. These two values are separated by a pipe, ( | ).
Now for each route, multiply together the numbers at the arrow heads. So, for example, the following route (row 2 in Table 2):
A -> B|0.85 -> E|0.94 -> C|0.95
gives a value of:
0.85 x 0.94 x 0.95 = 0.76
This is called the route value [amo crafts coined this term] of a particular route which began at A with destination C. There are a number of routes from A to C; we say that the "relation" AC has a collection of route values. Working through the other routes for the relation AC in the same way, we find that there are nine possible routes for AC (refer to the diagram and trace through all nine routes to convince yourself). Thus, after calculating in the way described above, we find that AC has nine route values:
Table 3. Route values for AC
--------------------
(1) 0.57 over 2 hops
(2) 0.76 over 3 hops
(3) 0.30 over 3 hops
(4) 0.40 over 4 hops
(5) 0.38 over 4 hops
(6) 0.72 over 3 hops
(7) 0.39 over 3 hops
(8) 0.73 over 2 hops
(9) 0.13 over 4 hops
--------------------
Table 3 represents all the "trust" that C receives from A. Later we will think about all the trust that C receives from B, D and E. Then, later, we must think about the trust that every member in the system receives from all the other members.
Note that each time we multiply the numbers along a route, we are taking a fraction of a fraction. Therefore, for any particular route, successive route values within the route get smaller and smaller as we approach the final hop. That is, as the "hop order" of a route increases, (i.e. from 1-hop to 2-hop to 3-hop and so on), the value of the product (the result of each multiplication) tends to zero.
From AC's route values in Table 3, it would seem that route value (8) is just about as good as route value (6), because they differ by only 0.01. But (8) was done over two hops whereas (6) was done over three hops, so intuition alone here seems to suggest that (6) is significantly better than (8). But intuition, although essential for forming conjectures, is not enough to build systems on. We need to prove it.
We must find a way to combine a member's route values into some value which indicates how much A can trust C. We have to be careful because we know that a particular route value will always decrease towards zero if it was to undergo further hops. (This means that a general curve for AC will approach 0 all the time, but will never reach it unless there is a 0.00 trust value on the route). Therefore the "rate" (i.e. the gradient of the line between two hop points) at which a trust value falls from one hop to the next generally gets smaller and smaller (proabably with some exceptions) as the hop size increases, and a curve for these rates will eventually approximate to a straight line which is approximately parallel to the x-axis.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Two routes of different hop order with the same nominal trust value are not equal.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For example, a trust value t1 with a nominal trust value of 0.74 over 3 hops, is better than another trust value t2 with the same nominal trust value of 0.74 over 2 hops. This is because if t2 were to undergo a further hop and become a 3-hop type, it would have to decrease below 0.74 (because we take a fraction of a fraction) (providing of course that this further trust level is not 1, which should not be allowed because perfection implies God status).
The argument in the previous paragraph can be taken as a proof by example, and should serve to explain why we have to type routes by different numbers of hops.
It follows that it is highly likely, in a large enough system, that an average hop line on a graph (a line joining two nodes) will have a smaller gradient than its preceding hop line.
It should be noted that, in my opinion, a 4-hop value implicitly contains a 3-hop value, a 2-hop value and a 1-hop value. Likewise a 3-hop value will contain a 2-hop value and a 1-hop value (I have taken hop values in this way reasoning that the resulting averages will be tighter. However, this is intuitive at the moment, and could very well turn out to be an unacceptable source of error. If you feel uncomfortable with it, just use the seperate values. My reason for doing it this way is because there are only a few members in the system, and the number of possible routes between them is small).
So from Table 2 above, we can see that the relation AC has:
three 4-hop values,
seven 3-hop values,
nine 2-hop values,
nine 1-hop values.
Therefore, in the above data for AC in Table 3, there are four types of data; 1-hop, 2-hop, 3-hop and 4-hop. If we try to compare or rank values of these different data types, it would be like trying to compare apples with oranges (because of the reasons given in the preceding paragraphs). Also, the number of route values will vary for different members, and they will have different combinations and different numbers of instances of the different hop types. All this would make comparison of members virtually meaningless.
You should now appreciate that there are different "types" of trust that a member can receive. There are 1-hop types, 2-hop types, 3-hop types, etc., and these different types cannot yet be compared.
But what we can compare are values of the same hop type. This means we can take the average of a collection of values if they are of the same hop type.
The 1-hop values for AC are:
0.85
0.93
0.77
The average of these is: 0.85.
[This may represent another wrinkle in my reasoning. By my earlier reasoning there are nine 1-hop values, but here I have formed a set from them so that there are three unique 1-hop values for AC. Why should we not calculate all nine? This does not matter for now. The overall calculation logic is unaffected.]
The 2-hop values for AC are:
0.85 x 0.67 = 0.57
0.85 x 0.94 = 0.80
0.93 x 0.48 = 0.45
0.93 x 0.82 = 0.76
0.77 x 0.75 = 0.58
0.77 x 0.95 = 0.73
0.77 x 0.51 = 0.39
The average of these is: 0.61
[Again I have formed a set of the 2-hop values.]
The 3-hop values for AC are:
0.85 x 0.94 x 0.95 = 0.76
0.93 x 0.48 x 0.67 = 0.30
0.93 x 0.48 x 0.94 = 0.42
0.93 x 0.82 x 0.75 = 0.57
0.93 x 0.82 x 0.95 = 0.72
0.77 x 0.75 x 0.67 = 0.39
0.77 x 0.51 x 0.48 = 0.19
The average of these is: 0.48
The 4-hop values for AC are:
0.93 x 0.48 x 0.94 x 0.95 = 0.40
0.93 x 0.82 x 0.75 x 0.67 = 0.38
0.77 x 0.51 x 0.48 x 0.67 = 0.13
The average of these is: 0.30
The averages above are called the "type averages" for the relation AC. The summary for AC is:
Table 4. Type averages for AC
------+-------+-------+------
1-hop | 2-hop | 3-hop | 4-hop
------+-------+-------+------
0.85 | 0.61 | 0.48 | 0.30
------+-------+-------+------
Now we must find the other routes from the other members to C, and, using the same method as above, tabulate the type averages for the relations BC, DC, EC:
Table 5. Type averages for BC
------+------
1-hop | 2-hop
------+------
0.81 | 0.89
------+------
Table 6. Type averages for DC
------+-------+-------+------
1-hop | 2-hop | 3-hop | 4-hop
------+-------+-------+------
0.63 | 0.51 | 0.40 | 0.34
------+-------+-------+------
Table 7. Type averages for EC
------+-------+-------+------
1-hop | 2-hop | 3-hop | 4-hop
------+-------+-------+------
0.64 | 0.35 | 0.21 | 0.17
------+-------+-------+------
These tables can now be collapsed into one table of type averages for C. That is, take the average of all the 1-hop values, then of all the 2-hop values, and so on. So the type average table for C is:
Table 8. Averages of type averages for C
------+-------+-------+------
1-hop | 2-hop | 3-hop | 4-hop
------+-------+-------+------
0.73 | 0.59 | 0.36 | 0.27
------+-------+-------+------
[At this stage we have enough information to compare the members of the system because these values for each member can be plotted on a graph with a hop-axis and a trust-axis to see the different rates at which the trust level is falling, and a particular member's curve can be compared with those of other members in the system.]
Upvote
0
M
Mortime Business Software
3 Calculating a member's trust ratio
To find a "trust-ratio" for a particular member, we first take a global average of type averages for each different type. That is, we take all the 1-hop type averages of all the members in the system and calculate a global 1-hop type average. We do the same for all the different hop types, and form a global type average table (similar in principle to the FTSE-100 index):
Table 9. Global type averages
------+-------+-------+-------+-------+-------+----
1-hop | 2-hop | 3-hop | 4-hop | 5-hop | 6-hop | ...
------+-------+-------+-------+-------+-------+----
0.82 | 0.53 | 0.38 | 0.27 | 0.15 | 0.09 | ...
------+-------+-------+-------+-------+-------+----
(This table is just an example. I have not calculated the type averages for A, B, D, E, and so I have not got real global averages. But this does not matter for our purposes).
We can now compare the type averages for a particular member (Table 8) with the corresponding global type averages (Table 9). Here is a comparison of Tables 8 and 9:
------+-------+-------+-------+-------+-------+----
1-hop | 2-hop | 3-hop | 4-hop | 5-hop | 6-hop | ...
------+-------+-------+-------+-------+-------+----
0.82 | 0.53 | 0.38 | 0.27 | 0.15 | 0.09 | ...
------+-------+-------+-------+-------+-------+----
------+-------+-------+------
0.73 | 0.59 | 0.36 | 0.27
------+-------+-------+------
To do this we take ratios which will tell us what proportion the member type average is of the global type average. For example, using the figures in Tables 8 and 9 we have:
73 / 82 = 0.89
59 / 53 = 1.11
36 / 38 = 0.95
27 / 27 = 1.00
Tabulating these gives the trust ratios for the member C:
Table 10. Trust ratios for C
------+-------+-------+------
1-hop | 2-hop | 3-hop | 4-hop
------+-------+-------+------
0.89 | 1.11 | 0.95 | 1.00
------+-------+-------+------
At this stage, we could take the average of these to give a "trust ratio" or "trust quotient" for C; it would be 0.99. For convenience we could discard the decimal point and just call it 99.
But would this be fair? I still have some doubts.
To find a "trust-ratio" for a particular member, we first take a global average of type averages for each different type. That is, we take all the 1-hop type averages of all the members in the system and calculate a global 1-hop type average. We do the same for all the different hop types, and form a global type average table (similar in principle to the FTSE-100 index):
Table 9. Global type averages
------+-------+-------+-------+-------+-------+----
1-hop | 2-hop | 3-hop | 4-hop | 5-hop | 6-hop | ...
------+-------+-------+-------+-------+-------+----
0.82 | 0.53 | 0.38 | 0.27 | 0.15 | 0.09 | ...
------+-------+-------+-------+-------+-------+----
(This table is just an example. I have not calculated the type averages for A, B, D, E, and so I have not got real global averages. But this does not matter for our purposes).
We can now compare the type averages for a particular member (Table 8) with the corresponding global type averages (Table 9). Here is a comparison of Tables 8 and 9:
------+-------+-------+-------+-------+-------+----
1-hop | 2-hop | 3-hop | 4-hop | 5-hop | 6-hop | ...
------+-------+-------+-------+-------+-------+----
0.82 | 0.53 | 0.38 | 0.27 | 0.15 | 0.09 | ...
------+-------+-------+-------+-------+-------+----
------+-------+-------+------
0.73 | 0.59 | 0.36 | 0.27
------+-------+-------+------
To do this we take ratios which will tell us what proportion the member type average is of the global type average. For example, using the figures in Tables 8 and 9 we have:
73 / 82 = 0.89
59 / 53 = 1.11
36 / 38 = 0.95
27 / 27 = 1.00
Tabulating these gives the trust ratios for the member C:
Table 10. Trust ratios for C
------+-------+-------+------
1-hop | 2-hop | 3-hop | 4-hop
------+-------+-------+------
0.89 | 1.11 | 0.95 | 1.00
------+-------+-------+------
At this stage, we could take the average of these to give a "trust ratio" or "trust quotient" for C; it would be 0.99. For convenience we could discard the decimal point and just call it 99.
But would this be fair? I still have some doubts.
Upvote
0
M
Mortime Business Software
4 Eliminating error
The domains of the hop types are different. That is, type averages for lower order hop types have more possible values than those for higher order hop types. This can distort the trust ratio. For example, if we have a member average hop value of 0.19 and a corresponding global average hop value of 0.20, then the ratio for the type would be 0.19/0.20 = 0.95. But what if that 0.19 had been rounded down from 0.194, and the 0.20 had been rounded up from 0.195? Then the real ratio would be 0.194/0.195 = 0.99, not 0.95. This is too big a difference to ignore.
One way of overcoming this would be to use sufficient decimal places to minimise this error down to a neglible level. The errors are not so large for higher values such as 0.89/0.90. The lower the hop values used in a ratio, the more decimal places we need to get the accuracy we want.
I feel that there could be more mathematics involved here, and that more thought may yield a near perfect answer. But at the same time, I feel that it may be overkill for our purposes, and that a simple method (such as using more decimal places) will suffice.
Using more decimal places as hop types increase in order will scale up the lower type averages in line with the higher ones because the differences in accuracy are not so marked in the higher values. This will allow us to safely take the average of a particular member's collection of trust ratios (no matter what size the collection is, or what types the collection contains) to get a trust ratio which can be compared fairly with those of other members..
If we chart the ratios of two type averages of high order hop type (say 0.01 and 0.02) to 2, 3, 4 and 6 decimal places, we find that the "rate of correction" grows smaller and smaller as we add decimal places. Even the difference between 4 decimal place accuracy and 6 decimal place accuracy seems to be negligible. I reccommend we use 6 decimal places.
Although we can never truly and completely convert one hop type to another, we can make a higher order hop type look virtually the same as the lowest order hop type. This will be sufficient for comparisons of them.
If you want to debate this "error" issue with me, I have some spreadsheet work which shows why six decimal places would be sufficient to eliminate virtually all the error. If anyone wants a copy, let me know. When you have studied it (it's very simple), then you can debate the error issue with me if you need to. If you can't be bothered reading the sheet, then you'll just have to "trust" me!
As with any abstract model, the one described above needs to be tested.
The domains of the hop types are different. That is, type averages for lower order hop types have more possible values than those for higher order hop types. This can distort the trust ratio. For example, if we have a member average hop value of 0.19 and a corresponding global average hop value of 0.20, then the ratio for the type would be 0.19/0.20 = 0.95. But what if that 0.19 had been rounded down from 0.194, and the 0.20 had been rounded up from 0.195? Then the real ratio would be 0.194/0.195 = 0.99, not 0.95. This is too big a difference to ignore.
One way of overcoming this would be to use sufficient decimal places to minimise this error down to a neglible level. The errors are not so large for higher values such as 0.89/0.90. The lower the hop values used in a ratio, the more decimal places we need to get the accuracy we want.
I feel that there could be more mathematics involved here, and that more thought may yield a near perfect answer. But at the same time, I feel that it may be overkill for our purposes, and that a simple method (such as using more decimal places) will suffice.
Using more decimal places as hop types increase in order will scale up the lower type averages in line with the higher ones because the differences in accuracy are not so marked in the higher values. This will allow us to safely take the average of a particular member's collection of trust ratios (no matter what size the collection is, or what types the collection contains) to get a trust ratio which can be compared fairly with those of other members..
If we chart the ratios of two type averages of high order hop type (say 0.01 and 0.02) to 2, 3, 4 and 6 decimal places, we find that the "rate of correction" grows smaller and smaller as we add decimal places. Even the difference between 4 decimal place accuracy and 6 decimal place accuracy seems to be negligible. I reccommend we use 6 decimal places.
Although we can never truly and completely convert one hop type to another, we can make a higher order hop type look virtually the same as the lowest order hop type. This will be sufficient for comparisons of them.
If you want to debate this "error" issue with me, I have some spreadsheet work which shows why six decimal places would be sufficient to eliminate virtually all the error. If anyone wants a copy, let me know. When you have studied it (it's very simple), then you can debate the error issue with me if you need to. If you can't be bothered reading the sheet, then you'll just have to "trust" me!
As with any abstract model, the one described above needs to be tested.
Upvote
0
M
Mortime Business Software
5 Programming the trust system
The following represents a preliminary sketch of the initial programming, and is for testing purposes only. It uses the grammar to find all the possible routes from one member to another.
The Perl script itself is a lazy hack and contains some BAD programming practices, including the use of symbolic references, but this does not affect the underlying concept or intentions, so don't worry!
The notes for the algorithm are the first that I wrote, so they are probably in need of updating by now.
The trace was done from the pseudocode before any coding was done, and shows how the algorithm aquires the first two sequences (routes) for AC. The Perl script worked the first time, straight from the algorithm - (sometimes you get lucky!) The algorithm is a recursive one. This may or may not be the better choice over iteration. The only reason I used recursion is to revise what I learned about it a couple of years ago. A software engineer once told me that recursion can be very much more efficient than iteration in some cases. This may or may not be one of those cases. If you come up with a better algorithm, which no doubt someone eventually will, then please share it with me.
----------------------------------
The example grammar is:
A ---> B D E
B ---> C E
C ---> B D
D ---> A B E
E ---> B C D
----------------------------------
The following is the algorithm in pseudocode (the trust receiver C is hardcoded to make the algorithm easier to read):
ROUTES( inFolder )
{
if1( inFolder is called C )
{
return an empty string
}
else
{
foreach( folder contained in inFolder )
{
if2( folder is not in this->sequence )
{
this->sequence = this->sequence . folder
ROUTES( folder )
if3( folder is called C )
{
store this->sequence in listOfSequences
chop one off the end of this->sequence
}
}
}
if4( this->sequence does not end with C )
{
chop one off the end of this->sequence
}
}
return an empty string
}
----------------------------------
The following is a trace of the algorithm for AC and shows how the first two routes are found:
---------------------------------------------------------------------------------------------------------------------------------------
inFolder folder this->sequence Instruction listOfSequences
---------------------------------------------------------------------------------------------------------------------------------------
A B AB ROUTES(B) -
B C ABC ROUTES(C) -
C - ABC return to ROUTES(C) -
B C ABC store sequence ABC
B C AB chop sequence ABC
B E ABE ROUTES(E) ABC
E B ABE if2 false ABC
E C ABEC ROUTES(C) ABC
C - ABEC return to ROUTES(C) ABC
E C ABEC store sequence ABC ABEC
E C ABE chop sequence ABC ABEC
E D ABED ROUTES(D) ABC ABEC
D A ABED if2 false ABC ABEC
D B ABED if2 false ABC ABEC
D E ABED if2 false ABC ABEC
D - ABE chop in if3 ABC ABEC
D - ABE return to ROUTES(D) ABC ABEC
E D AB chop in if3 ABC ABEC
E - AB return to ROUTES(E) ABC ABEC
B E A chop in if3 ABC ABEC
B - A return to ROUTES(B) ABC ABEC
---------------------------------------------------------------------------------------------------------------------------------------
A D AD ROUTES(D) ABC ABEC
...
---------------------------------------------------------------------------------------------------------------------------------------
----------------------------------
This is the initial sketch of the algorithm. This is what I started out with so it ***NEEDS UPDATING BY NOW***:
If all the folders in a folder are iterated over and the current sequence does not have the trustReceiver on the end, chop the last folder off the end the sequence. The next folder will not be the one which followed the folder in the last sequence, we examine the folder following this in ?'s list of folders.
We iterate over the folders of the last folder in the current sequence.
Is the folder already in the current sequence?
- If it is, do not add the folder to the sequence and skip the rest of the current loop iteration and move on to the next iteration.
Has the folder been looked at before?
- If it has, do not add the folder to the sequence and skip the rest of the current loop iteration and move on to the next iteration.
Is the folder the trustReceiver?
- If the last operation appended a folder to the current sequence, then add the trustReceiver to the current sequence, then add the current sequence to
the list of sequences, then start a new sequence with the same sequence, but chopped.
- If the last operation deposited a sequence into the list of sequences, then skip the rest of the current iteration and move on to the next iteration.
- If the last operation was a chop, check the list of sequences to see that there is not another sequence the same as the current sequence with the
trustReceiver on the end. If there is, chop the current sequence. If there is not, append the trustReceiver to the current sequence then add
the current sequence to the list of sequences, then start a new sequence with the preceding folders.
Has this folder just been chopped from the end of the sequence? If it has, move on to the next.
-------------------------------------------------------------------------------------------------------------------------------------------------
This is the Perl test script:
#------------------------------------
$truster = 'A';
$trustedMember = 'D';
#------------------------------------
$sequence = "$truster";
@sequences = ();
@A = ( B, D, E );
@B = ( C, E );
@C = ( B, D );
@D = ( A, B, E );
@E = ( B, C, D );
ROUTES( $truster );
foreach( @sequences )
{
print $_, "\n";
}
#------------------------------------
sub ROUTES()
{
if( $_[0] eq $trustedMember )
{
return "";
}
else
{
foreach( @{$_[0]} )
{
if( $sequence !~ /$_/ )
{
$sequence = $sequence . $_;
ROUTES( $_ );
if( $_ eq $trustedMember )
{
push @sequences, $sequence;
chop $sequence;
}
}
}
if( $sequence !~ /.*$trustedMember$/ )
{
chop $sequence;
}
}
return "";
}
#------------------------------------
The following represents a preliminary sketch of the initial programming, and is for testing purposes only. It uses the grammar to find all the possible routes from one member to another.
The Perl script itself is a lazy hack and contains some BAD programming practices, including the use of symbolic references, but this does not affect the underlying concept or intentions, so don't worry!
The notes for the algorithm are the first that I wrote, so they are probably in need of updating by now.
The trace was done from the pseudocode before any coding was done, and shows how the algorithm aquires the first two sequences (routes) for AC. The Perl script worked the first time, straight from the algorithm - (sometimes you get lucky!) The algorithm is a recursive one. This may or may not be the better choice over iteration. The only reason I used recursion is to revise what I learned about it a couple of years ago. A software engineer once told me that recursion can be very much more efficient than iteration in some cases. This may or may not be one of those cases. If you come up with a better algorithm, which no doubt someone eventually will, then please share it with me.
----------------------------------
The example grammar is:
A ---> B D E
B ---> C E
C ---> B D
D ---> A B E
E ---> B C D
----------------------------------
The following is the algorithm in pseudocode (the trust receiver C is hardcoded to make the algorithm easier to read):
ROUTES( inFolder )
{
if1( inFolder is called C )
{
return an empty string
}
else
{
foreach( folder contained in inFolder )
{
if2( folder is not in this->sequence )
{
this->sequence = this->sequence . folder
ROUTES( folder )
if3( folder is called C )
{
store this->sequence in listOfSequences
chop one off the end of this->sequence
}
}
}
if4( this->sequence does not end with C )
{
chop one off the end of this->sequence
}
}
return an empty string
}
----------------------------------
The following is a trace of the algorithm for AC and shows how the first two routes are found:
---------------------------------------------------------------------------------------------------------------------------------------
inFolder folder this->sequence Instruction listOfSequences
---------------------------------------------------------------------------------------------------------------------------------------
A B AB ROUTES(B) -
B C ABC ROUTES(C) -
C - ABC return to ROUTES(C) -
B C ABC store sequence ABC
B C AB chop sequence ABC
B E ABE ROUTES(E) ABC
E B ABE if2 false ABC
E C ABEC ROUTES(C) ABC
C - ABEC return to ROUTES(C) ABC
E C ABEC store sequence ABC ABEC
E C ABE chop sequence ABC ABEC
E D ABED ROUTES(D) ABC ABEC
D A ABED if2 false ABC ABEC
D B ABED if2 false ABC ABEC
D E ABED if2 false ABC ABEC
D - ABE chop in if3 ABC ABEC
D - ABE return to ROUTES(D) ABC ABEC
E D AB chop in if3 ABC ABEC
E - AB return to ROUTES(E) ABC ABEC
B E A chop in if3 ABC ABEC
B - A return to ROUTES(B) ABC ABEC
---------------------------------------------------------------------------------------------------------------------------------------
A D AD ROUTES(D) ABC ABEC
...
---------------------------------------------------------------------------------------------------------------------------------------
----------------------------------
This is the initial sketch of the algorithm. This is what I started out with so it ***NEEDS UPDATING BY NOW***:
If all the folders in a folder are iterated over and the current sequence does not have the trustReceiver on the end, chop the last folder off the end the sequence. The next folder will not be the one which followed the folder in the last sequence, we examine the folder following this in ?'s list of folders.
We iterate over the folders of the last folder in the current sequence.
Is the folder already in the current sequence?
- If it is, do not add the folder to the sequence and skip the rest of the current loop iteration and move on to the next iteration.
Has the folder been looked at before?
- If it has, do not add the folder to the sequence and skip the rest of the current loop iteration and move on to the next iteration.
Is the folder the trustReceiver?
- If the last operation appended a folder to the current sequence, then add the trustReceiver to the current sequence, then add the current sequence to
the list of sequences, then start a new sequence with the same sequence, but chopped.
- If the last operation deposited a sequence into the list of sequences, then skip the rest of the current iteration and move on to the next iteration.
- If the last operation was a chop, check the list of sequences to see that there is not another sequence the same as the current sequence with the
trustReceiver on the end. If there is, chop the current sequence. If there is not, append the trustReceiver to the current sequence then add
the current sequence to the list of sequences, then start a new sequence with the preceding folders.
Has this folder just been chopped from the end of the sequence? If it has, move on to the next.
-------------------------------------------------------------------------------------------------------------------------------------------------
This is the Perl test script:
#------------------------------------
$truster = 'A';
$trustedMember = 'D';
#------------------------------------
$sequence = "$truster";
@sequences = ();
@A = ( B, D, E );
@B = ( C, E );
@C = ( B, D );
@D = ( A, B, E );
@E = ( B, C, D );
ROUTES( $truster );
foreach( @sequences )
{
print $_, "\n";
}
#------------------------------------
sub ROUTES()
{
if( $_[0] eq $trustedMember )
{
return "";
}
else
{
foreach( @{$_[0]} )
{
if( $sequence !~ /$_/ )
{
$sequence = $sequence . $_;
ROUTES( $_ );
if( $_ eq $trustedMember )
{
push @sequences, $sequence;
chop $sequence;
}
}
}
if( $sequence !~ /.*$trustedMember$/ )
{
chop $sequence;
}
}
return "";
}
#------------------------------------
Upvote
0
creospace said:
You can indeed and I think this would be an awesome addition to the UKBF forums.
There is a mod available at vbulletin.org here:
http://www.vbulletin.org/forum/showthread.php?t=65730&highlight=review+system
Maybe it's not as complex as what has been discussed but it would definitely be useful.
Upvote
0
A
amo crafts
In my opinion, it is not sufficient to average the trust values around a member's node in an attempt to estimate the "trust" that the member receives.
No it's not, but it is a sufficient way to identify discrepancies.
For example, a trust value t1 with a nominal trust value of 0.74 over 3 hops, is better than another trust value t2 with the same nominal trust value of 0.74 over 2 hops. This is because if t2 were to undergo a further hop and become a 3-hop type, it would have to decrease below 0.74 (because we take a fraction of a fraction) (providing of course that this further trust level is not 1, which should not be allowed because perfection implies God status).
The argument in the previous paragraph can be taken as a proof by example, and should serve to explain why we have to type routes by different numbers of hops.
Certainly up to the individual, though I would have to disagree. At best the two balance each other out, at worst I would rely upon the shorter route. There is certainly no proof here. I understand that essentially you are extending the curves but the decision to select this method over selecting the shorter route is a very subjective decision. and introducing such subjective decisions so deeply into a solution will cause problems.
The calculation of a trust ratio is very flawed. The true value of the system is to determine the trust of an individual (or company or call it what you will), not to determine how much that individual can be compared to others grouped with him. Not to offend any social groups, but lets take a group of Buddhist monks. We can determine the trust value of one of those monks to, let's say, 0.75. Now add to the monks a group of individuals from a high security prison. The monks trust value would instantly increase due to the (assumed for this example) low trust ratings of the new members. It would be wrong to determine the monk is more likely to supply me with the Bucky I've ordered from him simply because he is now grouped with the prisoners. He's just as likely to supply me, or run away with my money, as he was before.
Overall, I disagree with the whole method proposed here. Too many of the decisions are subjective and stem from intuition. Why take average values and not mean values for example? Where is it simulated that a person's trust may be inappropriate (we all make mistakes and have been misled in the past)? Should the trust value of an individual drop just because the trust value of an individual connected to him/her has dropped? Or rise even? You obviously think that is the correct model, but I would disagree again. This strikes me more as a mathematical exercise than a model of the real problem. It would not be scalable, and maintaining it would likely be problematic.
What hasn't been taken into account is the hop from system to user. Let's say a user only has 0.5 trust in the system, then the system as a whole becomes useless. In fact the user would have to have a lot of trust in the system to make it usable. So how do we get around this problem? A number of ways. Provide information (which they can understand) as to how the system works. Introduce counter measures against fraudsters and inform the user of these measures. This needs to be weighed up in favour of/against security, but some measures (such as one I suggested in a previous post) could cause such a problem for fraudsters (with a wide enough net) that it would be futile for them to attempt to circumnavigate it. Most importantly of all, take those subjective/intuitive decisions and allow the user to decide who he (or she) wants to trust. If they would prefer to trust a friend of a friend of a friend over a friend of a friend simply because they have a higher trust value then fine, but let the user decide that not the coder. Many of them will decide to trust a friend of a friend over a friend of a friend of a friend, even if the system's trust value determines otherwise. Profile the user with a series of related questions. With the method suggested here, everything is tied too tightly together to allow this adequately. Without trust in the system, the system as a whole becomes useless.
A couple of points about the implementation.
I am a fan of recursion, it can often lead to elegant solutions. It's more addictive than coke (I hear), and lots of fun too. However, in this case I would avoid it like hens avoid teeth. Over and over again, with a problem like this, we are threatened with exponential scaling issues. With only five nodes in the system recursion wouldn't cause a problem, but as the number of nodes increase the stack size required to execute the system would grow dramatically.
The problem with using a brute force approach to discover routes is, again, that the time it will take to execute will grow exponentially as more nodes are added.
In my opinion, a route finding algorithm is required here, and I would suggest using a heuristic of a combination between the number of paths from a node (shortest route) and the trust in the node information (trust of route) -- weighted according to the user's preferences.
No it's not, but it is a sufficient way to identify discrepancies.
For example, a trust value t1 with a nominal trust value of 0.74 over 3 hops, is better than another trust value t2 with the same nominal trust value of 0.74 over 2 hops. This is because if t2 were to undergo a further hop and become a 3-hop type, it would have to decrease below 0.74 (because we take a fraction of a fraction) (providing of course that this further trust level is not 1, which should not be allowed because perfection implies God status).
The argument in the previous paragraph can be taken as a proof by example, and should serve to explain why we have to type routes by different numbers of hops.
Certainly up to the individual, though I would have to disagree. At best the two balance each other out, at worst I would rely upon the shorter route. There is certainly no proof here. I understand that essentially you are extending the curves but the decision to select this method over selecting the shorter route is a very subjective decision. and introducing such subjective decisions so deeply into a solution will cause problems.
The calculation of a trust ratio is very flawed. The true value of the system is to determine the trust of an individual (or company or call it what you will), not to determine how much that individual can be compared to others grouped with him. Not to offend any social groups, but lets take a group of Buddhist monks. We can determine the trust value of one of those monks to, let's say, 0.75. Now add to the monks a group of individuals from a high security prison. The monks trust value would instantly increase due to the (assumed for this example) low trust ratings of the new members. It would be wrong to determine the monk is more likely to supply me with the Bucky I've ordered from him simply because he is now grouped with the prisoners. He's just as likely to supply me, or run away with my money, as he was before.
Overall, I disagree with the whole method proposed here. Too many of the decisions are subjective and stem from intuition. Why take average values and not mean values for example? Where is it simulated that a person's trust may be inappropriate (we all make mistakes and have been misled in the past)? Should the trust value of an individual drop just because the trust value of an individual connected to him/her has dropped? Or rise even? You obviously think that is the correct model, but I would disagree again. This strikes me more as a mathematical exercise than a model of the real problem. It would not be scalable, and maintaining it would likely be problematic.
What hasn't been taken into account is the hop from system to user. Let's say a user only has 0.5 trust in the system, then the system as a whole becomes useless. In fact the user would have to have a lot of trust in the system to make it usable. So how do we get around this problem? A number of ways. Provide information (which they can understand) as to how the system works. Introduce counter measures against fraudsters and inform the user of these measures. This needs to be weighed up in favour of/against security, but some measures (such as one I suggested in a previous post) could cause such a problem for fraudsters (with a wide enough net) that it would be futile for them to attempt to circumnavigate it. Most importantly of all, take those subjective/intuitive decisions and allow the user to decide who he (or she) wants to trust. If they would prefer to trust a friend of a friend of a friend over a friend of a friend simply because they have a higher trust value then fine, but let the user decide that not the coder. Many of them will decide to trust a friend of a friend over a friend of a friend of a friend, even if the system's trust value determines otherwise. Profile the user with a series of related questions. With the method suggested here, everything is tied too tightly together to allow this adequately. Without trust in the system, the system as a whole becomes useless.
A couple of points about the implementation.
I am a fan of recursion, it can often lead to elegant solutions. It's more addictive than coke (I hear), and lots of fun too. However, in this case I would avoid it like hens avoid teeth. Over and over again, with a problem like this, we are threatened with exponential scaling issues. With only five nodes in the system recursion wouldn't cause a problem, but as the number of nodes increase the stack size required to execute the system would grow dramatically.
The problem with using a brute force approach to discover routes is, again, that the time it will take to execute will grow exponentially as more nodes are added.
In my opinion, a route finding algorithm is required here, and I would suggest using a heuristic of a combination between the number of paths from a node (shortest route) and the trust in the node information (trust of route) -- weighted according to the user's preferences.
Upvote
0
M
Mortime Business Software
Dave Mortimer wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In my opinion, it is not sufficient to average the trust values around a member's node in an attempt to estimate the "trust" that the member receives.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
amo crafts answered:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
No it's not, but it is a sufficient way to identify discrepancies.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
What discrepancies? We haven't even tested anything yet!
Dave Mortimer wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For example, a trust value t1 with a nominal trust value of 0.74 over 3 hops, is better than another trust value t2 with the same nominal trust value of 0.74 over 2 hops. This is because if t2 were to undergo a further hop and become a 3-hop type, it would have to decrease below 0.74 (because we take a fraction of a fraction) (providing of course that this further trust level is not 1, which should not be allowed because perfection implies God status).
The argument in the previous paragraph can be taken as a proof by example, and should serve to explain why we have to type routes by different numbers of hops.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
amo crafts answered:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Certainly up to the individual, though I would have to disagree. At best the two balance each other out, at worst I would rely upon the shorter route. There is certainly no "proof" here. I understand that essentially you are extending the curves but the decision to select this method over selecting the shorter route is a very subjective decision. and introducing such subjective decisions so deeply into a solution will cause problems.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I have some questions regarding this statement of yours.
Ignoring some nodes for a moment to make this simple, and considering only the nodes A, E and D; if A trusts D by 0.93, and A trusts E by 0.77, and E trusts D by 0.51, (refer to the diagram) and I ask you how much trust A has in D, then I am effectively asking how much trust D receives from A.
How much trust would you say D has from A? (Please show me your method).
How would you calculate the trust that D has from A? (Please show me your working).
amo crafts answered:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
At best the two balance each other out
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
How can two routes of different hop order "balance each other out"? Can you please show me your calculation method for this? (Remember that I did not invent the hop type, it is inherent in the system. I merely identified and named it).
One route has 2 hops and the other has 1 hop. If they both have the same route value of 0.74, then I would have thought it was obvious that being trusted by 0.74 over 2 hops is a better achievement than being trusted by 0.74 over one hop because the preceding member (node) in the 2-hop route would have to place more than 0.74 of trust in the end node (assuming that 0.00 < t < 1.00).
Your intuition alone should make you feel that if you can be trusted by a stranger by a value roughly equal to that of a direct contact, then this trust has more qualitative value. This is a case where your intuition can be simply confirmed.
Here is a simple, general algebraic version of my textual proof above:
Let the 1-hop value be given by:
1 / b = 1 / x
b = x
Let the 2-hop value be given by:
(1 / a)(1 / c) = 1 / x
1 / ac = 1 / x
ac = x
We want to show that:
1 / c > 1 / x
a and c are factors of x so:
If:
a not= 1 and c not= 1
Then:
a < x and c < x
c < x
c / c < x / c
1 < x / c
1 / x < x / cx
1 / x < 1 / c
Therefore:
1 / c > 1 / x
as required.
.
Please can you show me some clear working which shows why you disagree with this?
amo crafts wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
... at worst I would rely upon the shorter route.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Why would you want to rely on only the shorter route? For example, why would you rely only on A's direct trust in D of 0.93 when E only trusts D by 0.51? Would you not want to consider E's opinion of D as well as A's opinion?
What right would D have to boast a trust value of 0.93 when two other members do not trust him anywhere near as much?
If you are talking about chopping some routes at certain lengths in order to artificially endow the system with "fairness", then could you please show me some working and calculations to explain why you think this is a good idea?
The proof I wrote above is for the following lemma:
Dave Mortimer wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Two routes of different hop order with the same nominal trust value are not equal.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This lemma is relevant if you can understand the fact that a member receives different types of trust; 1-hop, 2-hop, 3-hop, etc., and that it does not make sense to directly compare route values of these different types. For example, comparing the route AD with the route AED is nonsensical because in the calculation of AED we took a fraction of a fraction (an opinion of an opinion) whereas in calculating AD we took a fraction (an opinion). Being trusted by, say, 0.74 over two hops is better than being directly trusted by 0.74 over 1 hop because it is obviously a better achievement.
A would have to be foolishly dogmatic to, *generaly*, trust D by 0.93. He must take E's opinion into account (ignore other routes for a moment). However, for a particular transaction, or set of transactions, A has clearly placed 0.93 of trust in D, but this should not be the final evaluation of the trustworthiness of D; it is A's opinion of D only for *some particular set* of transactions with D. Other opinions must be accounted for to arrive at a general system opinion of D.
I have not introduced anything subjective or otherwise into my model. I am making observations of behaviour which is exhibited naturally by Duane's fundamental principle of "diminishing trust". I did not "invent" the different hop-types, they are an obvious property of the system; in fact they are a property of Duane's original idea of a fundamental trust chain.
What we are trying to decide here is whether the original idea can be taken as an *axiom* for further mathematical development. My lemma that a longer chain with the same nominal value as a shorter chain is more valuable is based on this *potential* axiom. If "there is no proof here" as you say, then this axiom does not exist and we should not waste any further time on it. I am not even sure why I am calling it a *potential* axiom. I should probably assume that it *is* an axiom because it is actually fundamental to the reasoning, and is a self-evident truth whether any resulting trust calculating method is viable or not.
You are trying to accuse me of doing something which you yourself are doing. That is, you are tampering with a phenomenon which arises naturally from the fundamental idea. I cannot understand why, at this early stage, you would want to consider only shorter routes when there is trust to be gained or lost via the longer routes. What are your reasons for this apart from trying to force the system to work? What are these ideas based on? Why can we not consider all hop types in theory and for modelling purposes?
Nor can I understand why you want to manufacture unnatural, arbitrary boundaries without any proper testing beforehand. Would it not be better to start with a model from the real world? I think it is reasonable to start with something like the following:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Let us assume that nobody is completely trustworthy and nobody is completely untrustworthy, but we should not presume to know how trustworthy or untrustworthy a person is because trust is a human emotion and is very difficult to define. Therefore we should test the prototype of the system with an upper boundary of just below 1, and a lower boundary of just above 0.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Or maybe we should start with an assumption that some people are completely trustworthy and others are completely untrustworthy, and set the boundaries equal to 1 and 0 and see what happens. When we have made some observations of a working system, then we *may* be able to adjust for anything which seems unreasonable.
What we cannot start with is a full blown working system regulated by what *you think* are properties of real life trust. Arriving at a working system is an iterative development process which is best started from fundamentals.
It seems to me that you are trying to build an atomic bomb without considering Einstien's theory.
Dave
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In my opinion, it is not sufficient to average the trust values around a member's node in an attempt to estimate the "trust" that the member receives.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
amo crafts answered:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
No it's not, but it is a sufficient way to identify discrepancies.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
What discrepancies? We haven't even tested anything yet!
Dave Mortimer wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For example, a trust value t1 with a nominal trust value of 0.74 over 3 hops, is better than another trust value t2 with the same nominal trust value of 0.74 over 2 hops. This is because if t2 were to undergo a further hop and become a 3-hop type, it would have to decrease below 0.74 (because we take a fraction of a fraction) (providing of course that this further trust level is not 1, which should not be allowed because perfection implies God status).
The argument in the previous paragraph can be taken as a proof by example, and should serve to explain why we have to type routes by different numbers of hops.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
amo crafts answered:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Certainly up to the individual, though I would have to disagree. At best the two balance each other out, at worst I would rely upon the shorter route. There is certainly no "proof" here. I understand that essentially you are extending the curves but the decision to select this method over selecting the shorter route is a very subjective decision. and introducing such subjective decisions so deeply into a solution will cause problems.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I have some questions regarding this statement of yours.
Ignoring some nodes for a moment to make this simple, and considering only the nodes A, E and D; if A trusts D by 0.93, and A trusts E by 0.77, and E trusts D by 0.51, (refer to the diagram) and I ask you how much trust A has in D, then I am effectively asking how much trust D receives from A.
How much trust would you say D has from A? (Please show me your method).
How would you calculate the trust that D has from A? (Please show me your working).
amo crafts answered:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
At best the two balance each other out
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
How can two routes of different hop order "balance each other out"? Can you please show me your calculation method for this? (Remember that I did not invent the hop type, it is inherent in the system. I merely identified and named it).
One route has 2 hops and the other has 1 hop. If they both have the same route value of 0.74, then I would have thought it was obvious that being trusted by 0.74 over 2 hops is a better achievement than being trusted by 0.74 over one hop because the preceding member (node) in the 2-hop route would have to place more than 0.74 of trust in the end node (assuming that 0.00 < t < 1.00).
Your intuition alone should make you feel that if you can be trusted by a stranger by a value roughly equal to that of a direct contact, then this trust has more qualitative value. This is a case where your intuition can be simply confirmed.
Here is a simple, general algebraic version of my textual proof above:
Let the 1-hop value be given by:
1 / b = 1 / x
b = x
Let the 2-hop value be given by:
(1 / a)(1 / c) = 1 / x
1 / ac = 1 / x
ac = x
We want to show that:
1 / c > 1 / x
a and c are factors of x so:
If:
a not= 1 and c not= 1
Then:
a < x and c < x
c < x
c / c < x / c
1 < x / c
1 / x < x / cx
1 / x < 1 / c
Therefore:
1 / c > 1 / x
as required.
.
Please can you show me some clear working which shows why you disagree with this?
amo crafts wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
... at worst I would rely upon the shorter route.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Why would you want to rely on only the shorter route? For example, why would you rely only on A's direct trust in D of 0.93 when E only trusts D by 0.51? Would you not want to consider E's opinion of D as well as A's opinion?
What right would D have to boast a trust value of 0.93 when two other members do not trust him anywhere near as much?
If you are talking about chopping some routes at certain lengths in order to artificially endow the system with "fairness", then could you please show me some working and calculations to explain why you think this is a good idea?
The proof I wrote above is for the following lemma:
Dave Mortimer wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Two routes of different hop order with the same nominal trust value are not equal.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This lemma is relevant if you can understand the fact that a member receives different types of trust; 1-hop, 2-hop, 3-hop, etc., and that it does not make sense to directly compare route values of these different types. For example, comparing the route AD with the route AED is nonsensical because in the calculation of AED we took a fraction of a fraction (an opinion of an opinion) whereas in calculating AD we took a fraction (an opinion). Being trusted by, say, 0.74 over two hops is better than being directly trusted by 0.74 over 1 hop because it is obviously a better achievement.
A would have to be foolishly dogmatic to, *generaly*, trust D by 0.93. He must take E's opinion into account (ignore other routes for a moment). However, for a particular transaction, or set of transactions, A has clearly placed 0.93 of trust in D, but this should not be the final evaluation of the trustworthiness of D; it is A's opinion of D only for *some particular set* of transactions with D. Other opinions must be accounted for to arrive at a general system opinion of D.
I have not introduced anything subjective or otherwise into my model. I am making observations of behaviour which is exhibited naturally by Duane's fundamental principle of "diminishing trust". I did not "invent" the different hop-types, they are an obvious property of the system; in fact they are a property of Duane's original idea of a fundamental trust chain.
What we are trying to decide here is whether the original idea can be taken as an *axiom* for further mathematical development. My lemma that a longer chain with the same nominal value as a shorter chain is more valuable is based on this *potential* axiom. If "there is no proof here" as you say, then this axiom does not exist and we should not waste any further time on it. I am not even sure why I am calling it a *potential* axiom. I should probably assume that it *is* an axiom because it is actually fundamental to the reasoning, and is a self-evident truth whether any resulting trust calculating method is viable or not.
You are trying to accuse me of doing something which you yourself are doing. That is, you are tampering with a phenomenon which arises naturally from the fundamental idea. I cannot understand why, at this early stage, you would want to consider only shorter routes when there is trust to be gained or lost via the longer routes. What are your reasons for this apart from trying to force the system to work? What are these ideas based on? Why can we not consider all hop types in theory and for modelling purposes?
Nor can I understand why you want to manufacture unnatural, arbitrary boundaries without any proper testing beforehand. Would it not be better to start with a model from the real world? I think it is reasonable to start with something like the following:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Let us assume that nobody is completely trustworthy and nobody is completely untrustworthy, but we should not presume to know how trustworthy or untrustworthy a person is because trust is a human emotion and is very difficult to define. Therefore we should test the prototype of the system with an upper boundary of just below 1, and a lower boundary of just above 0.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Or maybe we should start with an assumption that some people are completely trustworthy and others are completely untrustworthy, and set the boundaries equal to 1 and 0 and see what happens. When we have made some observations of a working system, then we *may* be able to adjust for anything which seems unreasonable.
What we cannot start with is a full blown working system regulated by what *you think* are properties of real life trust. Arriving at a working system is an iterative development process which is best started from fundamentals.
It seems to me that you are trying to build an atomic bomb without considering Einstien's theory.
Dave
Upvote
0
- Original Poster
- #76
Sorry, I don't have time to read and comprehend all of this discussion. But just to re-iterate two points (ignore me if they don't need repeating)
a) We should never be looking for the 'best' trust level. We need a 'realistic' trust level, not an 'optimistic' trust level.
and
b) Any node does not have an inherent trust level in itself.. Trust levels for any node are only relative to the starting node - ie, the person asking 'how much do I trust x?". The whole system has to be subjective.
a) We should never be looking for the 'best' trust level. We need a 'realistic' trust level, not an 'optimistic' trust level.
and
b) Any node does not have an inherent trust level in itself.. Trust levels for any node are only relative to the starting node - ie, the person asking 'how much do I trust x?". The whole system has to be subjective.
Upvote
0
A
amo crafts
What discrepancies? We haven't even tested anything yet!
No, it was simply a statement to highlight that the values of the surrounding nodes should not be dismissed completely. They would do quite nicely to help spot people trying to break the system.
Ignoring some nodes for a moment to make this simple, and considering only the nodes A, E and D; if A trusts D by 0.93, and A trusts E by 0.77, and E trusts D by 0.51, (refer to the diagram) and I ask you how much trust A has in D, then I am effectively asking how much trust D receives from A.
How much trust would you say D has from A? (Please show me your method).
How would you calculate the trust that D has from A? (Please show me your working).
I would tell A to trust D by 0.93 as that is how much A has decided to trust D. I wouldn't do any modification because E doesn't trust D quite so much. That's leaving aside that A doesn't trust E so much as D (taking it to further extremes, I wouldn't trust a good friend any less because someone I dislike doesn't trust them). Of course I think the system should traverse more than one route to provide a number of results and allow the user to see any discrepancies, but not hide the information from the user by averaging the results or applying any other mathematical algorithms to provide a generalised result. The solution should easily allow further modification. For example, it may (for example) be required further down the line to allow the user to apply an additional diminishing value for each hop.
How can two routes of different hop order "balance each other out"? Can you please show me your calculation method for this? (Remember that I did not invent the hop type, it is inherent in the system. I merely identified and named it).
One route has 2 hops and the other has 1 hop. If they both have the same route value of 0.74, then I would have thought it was obvious that being trusted by 0.74 over 2 hops is a better achievement than being trusted by 0.74 over one hop because the preceding member (node) in the 2-hop route would have to place more than 0.74 of trust in the end node (assuming that 0.00 < t < 1.00).
I've seen many systems fail being the designers thought something obvious. You've chosen the method that you would choose, which isn't necessarily the method everyone would use. If a friend of mine were to tell me that I can trust another person by X amount, I would trust their word above a stranger regardless of how long the chain of people is from stranger to myself. I couldn't care less of what that stranger says is above, below or equal to X. And extending that example, I would prefer to trust a friend of a friend than someone six times removed from myself.
I'm talking about my preference, you are talking about yours. You make the point several times that I'm suggesting a method suitable only for myself. I make the same point to your own solution. Where your solution leaves little leeway for the user to make their own decisions, I have suggested in my previous post that the quotient allow the user to weight their preference.
I'm not going to write any proof because the method the user chooses to trust people by is their decision. It is subjective to the user, not the designer.
Your intuition alone should make you feel that if you can be trusted by a stranger by a value roughly equal to that of a direct contact, then this trust has more qualitative value. This is a case where your intuition can be simply confirmed.
Of course, but at the same time I've met people who my sister's boyfriend would trust with his life, whereas I would not trust them at all. Nor do I trust my sister's boyfriend. I don't want his opinion to influence how much I should trust those others, I don't need any proof to show that. That information should be made available to me, certainly not forced upon me.
Why would you want to rely on only the shorter route? For example, why would you rely only on A's direct trust in D of 0.93 when E only trusts D by 0.51? Would you not want to consider E's opinion of D as well as A's opinion?
What right would D have to boast a trust value of 0.93 when two other members do not trust him anywhere near as much?
See above. It's up to each person how they trust people.
If you are talking about chopping some routes at certain lengths in order to artificially endow the system with "fairness", then could you please show me some working and calculations to explain why you think this is a good idea?
I'm not, I don't know where you got this idea from.
... Being trusted by, say, 0.74 over two hops is better than being directly trusted by 0.74 over 1 hop because it is obviously a better achievement.
In your opinion, not everyone's.
A would have to be foolishly dogmatic to, *generaly*, trust D by 0.93. He must take E's opinion into account (ignore other routes for a moment). However, for a particular transaction, or set of transactions, A has clearly placed 0.93 of trust in D, but this should not be the final evaluation of the trustworthiness of D; it is A's opinion of D only for *some particular set* of transactions with D. Other opinions must be accounted for to arrive at a general system opinion of D.
Why must he take E's opinion into account? Why must other opinions be taken into account? That is A's decision to make, and it is up to the system to provide him with the information to allow him to make a decision.
I have not introduced anything subjective or otherwise into my model. ...
When you say that the user must base their trust on what others have decided, or that longer chains of trust must be given more weight than shorter chains, then yes you have made subjective decisions.
What we are trying to decide here is whether the original idea can be taken as an *axiom* for further mathematical development.
I thought we were discussing a system to determine trust, not a mathematical model.
You are trying to accuse me of doing something which you yourself are doing. That is, you are tampering with a phenomenon which arises naturally from the fundamental idea. I cannot understand why, at this early stage, you would want to consider only shorter routes when there is trust to be gained or lost via the longer routes. What are your reasons for this apart from trying to force the system to work? What are these ideas based on? Why can we not consider all hop types in theory and for modelling purposes?
Again, you are claiming I said something which I did not. I suggested the user may (not must, the option is entirely theirs at runtime) decide that shorter routes are of more value. They may also decide that shorter routes are of more value. It's their decision to make.
Nor can I understand why you want to manufacture unnatural, arbitrary boundaries without any proper testing beforehand. Would it not be better to start with a model from the real world?
What borders did I introduce? As far as I'm concerned I've suggested a solution far more flexible than your own.
I think it is reasonable to start with something like the following:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~
Let us assume nobody that is completely trustworthy and nobody is completely untrustworthy, but we should not presume to know how trustworthy or untrustworthy a person is because trust is a human emotion and is very difficult to define. Therefore we should test the prototype of the system with an upper boundary of just below 1, and a lower boundary of just above 0.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~
Or maybe we should start with an assumption that some people are completely trustworthy and others are completely untrustworthy, and set the boundaries equal to 1 and 0 and see what happens. When we have made some observations of a working system, then we *may* be able to adjust for anything which seems unreasonable.
And this is only necessary because your system relies upon a trust value relative to others, which I disagree with.
What we cannot start with is a full blown working system regulated by what *you think* are properties of real life trust. Arriving at a working system is an iterative development process which is best started from fundamentals.
It seems to me that you are trying to build an atomic bomb without considering Einstien's theory.
Again, I take issue at being accused of doing something I clearly did not do. Not only do I think what you are suggesting is an unmaintainable system which provides little leeway for change, but by making accusations your giving the impression of not wanting to hear alternate opinions. Creating a route finder with configurable quotient is a basic starter which allows very simple changes to be made over a period of time. It is hardly an atomic bomb, more like a homework exercise.
No, it was simply a statement to highlight that the values of the surrounding nodes should not be dismissed completely. They would do quite nicely to help spot people trying to break the system.
Ignoring some nodes for a moment to make this simple, and considering only the nodes A, E and D; if A trusts D by 0.93, and A trusts E by 0.77, and E trusts D by 0.51, (refer to the diagram) and I ask you how much trust A has in D, then I am effectively asking how much trust D receives from A.
How much trust would you say D has from A? (Please show me your method).
How would you calculate the trust that D has from A? (Please show me your working).
I would tell A to trust D by 0.93 as that is how much A has decided to trust D. I wouldn't do any modification because E doesn't trust D quite so much. That's leaving aside that A doesn't trust E so much as D (taking it to further extremes, I wouldn't trust a good friend any less because someone I dislike doesn't trust them). Of course I think the system should traverse more than one route to provide a number of results and allow the user to see any discrepancies, but not hide the information from the user by averaging the results or applying any other mathematical algorithms to provide a generalised result. The solution should easily allow further modification. For example, it may (for example) be required further down the line to allow the user to apply an additional diminishing value for each hop.
How can two routes of different hop order "balance each other out"? Can you please show me your calculation method for this? (Remember that I did not invent the hop type, it is inherent in the system. I merely identified and named it).
One route has 2 hops and the other has 1 hop. If they both have the same route value of 0.74, then I would have thought it was obvious that being trusted by 0.74 over 2 hops is a better achievement than being trusted by 0.74 over one hop because the preceding member (node) in the 2-hop route would have to place more than 0.74 of trust in the end node (assuming that 0.00 < t < 1.00).
I've seen many systems fail being the designers thought something obvious. You've chosen the method that you would choose, which isn't necessarily the method everyone would use. If a friend of mine were to tell me that I can trust another person by X amount, I would trust their word above a stranger regardless of how long the chain of people is from stranger to myself. I couldn't care less of what that stranger says is above, below or equal to X. And extending that example, I would prefer to trust a friend of a friend than someone six times removed from myself.
I'm talking about my preference, you are talking about yours. You make the point several times that I'm suggesting a method suitable only for myself. I make the same point to your own solution. Where your solution leaves little leeway for the user to make their own decisions, I have suggested in my previous post that the quotient allow the user to weight their preference.
I'm not going to write any proof because the method the user chooses to trust people by is their decision. It is subjective to the user, not the designer.
Your intuition alone should make you feel that if you can be trusted by a stranger by a value roughly equal to that of a direct contact, then this trust has more qualitative value. This is a case where your intuition can be simply confirmed.
Of course, but at the same time I've met people who my sister's boyfriend would trust with his life, whereas I would not trust them at all. Nor do I trust my sister's boyfriend. I don't want his opinion to influence how much I should trust those others, I don't need any proof to show that. That information should be made available to me, certainly not forced upon me.
Why would you want to rely on only the shorter route? For example, why would you rely only on A's direct trust in D of 0.93 when E only trusts D by 0.51? Would you not want to consider E's opinion of D as well as A's opinion?
What right would D have to boast a trust value of 0.93 when two other members do not trust him anywhere near as much?
See above. It's up to each person how they trust people.
If you are talking about chopping some routes at certain lengths in order to artificially endow the system with "fairness", then could you please show me some working and calculations to explain why you think this is a good idea?
I'm not, I don't know where you got this idea from.
... Being trusted by, say, 0.74 over two hops is better than being directly trusted by 0.74 over 1 hop because it is obviously a better achievement.
In your opinion, not everyone's.
A would have to be foolishly dogmatic to, *generaly*, trust D by 0.93. He must take E's opinion into account (ignore other routes for a moment). However, for a particular transaction, or set of transactions, A has clearly placed 0.93 of trust in D, but this should not be the final evaluation of the trustworthiness of D; it is A's opinion of D only for *some particular set* of transactions with D. Other opinions must be accounted for to arrive at a general system opinion of D.
Why must he take E's opinion into account? Why must other opinions be taken into account? That is A's decision to make, and it is up to the system to provide him with the information to allow him to make a decision.
I have not introduced anything subjective or otherwise into my model. ...
When you say that the user must base their trust on what others have decided, or that longer chains of trust must be given more weight than shorter chains, then yes you have made subjective decisions.
What we are trying to decide here is whether the original idea can be taken as an *axiom* for further mathematical development.
I thought we were discussing a system to determine trust, not a mathematical model.
You are trying to accuse me of doing something which you yourself are doing. That is, you are tampering with a phenomenon which arises naturally from the fundamental idea. I cannot understand why, at this early stage, you would want to consider only shorter routes when there is trust to be gained or lost via the longer routes. What are your reasons for this apart from trying to force the system to work? What are these ideas based on? Why can we not consider all hop types in theory and for modelling purposes?
Again, you are claiming I said something which I did not. I suggested the user may (not must, the option is entirely theirs at runtime) decide that shorter routes are of more value. They may also decide that shorter routes are of more value. It's their decision to make.
Nor can I understand why you want to manufacture unnatural, arbitrary boundaries without any proper testing beforehand. Would it not be better to start with a model from the real world?
What borders did I introduce? As far as I'm concerned I've suggested a solution far more flexible than your own.
I think it is reasonable to start with something like the following:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~
Let us assume nobody that is completely trustworthy and nobody is completely untrustworthy, but we should not presume to know how trustworthy or untrustworthy a person is because trust is a human emotion and is very difficult to define. Therefore we should test the prototype of the system with an upper boundary of just below 1, and a lower boundary of just above 0.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~
Or maybe we should start with an assumption that some people are completely trustworthy and others are completely untrustworthy, and set the boundaries equal to 1 and 0 and see what happens. When we have made some observations of a working system, then we *may* be able to adjust for anything which seems unreasonable.
And this is only necessary because your system relies upon a trust value relative to others, which I disagree with.
What we cannot start with is a full blown working system regulated by what *you think* are properties of real life trust. Arriving at a working system is an iterative development process which is best started from fundamentals.
It seems to me that you are trying to build an atomic bomb without considering Einstien's theory.
Again, I take issue at being accused of doing something I clearly did not do. Not only do I think what you are suggesting is an unmaintainable system which provides little leeway for change, but by making accusations your giving the impression of not wanting to hear alternate opinions. Creating a route finder with configurable quotient is a basic starter which allows very simple changes to be made over a period of time. It is hardly an atomic bomb, more like a homework exercise.
Upvote
0
M
Mortime Business Software
amo crafts wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The calculation of a trust ratio is very flawed. The true value of the system is to determine the trust of an individual (or company or call it what you will), not to determine how much that individual can be compared to others grouped with him.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
That is your opinion and you are entitled to it. I am still waiting to see how you will achieve it.
The global type averages are based on the trust that members in the system actually receive according to the axiom which we are supposed to be adhering to. Therefore, in theory, we can calculate an ideal trust from the collective of the system, and compare any particular member of the system with it.
When you propose "determining the trust of an individual", can you tell me something about how you would achieve this?
Do you think that just because your best mate trusts you by 0.99, that I should place the same amount of trust in you?
Sorry, but trust is not an attribute of a person like eye colour, which you can carry around with you. Trust is an emotional thing which can *possibly* be evaluated by considering both trust-givers (plural) and trust-receiver.
If you could determine the trust of an individual, would that individual be able to take that trust value into another system, or would a new trust value have to be recalculated from interractions with the members of the new system?
For example, how much "tallness" do I have? I have a constant "height" of 5' 10" when I am in the UK and also when I am in Australia. But when I am in Australia it could be argued that I have less "tallness" than I do when I am in the UK because the average height of British men is about 1/2 of an inch less than Australian men. So therefore I could argue that I am less "tall" in Australia than I am in the UK. In this sense, "tallness" is relative to one's environment.
You come out with some decent ideas which could possibly have some value, but you do not actually do anything about testing them, or show us the details of them with some legible working such as I showed. If each time you post a message we are left to guess about your method, then we cannot be expected to debate with you.
I have absolutely no problem with accepting *proper* criticism. I would not be taking part in this so called debate if I had. But it is very frustrating when you make criticisms and do not offer much in the way of explanation apart from your speculations and opinions.
Since you have not posted any legible description, or organised summary, of your method, how can you expect anyone to adopt it?
Dave
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The calculation of a trust ratio is very flawed. The true value of the system is to determine the trust of an individual (or company or call it what you will), not to determine how much that individual can be compared to others grouped with him.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
That is your opinion and you are entitled to it. I am still waiting to see how you will achieve it.
The global type averages are based on the trust that members in the system actually receive according to the axiom which we are supposed to be adhering to. Therefore, in theory, we can calculate an ideal trust from the collective of the system, and compare any particular member of the system with it.
When you propose "determining the trust of an individual", can you tell me something about how you would achieve this?
Do you think that just because your best mate trusts you by 0.99, that I should place the same amount of trust in you?
Sorry, but trust is not an attribute of a person like eye colour, which you can carry around with you. Trust is an emotional thing which can *possibly* be evaluated by considering both trust-givers (plural) and trust-receiver.
If you could determine the trust of an individual, would that individual be able to take that trust value into another system, or would a new trust value have to be recalculated from interractions with the members of the new system?
For example, how much "tallness" do I have? I have a constant "height" of 5' 10" when I am in the UK and also when I am in Australia. But when I am in Australia it could be argued that I have less "tallness" than I do when I am in the UK because the average height of British men is about 1/2 of an inch less than Australian men. So therefore I could argue that I am less "tall" in Australia than I am in the UK. In this sense, "tallness" is relative to one's environment.
You come out with some decent ideas which could possibly have some value, but you do not actually do anything about testing them, or show us the details of them with some legible working such as I showed. If each time you post a message we are left to guess about your method, then we cannot be expected to debate with you.
I have absolutely no problem with accepting *proper* criticism. I would not be taking part in this so called debate if I had. But it is very frustrating when you make criticisms and do not offer much in the way of explanation apart from your speculations and opinions.
Since you have not posted any legible description, or organised summary, of your method, how can you expect anyone to adopt it?
Dave
Upvote
0
A
amo crafts
That is your opinion and you are entitled to it. I am still waiting to see how you will achieve it.
To end your wait, I'll repeat what I wrote at the end of post #74:
In my opinion, a route finding algorithm is required here, and I would suggest using a heuristic of a combination between the number of paths from a node (shortest route) and the trust in the node information (trust of route) -- weighted according to the user's preferences.
There is little point in deciding which heuristic to use at this point in time, choosing one over another is rather elementary at this stage.
When you propose "determining the trust of an individual", can you tell me something about how you would achieve this?
See above.
Do you think that just because your best mate trusts you by 0.99, that I should place the same amount of trust in you?
No. It would depend upon how much trust is applied to the intermediates, as suggested by Duane.
Sorry, but trust is not an attribute of a person like eye colour, which you can carry around with you. Trust is an emotional thing which can *possibly* be evaluated by considering both trust-givers (plural) and trust-receiver.
Did I say it was such an attribute?
If you could determine the trust of an individual, would that individual be able to take that trust value into another system, or would a new trust value have to be recalculated from interactions with the members of the new system?
That would depend upon whether or not the trust value determined by the system was relative or not. Going back to my example of monks and criminals I made in a previous post, then I showed how much the (relative) trust values would be altered by putting the two groups together. Outside of the system, if a group of friends move from one area to another they would still place the same amount of trust in each other (i.e. their trust values would remain the same). If the trust values are relative, then those would likely change with a strong possibility of either converging or diverging.
You come out with some decent ideas which could possibly have some value, but you do not actually do anything about testing them, or show us the details of them with some legible working such as I showed. If each time you post a message we are left to guess about your method, then we cannot be expected to debate with you.
Route finding is a tried and tested, well understood technique. I'm not trying to invent the wheel here. I've never sat in a design meeting, or even worked for a company, where prototypes where built during the preliminary design stage. In fact I prohibited such practice in my teams to prevent emotional attachment, and for the same reason investigative work into new technologies was only done on non-related exercises for that same reason.
I have absolutely no problem with accepting *proper* criticism. I would not be taking part in this so called debate if I had. But it is very frustrating when you make criticisms and do not offer much in the way of explanation apart from your speculations and opinions.
Is this written in an attempt to insult me? I've given proper criticism. Even if no alternative is suggested, anyone is free to voice their opinion of whether they believe a system can work or not. In fact, the biggest problem I have with the system is what I have already said, it is not scalable. It will work with five nodes, but as that number increases the processing time taken to perform the calculations will get out of hand.
Since you have not posted any legible description, or organised summary, of your method, how can you expect anyone to adopt it?
As already mentioned I suggested a common technique for this kind of problem. Part of the beauty of tested techniques is that they don't need describing each and every time, but if you would like an explanation I can oblige.
To end your wait, I'll repeat what I wrote at the end of post #74:
In my opinion, a route finding algorithm is required here, and I would suggest using a heuristic of a combination between the number of paths from a node (shortest route) and the trust in the node information (trust of route) -- weighted according to the user's preferences.
There is little point in deciding which heuristic to use at this point in time, choosing one over another is rather elementary at this stage.
When you propose "determining the trust of an individual", can you tell me something about how you would achieve this?
See above.
Do you think that just because your best mate trusts you by 0.99, that I should place the same amount of trust in you?
No. It would depend upon how much trust is applied to the intermediates, as suggested by Duane.
Sorry, but trust is not an attribute of a person like eye colour, which you can carry around with you. Trust is an emotional thing which can *possibly* be evaluated by considering both trust-givers (plural) and trust-receiver.
Did I say it was such an attribute?
If you could determine the trust of an individual, would that individual be able to take that trust value into another system, or would a new trust value have to be recalculated from interactions with the members of the new system?
That would depend upon whether or not the trust value determined by the system was relative or not. Going back to my example of monks and criminals I made in a previous post, then I showed how much the (relative) trust values would be altered by putting the two groups together. Outside of the system, if a group of friends move from one area to another they would still place the same amount of trust in each other (i.e. their trust values would remain the same). If the trust values are relative, then those would likely change with a strong possibility of either converging or diverging.
You come out with some decent ideas which could possibly have some value, but you do not actually do anything about testing them, or show us the details of them with some legible working such as I showed. If each time you post a message we are left to guess about your method, then we cannot be expected to debate with you.
Route finding is a tried and tested, well understood technique. I'm not trying to invent the wheel here. I've never sat in a design meeting, or even worked for a company, where prototypes where built during the preliminary design stage. In fact I prohibited such practice in my teams to prevent emotional attachment, and for the same reason investigative work into new technologies was only done on non-related exercises for that same reason.
I have absolutely no problem with accepting *proper* criticism. I would not be taking part in this so called debate if I had. But it is very frustrating when you make criticisms and do not offer much in the way of explanation apart from your speculations and opinions.
Is this written in an attempt to insult me? I've given proper criticism. Even if no alternative is suggested, anyone is free to voice their opinion of whether they believe a system can work or not. In fact, the biggest problem I have with the system is what I have already said, it is not scalable. It will work with five nodes, but as that number increases the processing time taken to perform the calculations will get out of hand.
Since you have not posted any legible description, or organised summary, of your method, how can you expect anyone to adopt it?
As already mentioned I suggested a common technique for this kind of problem. Part of the beauty of tested techniques is that they don't need describing each and every time, but if you would like an explanation I can oblige.
Upvote
0
Latest Articles
-
What Carphone Warehouse, Microsoft and Uber Have in Common: They Started in a DownturnThere's a comforting myth that you need a booming economy to start...
- Ozzy
- Updated:
-
What Makes a Small Business Actually Sellable?There's a question that a lot of small business owners never think to...
- Ozzy
- Updated:
-
Why Your Team Keeps Asking the Same Questions (And What to Actually Do About It)Every small business owner knows the moment. You're halfway through...
- Ozzy
- Updated:
-
At What Point Do Courier Losses Just Become a Cost of Doing Business?If you sell physical products online, you already know the feeling. You...
- Ozzy
- Updated:
-
What I Wish I'd Known Before Using AI in My BusinessSomewhere between the headlines promising AI will transform everything...
- Ozzy
- Updated:
