Social proofs: Anyone care?

I do think the proofs are still rather useful (changed my mind from previously!), and so having proofs required for GaiaHub configuration should still be an option – however, it would have to be implemented as a standard that is at least managed by the browser because it lies within the profile.json (but could be expanded to be modified/added to by third-party providers, kind of what @friedger was arguing for).

The proofs/interface still exist but the responsibility to add them is moved away from the browser towards the community. Removing them entirely would be moving backwards and would require the GaiaHub config option to be removed as well.

@MichaelFedora Yes, all the add, remove actions for proofs/digital claims should be managed by the browser and by the user. The user should be in control of which claims should be published. However, the signatures on these claims can come from any authority.

Gaia can then require that there are at least two claims signed by auth.blockstack.org or auth.socialproofs.org

1 Like

Or make it configurable to where you want the claims to be signed from. Decentralize that part too by either making a open-source socialproof API and/or make it part of the configuration of what proofs are required, i.e.

requiredProofs: [
  { url: ["auth.blockstack.org", "auth.socialproofs.org"], count: 2 }
]

or

requiredProofs: [
  { url: "auth.mywebsite.com", type: [ "github", "twitter"], count: 1 }
]

or even make it simpler with urls:

requiredProofsUrl: "auth.mywebsite.com/auth?type=['github','twitter']&count=1"

where it makes a POST request with the profile.json as the body…

Plenty of ways to have fun with this.

1 Like

Right – that option isn’t well-supported and using it will probably degrade the performance of a user’s Gaia hub significantly. I think that feature should be chopped, as it hasn’t been used at all at this point.

There seems to be strong consensus here that we take option #2 and move social proofs to their own page in the browser, perhaps under “Settings”. I’ve created an issue for that change here, so please add further comments regarding it specifically on GitHub:

1 Like