From reading the proofs client library and looking at the examples, it seems like validating a proof strictly depends on validating some encapsulation (like a profile)? I say this as I could easily copy the tweet from the naval twitter handle, post it in a new malicious handle of my choosing and the proofs library would return valid: true. There does not seem to be any content in the proof itself which I could use to independently establish trust of the proof. Is that correct? If so, is there a reason to extract the proof library from the profile library?
Yes that’s true, it requires knowledge of the profile format. That’s actually a good case for combining the proofs library with the profiles library.
@muneeb@larry Think this combination is a good idea? These two are tightly coupled, as opposed to say, the profiles library and the zone files library, which are independent of one another.
Perhaps create a blockstack-identity library for each language that holds everything one needs to do all things related to the Blockstack ID application of Blockstack?
On the other hand, it seems like a matter of taste. Smaller, focused libraries vs monolithic libraries might be easier to work with. There are lots of services we will add to the proofs library and the benefit of having a clean API between it and the profile package is it might be easier for people who’d like to contribute. Even if the two are combined these into one library we’d still want to keep the separation of concerns internally.
You could do this but you’d just be tricking yourself. The preconditions of the proof libraries are that you got the profile from a trusted source and that it is in the proper format.
@wanderingbort is correct in that there is nothing in the proof by itself that lets you independently validate it as correct. It is simply contains pointer to a name. The profile is a pointer to an account identifier. You have to trust both of these pointers for the result of the proofs libraries to be useful.
You trust the profile pointer because proofs libraries assume you got it from a blockstack node you trust. You trust the proof pointer because you retrieved it yourself from the service. If you modify either the profile or the proof all you’ve proven is that you can’t trust yourself.
I like this. We can rename blockstack-profiles and roll in blockstack-proofs.
There definitely are two ends of the spectrum. However, generally it’s a good idea to combine libraries that are tightly coupled, and that definitely applies here. In addition, it’s a good idea to separate libraries that people will want to use as separate components, which does not apply here.
I’m in general a fan of having fewer separate packages in Python, as I’ve seen unintended consequences and longer debug cycles. In this particular case, I’m fine either way. The current separation isn’t really broken and is working fine. Making a new blockstack-identity package will require updates in a bunch of other packages. The new combined package can work better in the long run and looks like a “nice to have” to me.
In my opinion, that precondition is not communicated anywhere as part of the library’s documentation or API. Moreover, the library is currently positioned as a validation library and yet it only validates the least important part of the proof (the textual structure of the message) leaving out the cryptographic authenticity which, it cannot determine without knowledge of how the proof was sourced. My concern is that this becomes a “trap library” for application developers who find it in their package manager(s) and use it without understanding it.
While combining the proofs and profiles libraries is not an ideal situation, it does make it easier to do the “right” thing for application developers. There is some value to that for the top-level libraries you provide for those developers as misuse will negatively reflect on your ecosystem as well as the applications.
I see no reason that internally, it cannot remain a separate utility library.