Gaia For Organizations/Teams

I’m looking at using Blockstack to create enterprise solutions for organizations to own their data. Such that employees use Dapps, that store data in a Gaia in such a manner that allows the organization to lock the employee out and the organization still be able to decrypt things.

Just brainstorming, For this to work I would either need there to be some type of scheme to give multiple users access to one Gaia, and control what they have access to inside the same Gaia and the Dapp to be able to support multiple users one Gaia. Or giving an “admin” Gaia user control to shut out the user’s access to that Gaia account and being able to go in and access the keys to access and decrypt everything.

Is there any work being done in this realm or even just conversations about this? Or would this come down to the Dapp developer to find some type of authentication manipulation to make this work? Is blockstacks stance on this to avoid enterprise solutions?

@jdbender128 could likely add perspective on this. :slight_smile:

1 Like

Hey there @ksparakis !

Woah this is a really awesome question, and totally a plausible use case for decentralized storage in the future. I haven’t heard of anyone using Gaia for this specific functionality, but there are some features that might make it possible.

Gaia does give you the ability to delegate write/read access using address-based access-control, but writes to URLs (/store/<address>/<file>) are allowed only if the writer can demonstrate that they control that address. Conversely, reads can be done by everybody.

I connected with someone on our engineering team that has a more comprehensive understanding of Gaia architecture, and he said that your idea isn’t directly possible. However, the ability to delegate write permissions might make something like this feasible.

He also suggested that you take a look at this pull request on the Gaia repo. Apparently, the primitives that they had originally used for collections might be helpful as well (putFileArchival and the like).

As for Blockstack’s focus on Enterprises, I think that our first priority at the moment is attracting passionate developers to the ecosystem to experiment, bug-squash, and build exciting tools & applications. A lot of blockchain projects think that a growth hack would be getting a big flashy partnership with a Fortune 500 company. We’re thinking in a more grassroots mindset. We want to organically incentivize developers to investigate Blockstack by offering a superior protocol, efficient programming language, and smart contract capabilities. Whether that appeals to Enterprises is up to them I think!

@jdbender128 Thank you for taking the time and investigating everything and giving such an in-depth answer! P.S. I checked out your personal website haha love it.

I have been evaluating using Gaia to build my startup idea on, and reaching enterprise customers eventually becomes the biggest point of profit I think for most startups. I love the Grass-Root approach you guys have taken. As apps built on your platform gain popularity so does the platform it’s self. It also brings the power of data privacy to the masses.

Building a startup idea on Blockstack has its difficulties, given how relatively new things are and scalability at mainstream levels hasn’t been proven. The thing I like is how things are open source though, I am assuming that if my startup/ any startup were to get big enough it would have the ability to help contribute and build these types of solutions into the platform.

I came up with a hackish workaround, but unfortunately, it’s centralized in a manner (bad, bad, bad lol) and security becomes a concern from my perspective.

The concept here being the organization has a program that creates and manages blockstack accounts/ids for its employees. The employees authenticate with this middle man, who then authenticates with blockstack and passes over the authenticated tokens and keys.

The issue with this solution is that it will require a very customized solution for how access to Gaia is achieved, kind of barring my users from using other Blockstack dapps given current authentication workflows. I believe even using address-based access-control would require some other type of authentication again to be a centralized solution.

Overall I think a blockchain/blockstack standardized solution would be the best for this use case.

If you have any more resources or documentation to point me into write/read access using address-based access-control I would love to dive into it! I’ll check out the pull request as well. I’m still in the early stages of understanding all parts of the puzzle of the current solutions available.

If you take any, one on one calls, I would love to chat! or even in a messenger :slight_smile: I have a slew of questions from my research into the platform.

It would be nice to find out more information about address access control, interested in this thing. Because all aspects are not completely clear

Love the diagram! Glad to hear you’re deep diving on this solution, and I think a centralized Blockstack ID administrator of sorts is an interesting idea.

Yeah, being in the testnet phase of Stacks 2.0, you are correct that things are relatively new and experimentation is crucial. The open source nature of our codebase does however encourage collaboration and sharing of ideas. We’re all in that stage of understanding the puzzle lol.

I’d say a great first step would be to pop into the Discord and share your proof of concept with some of our other community members. There are a multitude of other developers who have tinkered with Clarity, Gaia, and the testnet, and might have some insight into the particular use case you are proposing. They also love talking high-level implementation ideas such as this :wink:

Also happy to hop on a call and try to answer any questions you have about the implementation. Always love meeting community members! Feel free to grab some time on my calendar. Might have more luck in the Discord though as some of our Blockstackers have really been getting their hands dirty with Stacks 2.0, and may have experience directly pertaining to your use case!