Social proofs: Anyone care?


#1

My understanding from chatting with the team is that the initial browser was released in a combined effort with our first token sale, and the social proofs were related to KYC.

Today, new users try to complete these social proofs because they are front and center on the browser profile (first thing a new user sees after creating a new ID). The proofs are often broken, new users complain, and tickets are opened. Here are a bunch of them:

We did a some qualitative user testing on the browser several months ago and we added in a few questions about the social proofs. The learnings were:

  • New users don’t understand what they are

  • New users don’t understand why they are valuable

Short term the value seems abstract and questionable. Long term, there might be some interesting use cases for proofs. After weighing the costs (user frustration and bug fixes vs. the benefits (?) I think we should consider:

  1. Remove social proofs completely, or

  2. Move social proofs to the settings panel.

Feedback welcome. If you disagree, would love a detailed breakdown of the use case and the value this is creating for your users. Thx :pray:


#2

Both 1 and 2 would be reasonable.

While 1 seems like the rational choice given that no one really knows why social proofs are there, I’d vote for 2 if you feel that there’s interesting use cases long term.

There’s also the use of people signaling that they’re using Blockstack (via Twitter/ LinkedIn).


#3

I have always been a fan of social proofs. Really, today, nicktee.id means nothing unless i can relate it things i have already built a reputation on (Facebook,Twitter, Github etc…), so people can prove its actually me. With that being said, Blockusign’s “Video Proofs” feature could help with attestations, although it does not support public unencrypted videos yet.


#4

I agree that they are largely useless, honestly, and that’s why I didn’t implement them in my extension (yet).

I do agree they could be useful – however why not have a third party app do it instead of the browser? This slims down the browser a bit and leaves handling the specialized stuff back to the community.

In addition, if number 2 was followed, then those issues would still have to be resolved… just moves it “under the rug” so people complain about it less.


#5

I am for 2) and furthermore, extend the claims to claims from the w3c verifiable claims working group. Here is a list of use cases for claims.

For the existing social proofs, I could imaging that a 3rd party service (based on the current code) could issue these claims, the blockstack browser would only add/remove/share any type of claims that the user received.

Edit: There is already the 3rd party service: proofs.blockstack.org. So, the browser could just manage any claims (Probably, they should be in a collection). If the claims are signed then the browser should verify the signature but not the proof it self.

{
  "@context": "https://w3id.org/security/v1",
  "id": "http://social.nasqueron.org/api/v1/statuses/101431046440239635",
  "type": ["Credential", "ProofOfSocialAccount"],
  "issuer": "https://proofs.blockstack.org",
  "issued": "2019-01-01",
  "claim": {
    "id": "did:stack:v0:1Mk9gNKVdeLsodtbtUssVJmJMRHaEa2hGF-67",
    "socialAccount": "@friedger@social.nasqueron.org"
  },
  "signature": {
    "type": "LinkedDataSignature2015",
    "created": "2016-06-18T21:19:10Z",
    "creator": "https://proofs.blockstack.org/jdoe/keys/1",
    "domain": "json-ld.org",
    "nonce": "598c63d6",
    "signatureValue": "BavEll0/I1zpYw8XNi1bgVg/sCneO4Jugez8RwDg/+
    MCRVpjOboDoe4SxxKjkCOvKiCHGDvc4krqi6Z1n0UfqzxGfmatCuFibcC1wps
    PRdW+gGsutPTLzvueMWmFhwYmfIFpbBu95t501+rSLHIEuujM/+PXr9Cky6Ed
    +W3JT24="
  }
}

#6

Keep it as number 2.
Removing it totally may cause potential issues in the future when you need those information again.


#7

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.


#8

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.


#9

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.


#10

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.


#11

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.


#12

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.


#13

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 proof.blockstack.org 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 proof.blockstack.org). Another user can then see the claim in the user’s profile and decide whether they trust the issuer, i.e. whether they trust proof.blockstack.org.

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?


#14

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.


#15

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

blockstack.org/addIssuer?key=value

and have it work the same way blockstack.org/auth?key=value 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…)


#16

Verifiable Claims. This is the way to go.


#17

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.


#18

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


#19

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


#20

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.