Proposal: User-selectable Gaia Hub UX

Browser
#21

I think we need to be careful about wording that is not quoted from the technical specification in the gaia docs. We are promising that there will be a validation of data writes per the gaia auth scheme.

This is an interesting point that Gaia itself doesn’t guarantee encryption – that appears to take place in blockstack.js and the mobile SDKs, correct?

I’m not sure whether the user needs to know exactly where encryption is handled in the stack, but it does feel when taking your point and @jude’s into consideration that we may risk over-promising if we mention encryption here at all (and especially by saying "all apps…will store your data 100% encrypted). At the very least, it seems we’d want to soften this to “apps can store your data encrypted…” so we’re not promising either that all or even some apps will encrypt data for a particular user, which may not be the case.

That said, I think it’s cleanest to remove the reference to encryption entirely for this release and think through more how we can provide better education and transparency surrounding encryption for end users in general. Ideally, when authenticating an application, users would know just what kinds of data will be stored for them and how (encrypted or public). But I’m not sure how we can communicate that effectively when apps evolve over time (post-authentication for previously registered users) and store different data in different ways for different users.

Perhaps this is another browser problem for @larry to help solve since the client itself could monitor Gaia activity and report the data being transacted, showing encryption status, etc…like an advanced evolution of browsers’ HTTPs status indicators perhaps. Perhaps the browser could even itself broker permissions e.g. prompt the user to approve storing images publicly into Gaia before allowing the app to do so.

#22

If/when it is possible, I’d be more than happy to write a migration script within Graphite. I would absolutely not ask users to create new Blockstack IDs.

1 Like
#23

If data is encrypted when stored, it is entirely up to the app developers at the moment, and therefore we should not mention it all. There is an auth scheme and data is stored as is. I would not say either at all. If some app developer is encrypting data they should advertise that on their app but it should not be mentioned by us at all.

2 Likes
#24

OK, I think “not mentioning this at all” is disingenuous. The topic comes up in this forum and elsewhere – is this data encrypted? It is a central question to the whole privacy/security. So, it should be mentioned — it should be a requirement that app developers indicate this.

And I’ll definitely be documenting that it is optional in the docs.

#25

The data is stored as is. This is straight from the technical specification. Encryption in transit is not the same thing as encryption at rest.

It would be disingenuous to tell people the data is stored as encrypted. If for example, people want to use an EBS volume, it stores data encrypted, but this is by design, left open to the choice of the user, and not within our scope of promises we make.

If we document it as optional, what will the options be? The options should be that the data is not stored as encrypted unless some app developer takes it on themselves to do so, or there is further configuration someone makes with their gaia setup between the hub and their ssl terminus so the data is delivered “as is” in the state the developer/app needs it.

Again, we should not be promising this. I can speak more about this when it comes time to document this but I am not there yet. I am working on the technical implementation. I am happy to work with both @moxiegirl and Mark and Jude, whom I have already confirmed this with to make some better technical docs, some clear separations about any automation or images we provide, as well as some documentation for entry level users. I think it might be more efficient to discuss iterations of technical documents when I produce them but they will be based of the current gaia docs, and fundamentally nothing will be different in the scope of what gaia offers currently when it comes to auth schemes.

Regardless, I am not sure how much of the technical docs are going to be used to educate the user at the first UI step we are making on sign in, or otherwise useful until migrations are done if the selection is made after sign in, for anything other than power users at this point. I have not synced on the UI for user selectable gaia hubs yet.

Overall, this conversation is useful, and indicative of the need for clarification. If the conversation is happening on our team, it’s happening elsewhere and needs to be clarified for the average user, which is fine and something we expected as we iterate on “user selectable” gaia hubs because we are bringing in more of the user awareness and prompting them to make a choice, so they need to know what they need to be aware of, and what choices are there, why and have some notion of how to pick the one that is best for them.

We do have an open engineering meeting and we can discuss further which is also something the community is welcome to be apart of.

1 Like
#26

It sounds like optional means optional for the developer using GAIA

The way I interpreted your original statement was not that there are options, but that it is optional for the application developer to implement encryption or not.

If that is correct, then an application user will need to take that into consideration before using an app that stores data on Gaia. This is what I would concern me, it is a buyer beware situation. We have consumer protection laws precisely because buyer beware doesn’t work very well.

2 Likes
#27

I agree. We can add in the docs that developers can encrypt the data, but that it is not guaranteed within the scope of gaia. We do say it clearly now what gaia doesn’t do, but we don’t explicitly say we don’t store data encrypted at rest just “as is”.

And to your note, it is important application users understand exactly what they are getting, which is why I want to make sure this is scoped and worded properly, even if the UI option flow and wording is not fully crystalized yet.

Noting optional configurations of data that could be implemented from both the developer and user side, and by doing that stating what we don’t provide, could help educate users, while maintaining the integrity of the scope of the technical specification of gaia.

#28

Happy to update that our in-progress pull request now has working username registration with a custom Gaia hub URL, and the browser will save profile updates to that custom hub as well.

Next steps are making this onboarding flow optional based on a special parameter in the auth request, following the flow that Mark described above.

You can preview with the same Netlify URL posted at the top: https://deploy-preview-1723–reporter-beaver-73821.netlify.com

I used a local gaia Hub, but the subdomain registration went through with the correct zonefile: https://registrar.blockstack.org/v1/names/hanklocaltesting.id.blockstack

1 Like
#29

Great news! Can you provide a link to the PR here? The Netlify URL you’ve posted doesn’t seem to work for me either, and Ken’s link in the original post here doesn’t lead to any apparent changes from before.

#30

I agree this is a “buyer beware” type of situation and it should be our job as a platform to give users as much information as possible to make intelligent decisions about which apps to use and how based on their handling of data.

Just how to give that information isn’t so clear, as this thread indicates. I’d be curious about what @jeffd thinks here given his onboarding studies, and perhaps we’d benefit from setting up some new wireframe tests that give us real-world feedback on various scenarios:

  • We show users how an app will store their various types of data upon authentication (e.g. photos will be private, follows public)
  • We show users how apps are storing their data during subsequent app usage (e.g. app just stored your photo privately, just shared your follow publicly)
  • We give users a data browser that indicates what data types are encrypted / private vs unencrypted / public (e.g. these photos are private, these are public)
  • We give users an option to download all their Gaia data in a ZIP file with instructions on how to unencrypt private data with their private keys

I’d be very curious to learn not only whether users understand these various modes of education and insight but also whether they value them. Our product thesis as a platform hinges on the belief that users will increasingly value this sort of information as a critical factor of their app usage (for dapps and perhaps one day, all internet-connected apps). But I don’t think we’ve done enough research yet to confirm just where the market stands at the end of 2018 here.

#31

Per the conversation in this thread about the risks of mentioning encryption without properly explaining it, I’ve removed the mention in the Figma file as shown here:

57
Screen Shot 2018-11-28 at 14.30.57.png816×1400 94.1 KB

1 Like
#32

This is good, and the link is fine. I can see how there might be some concern this wording with a link would cause confusion or otherwise increase the barrier sign up that has been discussed, but almost every sign up system with any option for advanced configuration has a link to “learn more” or an expandable “advanced options” so I don’t think this is too far out of the norm of most sign up processes.

One thing for feedback. I feel like we are not mentioning that people can host their own gaia hubs here, and prompting them that they must use some third party storage provider. Technically, they can be their own storage provider.

It is ambiguous though. Here we imply the storage provider is the company or perhaps the technology hosting the data, and in that context someone hosting their own gaia hub would also be using whatever brand/technology is enabling their own personal hardware. Therefore, it would still technically be a third party reference.

Despite this, If I were a first time user I would not get the notion here that one of the options for a storage provider was me if storage provider denotes the entity owning and hosting the technology storing the data (cloud company vs me vs cloud company tech vs my personal tech).

I don’t know what the alternative wording might be. I can think about it this week if noone has any suggestions, but I think it should be there, even if there is a link to “learn more”.

#33

One thing for feedback. I feel like we are not mentioning that people can host their own gaia hubs here, and prompting them that they must use some third party storage provider. Technically, they can be their own storage provider.

I agree this version doesn’t make clear self-hosting as an option. We could add text in reference to this or perhaps wait until we’re comfortable listing options in general (e.g. Amazon, Dropbox, Your Own Server, Other). The later case may be the clearest since the user will see (visually with logos?) exactly what they’re choosing between instead of just landing at a URL input as is the secondary path here.

1 Like
#34

Preview Link

There are no visual changes from before, everything looks the exact same. It’s all happening behind the scenes, we actually process your input and use that URL as your Gaia hub.

One way you can test this out is to go into the settings page, and you should see your custom Gaia URL in the “Gaia URL” section. You can also use the registrar link I added above with your new username to make sure the zonefile was set correctly.

1 Like
#35

Mark’s new copy/designs are up. I need to host my testing app, so that people can test this new onboarding flow, because it requires special auth request params. I’m working on that right now.

1 Like
#36

The number of users that do self-hosting is likely to be smaller than the set of all storage users. Moreover, this dialog happens at the point they are creating a new id. Does it make sense to throw a lot of choice into the mix at this point? Particularly a choice that is going to require set up activity to actually select the self hosting? We may be overloading this interaction to account for a minority use case.

1 Like
#37

I like this idea

#38

I agree. for now I’m fine for whatever the team decides. When we have multiple integrations available would be nice to list with icons if they choose another option.

#39

Ok, we have Mark’s designs implemented, and a live proof-of-concept to test this all out.

To test this, first visit https://gaia-test-app.netlify.com . This is just a sample app I’ve tweaked to help test this.

You can enter a URL in the input, and that’ll be passed as the “recommended Gaia Hub URL” if you click the second button. This gives you a different flow, as described in the designs.

If you click the top button, you’ll be sent through the flow, but without any recommended Gaia URL. You see a different design in that case.

1 Like
Blockstack Team Weekly Updates 12/3-12/7
#40

Does it make sense to throw a lot of choice into the mix at this point?

I’m not sure what choice we’d remove to simplify out the “self-hosting” path here. The “Learn more about storage with Blockstack” link that goes to documentation with information about self-hosting as an option?