Social proofs: Anyone care?

Don’t get rid of them completely. A core component of decentralized identity is the ability to tie that DID back to something that proves who you are (if you want). Social proofs aren’t great for this, but they are useful.

So number 2 is my vote.


I don’t think @jeffd is proposing getting rid of DIDs. Also, DIDs are supported as a first-class identifier at the protocol level, so even if the Browser ceased providing social proofs, Blockstack Core would still give you a name’s DID and let you resolve profiles by DID.

Oh I know. What I meant is that DIDs are often only useful if they can verifiably be traced back to the person claiming to own them. Proving ownership of the private key is fine, but the idea of attestations as a way to help prove real-world identity is a more approachable concept for most people.

My intention is to move the responsibility for these kind of real-world identity attestations away from the blockstack browser and only let the browser provide a simpler and more general functionality.

Yes, this is a good plan. As long as there is a replacement. The browser is super powerful in terms of being the only web interface that can write to a user’s profile. There’s a lot that can be done with this and it’d be cool to see a stand alone product that accommodates updates to the profile, including attestations/proofs.

The problem with moving social proofs out of the browser is that you need to use your master keychain when updating your profile.json, which is how you ‘broadcast’ your social proofs. So, you’d have to trust a third party app with your master keychain, or we’d have to build a separate app (seems like a bad use of resources for something that doesn’t get much use).

I’d vote for moving it out of the main ‘IDs’ page. Although their current form is not useful, I do think there are some cool services that could be built with social proofs.


The thing about verifiable claims is that is does not require the master key of the “subject”/user. It only needs the master key of the issuer. If is the issuer then it is their master key.

Then the subject decides to publish this claim via the blockstack browser (e.g. by importing a file from the user’s gaia storage of Another user can then see the claim in the user’s profile and decide whether they trust the issuer, i.e. whether they trust

This gives more control to the users about what social accounts to publish in their profile and it open doors for other apps to issue claims as well (like “Graphite ranked 1st in Jan 2019” issued by Blockstack PBC, or “Friedger is CEO of OpenIntents”, issued by OpenIntents)

If we want to enable users to sign their own claims then there is a discussion around the master key/ownerKey signing at How to communicate signing keys?


I agree entirely with you. The master key should be used only at the user’s discretion. And social proofs do not necessitate its use.

I just don’t want to see that functionality go away from the browser unless there is a viable alternative. Seems like it’s not going to go away though.

technically you could move it to it’s own URL, something along the lines of

and have it work the same way works currently. It would allow the browser to still handle social proofs but would allow third party apps/etc to expand upon the availability of such proofs… don’t know how it would totally work because there’s no standard way to do it (like oauth or something – the facebook issuer thing is different from github which is different from pgp, etc), but it’s a start.

definitely prefer to have the functionality moved out of the browser though, as I mainly argue for this because I want the browser to be smaller in scope so it doesn’t run “out of date” easily; if it just focuses on authentication and bare-bones-but-replaceable profile management/app launcher/social proofs management it becomes much easier to handle then an app which is trying to do everything.

(it also means, as the producer of a third party browser, that I can do less work and leave more to the community which can create much better software then what I can dream of doing alone…)

1 Like

Verifiable Claims. This is the way to go.

I’m a fan of option #2. It won’t seem like you “have” to do it, but more interested Blockstack users will find it and will want to round out their profile. Lots of good points above which I agree with most. Getting rid of it entirely seems extreme.

I support option 2, however it should not slow down the work of a browser. Or maybe it is possible to develop a special app for that

I vote for 2 option. Social proofs are necessary to be.

1 Like

There is a proofsConfig.proofsRequired option in the Gaia hub configuration. @aaron not clear how that config option would work without the social proofs in the browser.

1 Like

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 or

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: ["", ""], count: 2 }


requiredProofs: [
  { url: "", type: [ "github", "twitter"], count: 1 }

or even make it simpler with urls:

requiredProofsUrl: "['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