StarPort research

Calling it StarPort until we have a better name.

### Details

We need to build a library that enables us to easily scale up our apps and services. To do this, we need to be able to authenticate sessions from Web 2 users and allows them to engage with Urbit ships.


By focusing on the rooms use-case we can build out a robust framework.

### Rooms integration
The way `%rooms` works right now is that it is tied deeply into the `@holium/realm-rooms` lib found in `/lib/rooms`. This keeps everyone in sync and allows for WebRTC to connect to peers on Urbit.

The hosted version of rooms would be one where "temp account" links are generated and can be sent out. These would be similar to how the [magic email link](https://auth0.com/docs/authenticate/passwordless/authentication-methods/email-magic-link) systems work except they would be redeemed by setting a username in an initial splash page.

The StarPort middleware would be the method by which these "realm links" are created. Once the web 2 user has a valid "cookie" generated from this process, they would be redirected to a url hosted on the RoomsServer that returned the rooms web app (this would need to be built as the current Rooms app is fully embedded in Realm).

The workflow would look like this:
- In Realm, I create a new room and choose the hosted option.
- I could still invite users within Urbit.
- I would be able to generate a link with a unique UUID in the rooms tray in Realm.
- perhaps you could generate a bulk code or single use codes?
- I paste that link on Twitter.
- People click the link and are directed to `rooms.holium.xyz/?accessCode=`
- They are prompted to create a nickname.
- They are redirected to the rooms web app hosted at `rooms.holium.xyz/` and can start chatting.

#### StarPort specific watch path
We should force developers to use a specific watch path for starport.

As the dev who built `%rooms-v2`, I would add a new watch path called `/starport`. In the `on-init` of `%rooms-v2`, I would poke the `%starport` agent registering the `%rooms-v2` agent.

I would then build out the RoomsServer and use the StarPort middleware to connect via airlock to my star's `%starport` agent. The Starport middleware would have an in-memory copy of the state from the `%rooms-v2` agent and any other agent registered to starport. This way we could add multiple apps and services to one hosted server.

#### Poking from a StarPort account
Instead of poking the `%rooms-v2` agent directly from the RoomsServer, we would poke through the StarPort middleware and relay that through the `%starport` agent to `%rooms-v2`. The `%starport` agent would have the temp account information send along with the poke to a specific mark `%starport-action`. This would allow us to append the temp account data to the poke and handle it properly. All pokes from other Urbit ships would be handled by the `%rooms-v2-action` mark.

### Starport paid usage
Once we start integrating crypto payments into Realm, we can build premium payments into starport, where we have our star provide services to communities for an additional fee paid in crypto. For the purposes of the initial R&D, I don't think this is necessary to explore, but should be noted.