FMS Trust System FAQ
What's the purpose of this trust system? Do we need it at all?
Your instance of FMS[1] operates like this (very simplified):
- FMS compiles a list of existing FMS identities[2]
- FMS iterates over the list and downloads each identity's messages.
At each step of this latter stage, FMS faces the following choice:
Do I download messages from this identity, or do I ignore them?
The answer is provided by a condition involving trust. If at any point all gets too confusing, get back to this and remember that the whole function and purpose of the FMS trust system is to provide the rules for making the above decision.
Trust is not about liking or disliking some particular poster. It's not about affording some person trust, in the sense of feeling you could trust them with particular details you would not share with others, or anything like that. It's only about FMS deciding whether or not to download some particular identity's messages.
- [1] Note that "FMS" can be used to refer both to the FMS program itself (instance) that runs on your computer, or to the messaging system as a whole, that is, the design of the system and the set of messages, identities and so on that float around on Freenet. Keep in mind the context.
- [2] There are mainly two ways for FMS to discover identities: New identities announce themselves (by solving captchas/puzzles), and successfully announced identities propagate through the exchange of trust lists.
Why wouldn't I want to download some user's messages?
If it could be guaranteed that all identities would only insert messages you'd want to retrieve, indeed all this would be unnecessary. But in decentralized and censorship-free systems as Freenet and FMS aim to be, things are not so simple.
A malicious user might, for example, use an identity to insert a high number of large bogus messages. (Unfortunately there's no way to determine that a message is bogus before you actually retrieve it.) Among possible detrimental effects, this might cause your instance of FMS to tie up an inordinate amount of resources retrieving and processing those messages. This is called a denial of service (DoS) attack, and there were in fact several instances of such attacks on Frost, where they successfully disrupted the operation of many boards for an extended time period.
Another identity might (more akin to commercial "spam") persistently insert unsolicited messages to inappropriate boards and/or at an inappropriate rate. Some may consider this kind of behavior an attempt at disrupting communications.
Some users might consider both the above situations to be examples of "spam" and therefore wish their instance of FMS to reject those messages. (Surely you'll be able to think of further scenarios that might likewise be termed "spam".) Another group of users, however, might object to the latter situation being categorized as "spam", and prefer to limit their rejection of messages to the hard DoS.
As we see, in the end there will always be some disagreement as to what kind of messages constitute "spam" and therefore shouldn't be retrieved. Experience has shown that it's just not possible to arrive at a common definition (this is also why it's pointless to think of devising a fully automated system that would enforce such a definition.)
Fortunately, as we'll see, the FMS trust system doesn't require you to accept any particular definition, and it doesn't force others' opinions on anyone.
Then let me just mark the identities I don't want to receive messages from.
In fact, on a first approach that's just what FMS does. But the FMS system goes a bit further than that.
You could just use trust you assign yourself (in FMS this is called local trust) to tell FMS whether or not to download a particular identity's messages (this is message trust as we will see later). The default behavior is for everyone's messages to be downloaded. In such a case, trust levels could even consist of a simple binary yes/no, instead of a (0..100) range.
The downside to a local-trust-only system is that every individual user would be tasked with the whole burden of assigning trust. If an identity starts inserting spam, every single user would need to individually mark the spammer down. And, of course, a user that doesn't mark down the spammer in a timely manner wouldn't avoid getting hit by the wave of spam.
One possible remedy could be a sort of "early warning system", perhaps a specific board where users warn each other of spammers.
FMS, however, goes one step further: it allows users to share their trust assignments with each other, and to have their own FMS instance take into account trust lists of other users. (A user's trust list contains all trust levels he assigned to other identities.) And all this happens automatically.
FMS allows you to tell your instance to use selected trust lists published by your peers.[3] You do this by assigning trust list trust to those selected peers. It also allows you to share your own trust list.
(Note that you can't be forced to use any particular peer's trust list, and you can't be forced to share your trust list. Trust levels don't propagate but on a voluntary basis.)
This way, your FMS instance can reject spam if your trusted peers rate down the spammer, even before you locally mark down the spammer yourself. The system is not perfect, but it is hoped this will somewhat limit the effects of the spam.
We can say the FMS trust system contains both a local component and a peer-to-peer component.
- At the local level, you rate your peers and assign trust levels yourself
- On a peer-to-peer level, you can share your trust list with others and use others' shared trust lists.
You can choose to trust more that one of your peers' trust lists, and the resulting trust level (peer trust) will be a weighted average of all. The trust list trust is used as a weighting factor in the calculation (see example of trust calculation). This is why trust levels need to be expressed as a numeral (0..100) rather than a binary yes/no.
- [3] Peers are other FMS identities. Don't confuse this with Freenet (darknet/opennet) peers.
Does this mean I have to constantly maintain my trust list?
Not necessarily. Some users routinely rate their peers' messages and trust lists and add informative comments. Some of them choose to publish their trust lists in the hope that their effort will be useful to others. Others very rarely look at their trust assignments, only updating their trust list if some problem arises (e.g. lowering message trust if an identity starts to spam). And there are any number of approaches in between. All these approaches are valid and all work. There's no single correct policy. You're free to assign trust to as many or as few peers as you like. You don't need to allow anybody to tell you how you're supposed to maintain your trust list. It's pointless anyway - if they don't like your trust list, nobody is forcing them to use it in the first place.
Look, I'm a new user and I just want to get on with things quickly, what should I do?
A newbie who strictly wishes to avoid spam and be sure that his instance isn't hiding any messages can do so with minimal expenditure of effort. Spammers can be spotted and locally marked down, and the Peer Maintenance page can be used to determine if any messages are unintentionally being ignored. If the number of "peers have sufficient message trust to download their messages" is equal to the number of "known peers", then you're certainly retrieving everyone's messages. If that's not the case, it could be intentional, if it is not, the matter can be easily investigated on the Peer Trust page. If the unwanted negative message trust originates from a trusted peer, the undesirable trust list can be detected and untrusted (by removing or decreasing the trust list trust).
What do all these different types of trust mean?
Your instance of FMS knows many other identities (peers), and various types of trust can apply to each. First, message trust and trust list trust:
- Message trust rates how much that peer is trusted not to post spam.[4]
- Trust list trust rates how much that peer is trusted to rate their peers sensibly.[5]
- [4] Where "spam" is simply messages one does want to receive, and it's pointless to try to reach an universally accepted definition of what exactly constitutes spam, as seen earlier.
- [5] Where "sensibly" is necessarily a matter of personal opinion, and it probably relates to your own definition of "spam" and the ability of the peer to correctly identify and rate down spammers.
Trust levels are expressed as a number in the range 0 to 100. A trust level of less than 50 is considered "negative" (a disfavourable judgment, i.e. distrust). Trust levels greater than 50 are considered "positive".
Then there's local trust vs. peer trust.
- Local trust is assigned to other identities directly by you. You set or remove those trust levels yourself.
- Peer trust is calculated by your FMS instance from trust lists retrieved from peers to whom you assigned positive (local) trust list trust.
The peer trust level is derived from peers' trust lists and is controlled indirectly by you through (local) trust list trust.
Peer trust is a single value calculated as a weighted average from the corresponding trust levels taken from each trusted peer's trust list. The (local) trust list trust is used as a weighting factor. The FMS freesite contains an example of trust calculation. (Note: FMS does not take into account trust levels from peers with no trust list trust assigned, or with negative trust list trust.)
Your FMS instance, therefore, holds four trust levels in all for each identity: local message trust, peer message trust, local trust list trust, and peer trust list trust. It may hold values for all of these trust levels, or some of the fields may be empty, or all of the fields may be empty. In database speak, the empty fields are said to hold the value "NULL".[6]
The word "trust" is sometimes used without a qualifier. In those cases, the context should make clear what kind of trust (message trust, trust list trust) is meant.
- [6] Note that "NULL" means just that, an empty field. It is not the same as a value of 0 (zero). It is not the same as a value of 50.
What do different message trust levels do in practice?
- IF local message trust of an identity is less than 50 OR peer message trust is less than 30,[7] THEN the identity's messages are not retrieved. In all other cases, the messages are downloaded as usual.
- ...UNLESS you configured FMS to let local trust override peer trust.[8] If that's the case, positive local message trust will always override negative peer message trust.
- [7] Those are the default thresholds. They can be modified via configuration options MinLocalMessageTrust and MinPeerMessageTrust, respectively.
- [8] Configuration option: LocalTrustOverridesPeerTrust.
What about NULL trust levels?
A non-existing trust level is neutral, it has no influence. If both trust levels are NULL, the identity's messages will be downloaded, as is the default.
Why should I, say, assign a positive message trust to an identity?
There are two angles to look at things, local and peer-to-peer.
Locally, the result of assigning positive message trust is pretty much the same as not assigning trust at all. The exception is when the positive local trust would override the negative peer trust and the corresponding config option is set to "true".
The peer-to-peer relevance is that if you're publishing your trust list, by assigning positive message trust you're sharing that opinion with the community (the identity is not likely to spam). If others choose to trust your trust list, that positive message trust may average with message trust sourced from other trusted peers and potentially balance out negative trust. The exact outcome will depend on the trust levels and settings in each case.
Why should I, say, assign a negative message trust to an identity?
Locally, that will cause your instance to ignore that identity's messages.
On a peer-to-peer level, in case you're publishing your trust list, you're sharing your opinion with the community (that identity is a likely spammer). Lowering an identity's message trust may contribute to a lower combined peer message trust at users who choose to trust your trust list. If combined peer message trust falls below the minimum threshold (default 30), the distrusted identity's messages will be ignored. Again, the outcome will depend on the trust levels and settings in each particular case.
Some people say that if I want to ignore some identity I should just mark him with a message trust level between 30 and 49, why is that?
Since the default minimum peer message trust threshold (MinPeerMessageTrust) for retrieving someone's messages is 30, a peer trust level in the range (30..49) would never cause the combined peer message trust to fall below the threshold at users who might be trusting your trust list. By applying negative trust level in that range, you would avoid any potential to cause the identity's messages to be hidden at other users, while still ignoring the identity locally. In any case, the only users potentially impacted would be the ones who chose to trust your trust list (in case you're publishing it). Anyway, how you decide to manage trust levels is your personal choice, just as others have the choice to use or not to use your trust list.
What do different trust list trust levels do in practice?
- IF local trust list trust of an identity is greater than or equal to 50 AND peer trust list trust (if any) is not less than 30,[9] THEN the identity's trust list is used in local peer trust calculations. In all other cases, the identity's trust list is not used.
- [9] Default thresholds. They can be modified via configuration options MinLocalTrustListTrust and MinPeerTrustListTrust, respectively.
What about NULL trust levels?
A non-existing trust level is neutral, it has no influence. If local trust list trust is NULL the identity's trust list won't be used by FMS, as is the default. Important note: if local trust list trust is not explicitly set to a positive value, the foreign trust list will never be used, regardless of peer trust list trust level.
Why should I, say, assign a positive trust list trust to an identity?
Locally this causes your FMS instance to include that identity's trust list in calculations to come up with average peer trust levels. The calculation procedure is outlined here. The local trust list trust level is used as a weighting factor.
On a peer-to-peer level, if you're publishing your trust list, increasing an identity's trust list trust may contribute to a higher aggregate peer trust list trust at users who choose to trust your trust list. The exact outcome will depend on the trust levels and settings in each particular case. Note that by itself this won't cause the other user to use that identity's trust list in peer trust calculations.
Why should I, say, assign a negative trust list trust to an identity?
To the local instance that makes little difference from not setting trust list at all: the identity's trust list will be ignored.
On a peer-to-peer level, if you're publishing your trust list, you're sharing with the community your opinion of the identity's rating behavior. Decreasing an identity's trust list trust may result in a lowered combined peer trust list trust at users trusting your trust list. If combined peer trust list trust falls below 30 this may result in that identity's trust list being ignored by those users. Again: the exact outcome will depend on the trust levels and settings in each particular case.
But how do I know a peer is trustworthy so I may trust his trust list?
The only way, really, is to observe how the peer rates other peers and/or looking around for others' opinions. You should judge for yourself and exercise prudence, ultimately it's your own personal decision to take.
Why does FMS have two types of trust, message trust and trust list trust? Wouldn't it be simpler to have a single trust level for each identity?
Those two types of trust have each a clear and precisely defined function and meaning. If I, for example, see a non-spammer, I may want to increase his message trust without at the same time having to trust his trust list (because I didn't yet review his trust list to determine if it's any good). Or, I may want to decrease someone's trust list trust without necessarily blocking his messages. So, I need two separate trust levels. If a single trust level is used, one either loses the peer-to-peer component of the trust system, or the two meanings become muddled in some way. "Trust" becomes vaguely defined. Ultimately you end up with users marking peers up or down because some guy "sounds cool" so he seems trustworthy, without a clear idea of the consequences of their decisions.
Do I have to assign trust to an identity before I can see their messages?
No. That wouldn't make any sense at all. If that were the case, there would be no way for new identities to have a voice, since nobody knows them beforehand, hence nobody would trust them in the first place. The default behavior, in the absence of trust, is to retrieve the identity's messages. Not retrieving is the exception.
Doesn't someone have to trust me so I can be seen?
No. See above.
Isn't the FMS trust system a kind of "community moderation"? Can't this lead to community censorship?
Not really. That's not a very adequate way to describe it. Let's explain why using an example.
Suppose FMS has 1000 identities. Let's say there are 3 identities I (User1) decide to assign high trust list trust to: A, B and C. My FMS instance will use those 3 trust lists for its peer trust calculations. What about the rest, 997 identities? They won't have any influence. The "wider community" doesn't have any say over what I end up seeing or not seeing.
Let's now say you (User2) choose to trust the trust lists of a different set of identities (D, E and F). The resulting peer trust your FMS instance arrives at would be different from the peer trust my instance arrives at. Your "view" of FMS would therefore be potentially different from mine. Again, the remaining 997 identities' trust lists don't affect User2, you, at all.
Hence, it's not a case of "I let my view of FMS be moderated by the community", but rather "I let my view of FMS be moderated by a selected group of moderators". The selection of which is done entirely by me.
