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
And if you have any questions, we (@jehunter5811, @alexc.id ) can answer it here!
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.
Sounds great, good luck - keep me posted!
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.
If you haven’t filled out the survey linked in the original post, please do.
Curious about your work on replicated storage?
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.
all of it—needs to be so simple the user never thinks about it . Complex and hard coding belong to us, simple belong to users.
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.
@prabhaav @jehunter5811 @hank ,
Have you guys tried keybase? https://keybase.io/ . It’s really cool!
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).