-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cell Joining Code #3
base: social-process-how
Are you sure you want to change the base?
Conversation
The cell joining URI format MUST follow this structure: | ||
|
||
``` | ||
hc://join/<dna_hash>/<dna_modifiers>?proof=<membrane_proof>&metadata=<metadata> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hc://join/<dna_hash>/<dna_modifiers>?proof=<membrane_proof>&metadata=<metadata> | |
hc://join/<dna_hash>/<dna_modifiers>?name=<name>&proof=<membrane_proof>&metadata=<metadata> |
The name of the cloned cell is optional but it may be used in your app for referencing the particular cell
- Reduce user error during configuration | ||
- Enable one-click joining capabilities | ||
- Facilitate easier sharing of network access | ||
- Facilitate services providing "always-on" Cells: simply provide the DNA and joining code |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Facilitate services providing "always-on" Cells: simply provide the DNA and joining code | |
- Facilitate services providing "always-on" Cells: simply provide the .dna file and joining code (this does *not* include always-on nodes for happs). |
The only use case I'm aware of for this is holo's always online node service. I don't know if they would be supported by this proposal since they may host the entire happ, not just a single cell.
Although maybe they do want to support hosting a single cell. If so, then I believe providing the .dna
file along with the joining code would be sufficient.
Where: | ||
|
||
- The scheme MUST be `hc://` | ||
- The path MUST start with `join/` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rationale:
- a "verb" of what the code is intended to be used for
- makes the code self-describing
- leaves open the possibility for other kinds of
hc:
codes. Can we think of any or is this not expected? Maybe things like remote calling a zome fn on a specific agent's node with some input?
|
||
Where: | ||
|
||
- The scheme MUST be `hc://` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- The scheme MUST be `hc://` | |
- The prefix MUST be `hc:` |
I'm thinking this should not be an actual URI, because if you did want to use joining codes for deep-linking to your app, you would probably want a custom scheme for just your app.
Otherwise, if you supported hc://
link schemes for your app, then joining codes intended for other apps might still be opened by yours, and it gets pushed up to the user to figure out which apps can open which joining codes.
On the other hand, if we keep this a URI, then we encourage it to be used for deep linking, and an app can just refuse to use a joining code not intended for itself.
Is it valid uri format to have a uri with multiple schemes? I.e. my-app://hc://join/...
. If so that might give us the best of both worlds: create an app-specific scheme if you want, otherwise use the generic one. If this is not a valid uri, then I'm leaning towards not having it be a uri at all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it valid uri format to have a uri with multiple schemes? I.e. my-app://hc://join/.... If so that might give us the best of both worlds: create an app-specific scheme if you want, otherwise use the generic one. If this is not a valid uri, then I'm leaning towards not having it be a uri at all.
No it is not valid to have multiple schemes in a URI. Thus I think the best approach is to make this just a path, not a URI.
A standardized joining code format would: | ||
- Simplify the process for inviting someone into a network | ||
- Simplify the implementation of sending and receiving network invitations in apps | ||
- Facilitate services providing "always-on" nodes for a particular Cell |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This proposal is for joining codes for a single Cell -- not for an entire happ (multiple cells).
I'm opening this PR as a draft to show my work but also not ready to submit it as DRAFT yet. Depends on #2 anyway.