Deduplicating Stamps
Why is deduplication necessary?
Stamp deduplication is a crucial feature that prevents users from amplifying their influence over some specific outcome by submitting the same Stamps across multiple Passports.
It is important for users to be able to hold multiple Passports representing different user profiles that might be used to as identification in specific communities. However, without deduplication logic, this could allow users to repeatedly attach the same Stamps to multiple Passports, fooling an app into treating each Passport as a real, verified human.
Deduplication ensures that a user can only associate an individual Stamp to one single identity within a specific context.
Do you need to handle deduplication in your app?
If your app uses a Passport default Scorer, then deduplication is already handled server-side. When you request a score through the API, we calculate scores after already deduplicating Stamps, meaning you don't have to implement any deduplication logic yourself.
However, if you are using your own custom scoring mechanism based on Stamp data, you will have to implement deduplication for yourself. Each Stamp has a hash field that can be used as a unique identifer. You can store hashes and compare them across all your users' Passports to ensure they are not being used multiple times. Our Scorer uses a Last-In-First-Out mechanism to handle duplicates, but you might want to use your own algorithm in your custom Scorer.
How does Passport XYZ handle duplicate Stamps?
Passport handles the issue of Stamp duplication by automatically identifying and eliminating duplicate Stamps. This prevents users from using the same credentials to verify their Stamps and identity across multiple Passports. This ensures that each user in an application has a unique and consistent digital identity.
By default, the Passport API uses a Last In, First Out (LIFO) Stamp deduplication method.
This means that, in a given scoring instance, if a Passport holder submits a Stamp that has already been submitted by another user, the duplicate Stamp is ignored and not counted towards the score.
For example, let’s say you build an application that uses the Passport API to verify the unique humanity of your users. Two Passports, “Passport A” and “Passport B,” present the same Stamp based on the same Twitter account. In this scenario, the Last-in-First-out deduplication method would only count the Stamp instance that was submitted earliest, ignoring the one that was submitted later.
For example, if Passport A submitted the Twitter Stamp first, followed by Passport B, your app would only count the instance of the Twitter Stamp submitted by Passport A. The same rule applies to any subsequent instances of the Stamp.
This LIFO method ensures that each Passport’s score accurately reflects the unique identity of its holder. This prevents duplicate Stamps from skewing the verification process and prevents users from re-using evidence of personhood across multiple Passports within an application.
Things to note
Stamps are unique to scoring instances. For example, one user uses Passport holder A with one Twitter account in an application that uses scoring instance X, and another user uses the same Twitter account in a distinct Passport in an independent scoring instance Y. In this case, both users will get scored for the Twitter account. As long as the scoring instances are independent, there is no concern for double counting or interference between instances. This allows users to create multiple personas that they use in different contexts but prevents double-counting of their credentials within a context.
The scores assigned to Passports will not change once they are issued. This means that there is no need to recalculate Passport scores or synchronize them again in case of duplicate Stamp submissions. Once a score is assigned to a Passport, it remains fixed and can be relied upon for future verifications, even if a duplicate Stamp is submitted by a new Passport. This makes the scoring process more efficient and streamlined, which is particularly important for large and complex applications that score a high volume of verifiable credentials.
Also note that because Stamp deduplication is achieved using a 'last in, first out' model, it is possible for Passports with identical Stamps to return different scores from different Scorers. The reason is that if the identical passports A and B are submitted to Scorer 1 in the order A,B, the returned score could be different to the same Passports submitted to Scorer 2 in the order B,A, because different instances of duplicate Stamps would be removed.
Summary
The LIFO deduplication strategy has several benefits for Passport holders and developers. It ensures that each Passport holder (in other words, Ethereum address) is assessed based on their unique set of Stamps, and that no one receives an unfair advantage due to having the same Stamp as another Passport holder within a given scoring instance. This means that for applications using the Passport API, there will be no double-counting of Stamps within the app, ensuring a fair and accurate assessment of each user’s unique identity.