Separate username.fission.name from app-name.fission.live

[bnchrch]

Dependant on #218

Summary

Essentially we want users to own a tld that includes their username and also be able to register app names arbitrarily.

Extra context

_Taken from: https://talk.fission.codes/t/platform-users-apps-and-domains/362/10 System Requirements

1. Users should be able to create apps with no restrictions on the name (other than is it already taken)
2. Users should be able to own their username as a fission url
3. Users should be able to connect their data to apps with a familiar url
4. When a user types fission register this should be the begining of their fission drive and fission identity

What is Fission Drive: It would start as a place to store your own personal data.

1. Your personal files and folders. Public and private.
2. App data both public and private. (Think a URL you can use for diffusion)

Then would evolve to also include a default app by us. Fission Personal Homepage (outlined here: https://talk.fission.codes/t/the-users-sample-apps-platform-features-triangle/368?u=bnchrch)

What did this inform Since the usage of Fission Drive and the usage one off Fission Apps are different despite the underlying tech. And that items #1 and #2 from System Requirements are in conflict when using the same TLD. We thought it would be good to separate the two into separate TLD's.

Problem

A user needs to register multiple accounts to allow for multiple apps

Impact

Solution

1. Move *.fission.live from hexonet to route53
2. update fission register to assign username.fission.name to the user
3. update the POST /app route to provision new apps under app-name.fission.live

Concerns

@expede what would the best way to modify the heroku addon to work in this paradigm be?

[bmann]

The Heroku add on needs to have a token. And generally — any remote systems need to work similarly? Needs discussion about how this should work.

[expede]

Paradigm

@expede what would the best way to modify the heroku addon to work in this paradigm be?

Well, it depends on the goals for the Heroku add-on, and VERY MUCH depends on how far down the rabbit hole we want to go 🕳️🐇

Disclaimer: This change makes the Heroku add-on strategy a bit fuzzier, and I feel like we may want to clarify the types of experiences that we'd like users to have with it

Leave Heroku As-Is

On one extreme, we leave Heroku as-is, and treat each provision as a single-app user, and have them authenticate with basic auth. We then simply ignore the fact that this user could have more than one domain name, and they don't really use their username.fission.name.

Maximum Change

At the other end, The Heroku docs could be clearer, but AFAICT we're never given an identifier for the user, but only each Heroku application. We could do a many-to-many by provisioning outside of the Heroku CLI/marketplace (e.g. we build our own web portal or give Fission CLI instructions), and give them credentials that way.

Either Case

In either case, we're using a Heroku provisioning request as a replacement for fission register in the Heroku scenario. They can use keys from outside Heroku, but that largely defeats the purpose of having an addon.

By default all that we're given in a Heroku provisioning request is the Heroku app name, a UUID, and an initial OAuth Grant to generate the first refresh token from (plus some metadata like which geographic region they're in). We can ask for more data (e.g. ancustom username) as an part of the flow, and fallback to the app name otherwise. Adding fields does add some minor friction to the process, and I've been sent to hunt through docs to do this on Heroku before. We don't get particularly amazing hooks into their CLI. But unless they have credentials already from some other flow that they're willing to copy/paste in, we have no way to separate a Heroku app from a Heroku user.

[expede]

Token

The Heroku add on needs to have a token.

The Heroku addon only needs a token if we want to act on behalf of the user. We receive requests from the Heroku app directly and authenticate our auth ourselves. Aside from rotating credentials for users directly, there is no necessity for a token at all.

We currently use username & password (where we autogenerate a complex password — essentially a token). We could absolute swap this out for a private key in the future. I've used systems like that in the past (e.g. CircleCI integrations that use PKs, a vague memory of this on Heroku as well). It's not an uncommon web2 practice.

[expede]

What is Fission Drive: It would start as a place to store your own personal data.

Your personal files and folders. Public and private. App data both public and private. (Think a URL you can use for diffusion)

I'm not totally sure that this fits the Heroku use case 🤔 I would assume that it's mainly for writing apps, and we can onboard with a Deploy to Heroku button (especially since now that we're in public beta it's possible).

There's no harm in giving users an identity along the way 🤷‍♀️ We need to be aware of shoe-horning in a solution that doesn't map cleanly to the new split model, though. We should maybe consider a scenario where not every app has a user Drive.

But, I could totally be wrong!

[bmann]

A Heroku deploy is equivalent to an app, not a platform user account.

My short comment was meant to highlight that there will be other scenarios like this — where a remote system needs a token of some kind to indicate that it can access services. IF we think this is worthwhile.

We might have a sort of Heroku shadow user, where then afterwards the app can be claimed by the actual user. Do we get email address from Heroku? If so we can actually prompt for people to sign up for a Fission account and have a flow for attaching the app.

[expede]

where a remote system needs a token of some kind to indicate that it can access services. IF we think this is worthwhile.

Ah, okay, I see where you're going with that now. For authentication and authorization, we can leapfrog token use and move directly to PKs (for authentication forwards compatible with DIDs) and either maintain an ACL or use verifiable claims for authorization.

This line of thinking actually gets pretty interesting in the Heroku use-case once apps have client-side key management. The app no longer needs to maintain a complete backend that proxies files to us, but rather just signs a claim that the user's keypair is valid to use their storage. We can do this with tokens as well, but the setup is actually quite a bit more involved. This is a case where if our core hypothesis of client-side key management is successful, everyone wins (us, devs, and end users)

We might have a sort of Heroku shadow user, where then afterwards the app can be claimed by the actual user.

Both a good idea IMO, and totally doable 👍

Do we get email address from Heroku? If so we can actually prompt for people to sign up for a Fission account and have a flow for attaching the app.

We do not get their email (or any other PII) in the standard request. We only get the Heroku app name and a UUID for our add-on in their app. Heroku fully mediates the relationship if provisioned through them.

My understanding is that could add a custom field to the signup flow that asks for then to submit an email (or any other text), but we would need to check Heroku's rules on PII especially in light of how little we get by default.

[expede]

Closed by #313