App deployment via Gaia?

Apps Storage (Gaia)
#1

Have we ever explored the possibility of a system with which developers deploy their applications via Gaia instead of hosting them in a traditional (developer-controlled) way?

I’m thinking essentially that upon release, app code would get compiled and distributed to every Blockstack user who has authorized it, placed within their Gaia storage “locker” (aka their directory of data within the storage provider dictated by their Gaia hub) perhaps in a directory called “apps” and versioned (e.g. “/apps/acme/1.0.0”).

Assuming these are static web apps, they could get served out directly via the storage provider or Gaia hub via HTTPs. And they could be mapped additionally via BNS or DNS and perhaps served in a highly usable way by a specialized browser (a la @larry’s).

The main goal here is to remove user dependence on developers for app hosting. If a user starts investing time and content creation with an app, they don’t have to worry about that developer taking the app down, failing to renew their hosting subscription, changing URLs, etc. Just like buying a CD of old, the customer has the software available to them for all time (as long as they maintain their data locker).

This would treat app code as just another data type for which users gain control over. The code for apps they use lives alongside the data for content they create with them. And since the app code is versioned, they can theoretically maintain access to older versions and their benefits, even if developers continually update their apps. Users could choose, of course, to delete old versions of apps from their lockers as they choose. But that’s their choice instead of getting forced to upgrade every time there is a new release.

This would also relieve developers of the burden of hosting and maintaining the apps they build until the end of time. This is especially advantageous for side-project apps or experimental startups, where developers may want to make a bit of money but not take on the costs and risks of disappointing their customer base should they not have the capacity to host for years on end.

Such a model would also help us develop App.co into something much more akin to an App Store, in which you go to discover apps and download / install them (to your Gaia locker). Developers could set up GitHub and the like to deploy their master builds to App.co via an open protocol, and that process could ensure checks that the deployed code matches the open source code (and it’s security and privacy guarantees) as represented publicly online. Users would no longer have to question whether the hosted version of the app matches its repository. The hand-off serves as a security check.

What technical and design challenges might we face in accomplishing the above? Are there better models available to achieve the same ends for users and developers alike? How might this be easily prototypeable?

3 Likes
Closed Sourced Blockstack Apps
#2

App.co could definitely be a Blockstack app, and it could ‘install’ apps in your Gaia hub. That could be built, today, without any changes to the protocol. App.co would have to have some way of knowing where the app’s code lives, in a format that is viable for distribution. It would only work with client side apps that have published their compiled source code. You’d also need some “browser” for navigating between your apps, which could live in app.co, the current Browser, or some new form factor. There would also be technical challenges around updating the app’s code when the developer updates the app.

Sounds like a cool integration with NIL’s browser. You can view apps on app.co, and click a button to install locally.

#3

You could also use the BNS, which is heavily underused right now…

(think “stealthy.app” instead of “stealthy.id”, and the app pointing to the URL it’s located – which very well could be a gaia bucket).

Regardless, I like the idea, but there are a few issues, such as if the code requires server-side logic (or is php or something), or how updates will be propagated, but the former can be ignored (JS is the future!) and the later could be fixed with either inboxes or polling (as they are done on traditional systems).

1 Like
#4

Wouldn’t it be really cool if developers can use a CLI command to deploy their code to whoever wants to host it for a fee? We could have a smart contract(s) that do this. This would really be server-less from the developer’s perspective. And it increases the censorship resistance of Blockstack apps.

Imagine that after you finishing coding, you type one single command to invoke smart contracts that register a BNS name for your app and finds/pays hosts to serve your code. I guess one difficulty of this proving that the host served your code for a given time period. Which is getting into something like proof of spacetime that Filecoin is using.

1 Like
#5

I like what you’re getting at (the simple CLI tool), but why not just use your own Gaia hub?

1 Like
#6

You can definitely choose to use your own Gaia hub. But I see a few advantages of not doing that:

  1. You don’t have to setup a Gaia hub and figure out paying for storage/bandwidth
  2. Increased censorship resistance if you can simultaneously deploy to multiple servers to host your code
#7
  • Publish your app to (any) gaia hub
  • Publish a BNS name (myapp.app) with your app and a link to the Gaia Hub, as well as an index of files and hashes for said files (or just a link to & hash of an index.json and said index has links/hashes of all remaining files)
  • Allow users to “re-share”/copy/clone your app and re-host on their own Gaia Hub, while being linked via a subdomain of your “top” username (michaelfedora.host.myapp.app)
  • ???
  • Profit?

Files could be verified by a hash stored in the main BNS name. Now this is exciting!

2 Likes
#8

This is doable today with scoped authorization tokens – You (the developer) receive from me (the user) a scoped auth token that lets you write to any path under /apps/acme.

You can already fetch normal HTML out of a Gaia hub today. However, to build a Blockstack app deployed this way, I foresee the following challenges:

  • You need to use relative URLs in your app, since the app won’t know which storage provider it will be served out of. This is fixable with adequate developer tooling though.

  • The app needs to generate the right app private key on sign-in. This is challenging here since the Origin will be different for each Gaia hub. I have proposal open on the blockstack.js repo that would let developers publish their app under a BNS name instead of a DNS name, as @MichaelFedora suggests. We will need to tweak the proposal so the app does not need a DNS origin at all, but instead may be served directly out of Gaia (this is less of an issue for new apps).

When the developer makes an update, do they have to push a new copy to each and every user? Or can the authenticator simply check if a newer version is available and automatically pull, verify, and store the app into the user’s Gaia bucket on the next sign-in?

2 Likes