-
Notifications
You must be signed in to change notification settings - Fork 8
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
private-network RFC #67
Conversation
docs/RFCs/private-network.md
Outdated
- Functionland Issue: | ||
|
||
## Background | ||
we are using IPFS as our file system. but IPFS is build to use for public data, and it does not support ACL, |
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.
What is the purpose of building a temporary workaround to auth/ACL instead of just waiting for the auth/ACL to be developed?
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.
@gitaaron
I don't think the security layer that cover all the stories would be ready in at least 3 month. and also i personally can't relay on access control by encryption only to make user safe. with this solution we can demo useful box and photo in in around a week.
As @masih mention i should explain more on public network risk's
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.
@farhoud thanks for the clarification. I am still not sure where this PR is coming from (probably because I joined the team after this work commenced). Could you please share a few of the use cases / user stories this PR is solving? What I am trying to understand is how this PR will directly impact BOX customers and their capabilities.
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.
It seems to me that this PR is trying to cover two different scenarios -
- Private communication between the fula-client and fula-api (eg/ uploading a photo to a BOX and retrieving a photo from a BOX)
- Private communication between BOXes or other 'peers' in the fula-network (eg/ data syncing)
Is that correct?
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.
yes. and i try to add more on it.
docs/RFCs/private-network.md
Outdated
For box setup user provide an environment variable SECRET which is password he should remember. | ||
the secret then convert to a hash of 256 bit by algorithm like sha256 and generate the swarm.key for ipfs and libp2p node's. | ||
|
||
For Fula client when user call createClient he should also provide the password he used for setting the box's. |
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 sounds related to the discussion @masih and @ruffiano89 were having around the question -
what is the relationship between DID and
PeerId
?
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.
I think by adding the human readable password i make this PR a little bit complicated. but my thinking was asking user to enter a 64 character in web app or photo's is painful task so i suggest to change it to more human readable think.
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.
I will try to separate them.
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.
I think when we can use DID instead of Peer id to connect (verified connection) box <---> box and client <---> box which also most cover internal IPFS like bitsawp engine then that's the end of life for this proposal
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.
I think when we can use DID instead of Peer id to connect (verified connection) box <---> box and client <---> box which also most cover internal IPFS like bitsawp engine then that's the end of life for this proposal
like the libp2p gatekeeper should use the DID to let others connect to my box or ... .
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.
and if we want to use ipfs-cluster then it also have to cover a lot of ground on go lang too.
docs/RFCs/private-network.md
Outdated
For network discovery its manual process that user should provide all box peer id's in config. | ||
|
||
## Scope of work | ||
- human friendly password to swarm.key |
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.
Perhaps this could be broken into its own doc? The doc would answer the question - what is the user interface that enables us to provide a human friendly password and generate a shared swarm.key at the same time? Once again sounds related to what @ruffiano89 is working on.
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.
I think by adding the human readable password i make this PR a little bit complicated. but my thinking was asking user to enter a 64 character in web app or photo's is painful task so i suggest to change it to more human readable think.
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.
I don't see any overlapping. we are working at different layer.
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.
Great start 👍
docs/RFCs/private-network.md
Outdated
|
||
|
||
## Alternative approaches | ||
- Using VPN for creating the private network |
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.
Expand on this please.
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.
@gitaaron
Can you collaborate with me on this?
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.
Apologies I think I am mistaken on the use case / purpose of this PR. You can remove this.
For Fula client when user call createClient he should also provide the password he used for setting the box's. | ||
|
||
For network discovery its manual process that user should provide all box peer id's in config. | ||
|
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.
We also need to talk about how the network is joined together. So far this reads as a simple key generation RFC.
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.
I will try to add current network topology to background and also how network join in the proposal
docs/RFCs/private-network.md
Outdated
- fula-client constructor should get another parameter call secret and if exist set connProtector for libp2p | ||
- create an example for the describing functionality | ||
|
||
## Implementation |
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.
Consider providing an overview of steps, where each sub section expands on.
docs/RFCs/private-network.md
Outdated
} | ||
|
||
``` | ||
the box and client already support pkey input, but we should add the above function to them |
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.
-
Capitalise first letter in paragraphs. I'll stop pointing this out for the rest of the document.
-
Seems like there is a specific place in code you envision this needs to be added? If so, link it up.
docs/RFCs/private-network.md
Outdated
the box and client already support pkey input, but we should add the above function to them | ||
and after that we should change existing pkey on both fula and box to use the above function. | ||
|
||
for creating an example we can create copy of react-gallery and add the password field in config.<br/> |
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.
Flesh this out as a case study with more details. Remove <br/>
?
Co-authored-by: Masih H. Derkani <[email protected]>
Co-authored-by: Masih H. Derkani <[email protected]>
Co-authored-by: Masih H. Derkani <[email protected]>
Co-authored-by: Masih H. Derkani <[email protected]>
Co-authored-by: Masih H. Derkani <[email protected]>
Co-authored-by: Masih H. Derkani <[email protected]>
Co-authored-by: Masih H. Derkani <[email protected]>
The second draft is ready. |
No description provided.