A member of the community posted this on the Blockstack slack:
https://tor.us/ - has anyone seen this? Curious if something like this can be done in blockstack. One of the challenges we face now is adoption - maybe this lets people create IDs in an easier way.
This is exactly why we have started work on this simplification framework. We donāt believe that users should have to meet us in the middle in terms of user experience. We have to come to them if we want adoption. That means, onboarding, authentication, storageāall of itāneeds to be so simple the user never thinks about it.
If you havenāt filled out the survey linked in the original post, please do.
Iām currently working on an alternative Gaia implementation that can have multiple backends at once (per-user), syncing between them as needed. I.e. have user A with dropbox-1 ([email protected] dropbox account), dropbox-2 ([email protected] dropbox account), and disk drivers, and user B with their own dropbox-1 ([email protected] dropbox account) and gdrive-1 ([email protected]), etc. Only issue Iām seeing so far is the amount of processing power and bandwidth neededā¦ haha.
I donāt know if thatās what OP meant by replicated storage, but itās storage thatās replicated, soā¦?
I donāt know if thatās what OP meant by replicated storage, but itās storage thatās replicated, soā¦?
Yep, replicated storage in the context of this project definitely means something similar, except we are initially looking at replication to IPFS. That way if a Gaia hub even becomes inaccessible, the code would automatically fall back to fetching the data from IPFS. There are other replication strategies we are considering as well.
I have often thought about a āwhite labeledā authentication flow, where you never leave the app. All of the code youād need exists in the Browser. My hunch for how Iād do it is something like this, assuming theyāve never made a Blockstack account before:
Ask for a username and password
Generate the 12 word seed
Register the subdomain
Derive the app private key and Gaia bucket
Then, you could give the user their recovery key, and tell them they can use the Blockstack Browser to make their account more āpermanentā, and give access to other apps.
Obviously this is just how Iāve been thinking about it, not the way it has to be done! I am really excited to see what innovation you come up with around auth and storage.
Very very similar to what weāre thinking. Combine a lot of what youāre talking about there with replication strategies that make blockstack apps far more decentralized than they are today and thatās essentially what we are working on.
We want a user to be able to log in even if Cloudflare goes down. We want them to be able to log in even if their specific Gaia hub goes down. We also want a storage hub host marketplace to arise out of this that would make it so that users can simply choose alternative hosting partners that offer different storage options than whatās offered by Blockstack PBCās hosted storage.
Most all of this is more long-term. Onboarding and authentication are primary goals, though.
Thanks Michael. The use case for a single user is clear, Iām curious what you had in mind for User A & User B in concertāi.e. is this a situation where they are sharing write privileges for a single bucket or an inboxing strategy? Do you have a specific application you are trying to cater to?
No ā the backend keeps track of the oauth tokens and such, so user A can only write to their backends and user B can only write to theirs, etc. (I developed something called a āmulti-driverā that can handle multiple ābackendsā to the same driver type, i.e. āuser-dropboxā). Itās best use-case is if one person or a small group of people (family, organization) uses a node, but given enough processing power and bandwidth, it could handle any number of people and backends (theoretically).
I am simply trying to finish what Blockstack started in regards to Gaia ā or rather, to try and fulfill the original goal in a different way. I wanted Users to be able to use their own Dropbox without having to spin up their own node and all of the complexity that doing so brings ā so why not have a psuedo-centralized service handle it all for them? And beyond that, why not have the ability to hook up multiple backends (as advertised in the whitepaper) that can replicate or be given to a particular app at the userās choosing?
If you want to get into blockstack easily, use this; if you are concerned about centralization but still want the ease-of-use this brings, run your own node; if you want to go as deep as you can, run multiple of your own gaia hubs and use a browser that supports that (if any exist currently).
Iām very concerned about Blockstackās ease-of(-end-user)-adoption, and so I developed this to help in some way, and I plan on making another service to help user registration and handling in another psuedo-centralized way, but that will probably only come to fruition if I can get sponsoredā¦ even doing this is quite unwise due to how big of a project it is and with how much time Iām spending on it whereas I could be getting paid elsewhere (but at least itās almost done!).
Thanks for the explanation and even more for the contributionāyouāre spot on about the ease-of adoption. Iāve had some amusing conversations with tech. people that had troubles getting onboardedāI canāt imagine the antics that regular folks undergo (though they seem to be getting on platform anyway, which is great).
Curious as to whether an app could do this with current Blockstack APIs or whether weād have to expand our functionality?
Also, would #1 be possible to drop / make optional ā skipping straight to 12-word seed generation from the start?
I think it could possibly help a lot for apps to register users directly inside of their UIs. But I also think itās vital that they understand fully that:
A) theyāre signing up for an independent (Blockstack) ID
B) the ID works across many apps
C) their ID and data is saved separate from all apps in a way the user controls
So, any in-UI integration needs to make this UX seamless but not invisible per se.
Its pretty much like an encrypted slack but they have a really user friendly auth flow where you never leave the app.
You basically choose a username and never leave the app. It creates a local private key (that the user can backup later if the user understands paper wallets) . But they encourage users to login to a second device via a QR code (this copies the private key to the second device).
As you may remember, we posted a question and survey on the forum a few weeks ago. We wanted to know if there was a general need/interest from the Blockstack development community for a better onboarding/authentication tool within the Blockstack ecosystem. The response was overwhelmingly positive and gave us all the validation we needed.
Graphite and Stealthy collaborated to build SimpleID, a library that allows developers to drop in a simple JS package (and eventually make simply HTTP requests from any environment). The benefit of this library is that developers can get up and running in literally just a few minutes. For the apps these developers build, users get the experience theyāve become used to on the web:
Sign up with an email, username, and password
Sign in with username and password
Even though the experience is exactly what users expect, the complexity behind the scenes is immense. That complexity, hidden from the users, and avoided by the developers using our library, gives end-users control over their identity, encryption keys, and login, all without ever revealing any private information to us. A technical write-up is coming soon, but we encourage you to visit the website to learn more today:
While we love the spirit of open source projects, this is a commercial endeavor. The library is open source, but will require API key generation and payment from the developer/app wanting to use it. We feel the benefit this provides the Blockstack developer community is well worth the $9/month base plan price.
First of all, I want to thank you and Justin for taking on the task of building on top of Blockstack, and seeking to improve the overall community. Third parties building on top of the Blockstack platform is exactly what we need in order to grow as a community.
There have been some questions about whether this qualifies for app mining. While this highlights the need to exactly define what qualifies as āBlockstack authenticationā, as a team we have determined that this current implementation does not qualify for app mining.
One feature that would get this closer to qualifying is some clear mechanism for being compatible with typical Blockstack auth using the Browser. If I start with SimpleID, can I later on use the Browser? Can I use the ID I registered with SimpleID later on in other apps? Can I start with the Browser, and later use SimpleID? Right now, it seems that none of these could be answered in the affirmative.
I think there are other concerns here, like whether the user has any idea that theyāre using a platform that provides a personal data locker and a self-sovereign ID that can be used in other apps. This is a less well-defined problem, which is why I think the above concerns are more immediate.
Again, we want to encourage 3rd parties on the platform. I am sure you would like to get to a place where SimpleID qualifies for app mining, and if so, then we can definitely work together to find a solution that we feel does qualify.
Thanks for writing this up, Hank. First, let us point out that SimpleID is actively being developed. Just like any of us here can post all of the things that Blockstack is missing because Blockstack is actively being developed, the same is true of SimpleID.
That being said, whatās possible as of today with SimpleID mirrors everything possible with traditional Blockstack Auth. Weāve just pushed an update to give users control to take an ID registered on SimpleID and use it via the Blockstack Browser. That was always in the cards and it was a matter of exposing the function. So done.
We also intend to allow existing Blockstack IDs to be used on SimpleID-based apps. Thatās a bit less of a priority, and in our eyes should not disqualify anyone using SimpleID from App Mining.
This particular issue strikes me more as one that should be communicated by developers as they see fit. SimpleID is intentionally un-opinionated. Blockstack Auth is very opinionated, so building an alternative that is also opinionated doesnāt make a ton of sense. It also puts a lot of centralization on the solution.
Now, letās talk about roadmap, both immediate and long-term. As mentioned, we plan to allow existing Blockstack IDs to sign into SimpleID apps. All user data (which consists of non-revealing pointer files) will be replicated to IPFS to ensure that if SimpleIDās database and server go down, users can still log in. Thatās a major goal of further decentralizing Blockstack, so this seems very much aligned with your goals.
Long-term, we plan to introduce user data replication. In addition to storage on the userās selected Gaia Hub, developers using SimpleID will be able to offer user storage replication to IPFS. We also plan to support custom Gaia hubs as well as simple profile.json updates. These two features alone will significantly extend the capabilities of Blockstack and we think developers and users of apps built by these developers will benefit immensely.
Iām not sure what other information is necessary for you all to make a decision on this being something developers can use in app-mining-eleigible apps, but I do want to leave you with a post in which @muneeb himself confirmed that third-party auth built using Blockstack would be acceptable:
I took a look at the code for Simple ID. I just want to make sure I understand one thing correctly ā is the 12-word seed generated from a user-given password? If so, then I cannot overstate how dangerous this is. Passwords do not have very much entropy, and given that your ID address is public knowledge, itās trivial to build a rainbow table of all plausible password --> address mappings and guess peoplesā seed phrases offline.
No, the 12-word seed phrase is generated exactly the same way Blockstack generates it today. The password encrypts the seed phrase (just like the Blockstack Browser does today).
Great to see this work here and especially to see a commercial ID solution in our ecosystem!
RE qualification for App Mining, there are many considerations here. We want to be thoughtful and make the best decision for both our users and App Miners. I trust the App Mining team to work through all the angles and reach a decision.
As always, Github or this forum remain the best place for discussions.