TLDR: weāre building a Heroku for DWeb to help developers integrate Blockstack into their apps easier. See Pinata for IPFS or OpenNode for Lightning/BTC for example
As Blockstack developers, we (Stealthy + Graphite team) have run into and solved most of the issues with integrating the SDK into multiple platforms (Web, iOS, android).
We want to help new and existing developers avoid the problems we have faced by offering them a simpler solution that has an HTTPS api endpoint for services. A few features weāre considering: simple auth, custom on-boarding, replicated storage, subdomain registrar, etc
We will be integrating this technology in Stealthy and Graphite products. If youāre interested in such a service, please answer a few questions here: https://simplysecure.typeform.com/to/XZaorm
Iāve been bouncing around some of these ideas in my head and am even working on something akin to the āreplicated storageā item (as far as I can tell). Iād love to solve all of those problems eventually but time and money are always an issue when working alone.
As far as questions go, is this funded, and do you need more developers? =)
Hi @prabhaav, This sounds interesting. I looked at heroku for the blockstack search indexer I use in my d-apps but decided to host this via docker on debian vm.
Like @MichaelFedora Iām very interested in helping with efforts to advance Gaia. I built a gaia admin side car a few months back that can administer gaia settings. What are your plans in this area?
What is it you mean by custom on-boarding?
Would love to help if I can - anything that helps the transition for users to blockstack is much needed.
Hey Michael! Not funded yet. Weāre still in the exploratory phase. We know that weāll be using what we build for our apps and have started stubbing out some code, but we wanted to get a sense early of developer interest.
Hey Mike! Custom onboarding, as we envision it, does two main things:
Provides a white label option for developers that allows them to keep their users in their own app. Weāve seen that having users bounce out to the Blockstack browser is confusing and lowers user trust.
Simplify the experience for the end user. While Blockstackās UX has come a long way and is the best in the decentralized identity business, itās still not good enough to land general consumers, especially if an app developer is trying to charge customers for their app. The experience that we intend to build would give users an experience that replicated what they are used to now while obfuscating all the key generation and management complexity.
Hey @jehunter5811 this is really important - I kind of assumed @larry or someone would be on this and imagined there to be some gnarly reason why it canāt be handled via ajax! Would be very up for helping / testing what you guys come up with.
Will the solution involve a fork of the existing browser code or something new?
We will absolutely welcome any testing and help we can get once this thing gets going. I appreciate it!
In a sense, what we are planning (and again, everything is still high-level architectural designs right now) could be considered a combined fork of blockstack.js and the blockstack browser. But the model will introduce completely new code.
Curious about your work on replicated storage? (Last I recall Blockstackās API has hooks wherein you can define replication and resolution behaviors but no default implementation.)
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).
