The app key you mention is the user private app key, i’m thinking about the dapp itself, if it would like to sign attestations, like you guys mention in one of your docs on the topic in github
No, we don’t have a notion of application attestations, though such attestations can certainly be built by developers on top of the platform.
Yep – that’s correct. If an application wishes to have an authoritative application key, they should register a Blockstack name for the application, and use the owner key of that name.
To be clear though, there’s definitely a lot of room to implement many different attestation schemes. Blockstack’s software and client libraries don’t make many assumptions about the contents of your profile or Gaia hubs. If you have a good idea about how to implement attestations and want to do so as a 3rd party library, I’m sure you’ll find interest from this community
Well I would argue that the best place for attestations is the user profile.
I’m not very familiar yet with how files work on blockstack.
It would help if you can clarify a bit about the internals.
Where is the user profile stored?
Who has access to modify it?
Do I need to create a separate profile for my dapp?
is the concept of a global file for attestations that is appendable by many apps is feasible?
It’s stored in a Gaia hub. The specific URL is anchored to the Bitcoin blockchain by a hash. You can see the URL in the zonefile key in the object returned from the /v1/names endpoint on core.blockstack.org:
(the zonefile_hash is the hash160 of the zonefile, and is written to the blockchain on name registration)
Who has access to modify it?
Only you can modify it. The signature on your profile is checked against the public key address that owns the name’s blockchain. In this example, only the owner of the private key for 15gxXgJyT5tM5A4Cbx99nwccynHYsBouzr can generate a valid profile.
Do I need to create a separate profile for my dapp?
Only if you intend for your dapp to have a Blockstack ID and profile that other non-dapp users can read. For example, if you want the dapp profile to show up in the Blockstack explorer, the profile object itself needs to be a JWT signed by the private key that owns your dapp’s Blockstack ID. The profile JWT’s payload needs to include a URL to an avatar image and list of zero or more social media verifications. There’s a description of what this JWT is expected to look like here.
is the concept of a global file for attestations that is appendable by many apps is feasible?
Can you describe more about what you’re trying to build? It’s possible today to create a materialized view of a global file appended to by many different apps, but the individual attestations may live in each app’s (or each user’s) Gaia hubs.
You described the name registry profiles. While I was talking about user profiles on id.blockstack, such as https://core.blockstack.org/v1/names/hadar.id.blockstack
These are called subdomains right?
This is the user profiles that logs into my dapp. This profile has social network proofs. I would like to add to this profile more proofs or attestations(that i verified the user passed captcha for example) signed lets say by my dapp, gooddollar.id (doesnt exists yet)
If a gaia file is controled by the user, how can I ask him or get his permission to modify it? or I can simply use the files api to do that? (ie change the hadar.id.blockstack profile file.)
This is the user profiles that logs into my dapp. This profile has social network proofs. I would like to add to this profile more proofs or attestations(that i verified the user passed captcha for example) signed lets say by my dapp, gooddollar.id (doesnt exists yet)
You don’t need to modify the profile to achieve this. If you store your signed attestation as a file in the user’s Gaia hub, then your app will be able to load and verify it once the user signs in.
It sounds like this might work for your use-case:
When the user signs in, the first thing you do is check whether or not they have passed the captcha test (or whatever test you have). You do this by calling getFile('your-captcha-attestation') and checking that the contents are signed by your key. If so, then the user can start using the app.
If not, then your app would present the user the captcha test (served by a server you control), and when the user completes it, your server would sign the test result to create the attestation. Your server would send the attestation back to the app.
When your app receives the signed attestation, it uses putFile('your-captcha-attestation', attestation_data) to store it in the user’s Gaia hub. Then, when the user signs in again, the call to getFile('your-captcha-attestation') will return the signed attestation and the user can proceed to use the app.
If a gaia file is controled by the user, how can I ask him or get his permission to modify it? or I can simply use the files api to do that? (ie change the hadar.id.blockstack profile file.)
You can simply use the file APIs. Your reads and writes will be sent to the signed-in user’s Gaia hub automatically.
For question #1, if you’re attestation file is not encrypted, it’s a simple matter of passing the other dapps a URL (typically done by lookup to your dapp’s GAIA bucket along with a relative path to your attestation file).
If the attestation file is be encrypted, then you need access to the public key of the dapps you wish to share with or a mechanism for creating a general purpose shared key pair. Stealthy Protocol is working on a solution to this exact problem to enable on-the-fly sharing of encrypted content between dapps.
Here’s how it would work:
Both dApps incorporate Stealthy components for messaging and decryption
The attestation file would be written and stored with your dApp’s encryption
Your dApp code could choose to message the other dApp (or it could message you) to send the attestation (or request the attestation)
Stealthy would prompt your dApp to read the attestation and decrypt it, would then encrypt it using the other dApps Stealthy public key, and transmit it as a message.
The other dApp upon receiving the message would receive it and be able to unencrypt it.
Tentative timeline for this is later this year (i.e. late Q3 / mid Q4). There’s a lot of moving parts to sort out.
As for question #2, modifying files your dApp did not create, I’ve seen multiple discussions loosely related to the subject under the term multi-player write and another one under ‘open membership hubs’.
Ultimately the user is in control of all storage no? so he should be able to give permissions.
Stealthy is designed as a p2p app? or it needs a centralized server to facilitate the communication between apps? (ie push notifications to check if a a request arrived)
Ultimately the user is in control of all storage no? so he should be able to give permissions.
That’s being discussed (permissions). Presently each app has it’s own bucket and encryption keys and is only capable of allowing other apps to read from it’s bucket (not write to it). Two mechanisms may extend this (inbox proposal, membership hubs).
Stealthy is designed as a p2p app? or it needs a centralized server to facilitate the communication between apps? (ie push notifications to check if a a request arrived)
Stealthy is a protocol for app to app and person to person communication. The messaging client Stealthy.im is built on that protocol. p2p is used for both offline and realtime data transfer. The client also offers optional centralized convenience features (i.e. for push notifications or discovery). Eventually these will be replaced with decentralized equivalents.
Notably, the desktop Stealthy IM client establishes WebRTC connections in a completely decentralized fashion (full decentralized SDP handshake).