private-network RFC by farhoud · Pull Request #67 · functionland/docs

farhoud · 2022-03-25T13:15:52Z

No description provided.

gitaaron · 2022-03-25T13:39:42Z

+- 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, 


What is the purpose of building a temporary workaround to auth/ACL instead of just waiting for the auth/ACL to be developed?

@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

@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.

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?

yes. and i try to add more on it.

gitaaron · 2022-03-25T13:49:03Z

+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.


This sounds related to the discussion @masih and @ruffiano89 were having around the question -
what is the relationship between DID and PeerId?

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.

I will try to separate them.

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

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 ... .

and if we want to use ipfs-cluster then it also have to cover a lot of ground on go lang too.

gitaaron · 2022-03-25T13:52:05Z

+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 


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.

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.

I don't see any overlapping. we are working at different layer.

masih

Great start 👍

masih · 2022-03-25T14:13:31Z

+
+
+## Alternative approaches
+- Using VPN for creating the private network


Expand on this please.

@gitaaron
Can you collaborate with me on this?

Apologies I think I am mistaken on the use case / purpose of this PR. You can remove this.

masih · 2022-03-25T14:14:48Z

+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.
+


We also need to talk about how the network is joined together. So far this reads as a simple key generation RFC.

I will try to add current network topology to background and also how network join in the proposal

masih · 2022-03-25T14:15:18Z

+- fula-client constructor should get another parameter call secret and if exist set connProtector for libp2p
+- create an example for the describing functionality
+
+## Implementation 


Consider providing an overview of steps, where each sub section expands on.

masih · 2022-03-25T14:16:04Z

+}
+
+```
+the box and client already support pkey input, but we should add the above function to them


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.

masih · 2022-03-25T14:18:23Z

+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/>


Flesh this out as a case study with more details. Remove  ?

Co-authored-by: Masih H. Derkani <m@derkani.org>

farhoud · 2022-03-26T15:18:50Z

@masih @gitaaron
I try to cover all the feed back but i still have to work on implementation and case study. its more of preview can u review it.

farhoud · 2022-03-28T09:56:58Z

The second draft is ready.

farhoud · 2022-03-25T13:15:52Z

No description provided.

gitaaron · 2022-03-25T13:39:42Z

+- 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, 


What is the purpose of building a temporary workaround to auth/ACL instead of just waiting for the auth/ACL to be developed?

@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

@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.

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?

yes. and i try to add more on it.

gitaaron · 2022-03-25T13:49:03Z

+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.


This sounds related to the discussion @masih and @ruffiano89 were having around the question -
what is the relationship between DID and PeerId?

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.

I will try to separate them.

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

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 ... .

and if we want to use ipfs-cluster then it also have to cover a lot of ground on go lang too.

gitaaron · 2022-03-25T13:52:05Z

+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 


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.

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.

I don't see any overlapping. we are working at different layer.

masih

Great start 👍

masih · 2022-03-25T14:13:31Z

+
+
+## Alternative approaches
+- Using VPN for creating the private network


Expand on this please.

@gitaaron
Can you collaborate with me on this?

Apologies I think I am mistaken on the use case / purpose of this PR. You can remove this.

masih · 2022-03-25T14:14:48Z

+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.
+


We also need to talk about how the network is joined together. So far this reads as a simple key generation RFC.

I will try to add current network topology to background and also how network join in the proposal

masih · 2022-03-25T14:15:18Z

+- fula-client constructor should get another parameter call secret and if exist set connProtector for libp2p
+- create an example for the describing functionality
+
+## Implementation 


Consider providing an overview of steps, where each sub section expands on.

masih · 2022-03-25T14:16:04Z

+}
+
+```
+the box and client already support pkey input, but we should add the above function to them


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.

masih · 2022-03-25T14:18:23Z

+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/>


Flesh this out as a case study with more details. Remove  ?

Co-authored-by: Masih H. Derkani <m@derkani.org>

farhoud · 2022-03-26T15:18:50Z

@masih @gitaaron
I try to cover all the feed back but i still have to work on implementation and case study. its more of preview can u review it.

farhoud · 2022-03-28T09:56:58Z

The second draft is ready.

farhoud · 2022-03-25T13:15:52Z

No description provided.

gitaaron · 2022-03-25T13:39:42Z

+- 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, 


What is the purpose of building a temporary workaround to auth/ACL instead of just waiting for the auth/ACL to be developed?

@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

@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.

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?

yes. and i try to add more on it.

gitaaron · 2022-03-25T13:49:03Z

+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.


This sounds related to the discussion @masih and @ruffiano89 were having around the question -
what is the relationship between DID and PeerId?

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.

I will try to separate them.

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

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 ... .

and if we want to use ipfs-cluster then it also have to cover a lot of ground on go lang too.

gitaaron · 2022-03-25T13:52:05Z

+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 


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.

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.

I don't see any overlapping. we are working at different layer.

masih

Great start 👍

masih · 2022-03-25T14:13:31Z

+
+
+## Alternative approaches
+- Using VPN for creating the private network


Expand on this please.

@gitaaron
Can you collaborate with me on this?

Apologies I think I am mistaken on the use case / purpose of this PR. You can remove this.

masih · 2022-03-25T14:14:48Z

+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.
+


We also need to talk about how the network is joined together. So far this reads as a simple key generation RFC.

I will try to add current network topology to background and also how network join in the proposal

masih · 2022-03-25T14:15:18Z

+- fula-client constructor should get another parameter call secret and if exist set connProtector for libp2p
+- create an example for the describing functionality
+
+## Implementation 


Consider providing an overview of steps, where each sub section expands on.

masih · 2022-03-25T14:16:04Z

+}
+
+```
+the box and client already support pkey input, but we should add the above function to them


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.

masih · 2022-03-25T14:18:23Z

+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/>


Flesh this out as a case study with more details. Remove  ?

Co-authored-by: Masih H. Derkani <m@derkani.org>

farhoud · 2022-03-26T15:18:50Z

@masih @gitaaron
I try to cover all the feed back but i still have to work on implementation and case study. its more of preview can u review it.

farhoud · 2022-03-28T09:56:58Z

The second draft is ready.

farhoud · 2022-03-25T13:15:52Z

No description provided.

gitaaron · 2022-03-25T13:39:42Z

+- 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, 


What is the purpose of building a temporary workaround to auth/ACL instead of just waiting for the auth/ACL to be developed?

@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

@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.

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?

yes. and i try to add more on it.

gitaaron · 2022-03-25T13:49:03Z

+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.


This sounds related to the discussion @masih and @ruffiano89 were having around the question -
what is the relationship between DID and PeerId?

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.

I will try to separate them.

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

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 ... .

and if we want to use ipfs-cluster then it also have to cover a lot of ground on go lang too.

gitaaron · 2022-03-25T13:52:05Z

+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 


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.

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.

I don't see any overlapping. we are working at different layer.

masih

Great start 👍

masih · 2022-03-25T14:13:31Z

+
+
+## Alternative approaches
+- Using VPN for creating the private network


Expand on this please.

@gitaaron
Can you collaborate with me on this?

Apologies I think I am mistaken on the use case / purpose of this PR. You can remove this.

masih · 2022-03-25T14:14:48Z

+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.
+


We also need to talk about how the network is joined together. So far this reads as a simple key generation RFC.

I will try to add current network topology to background and also how network join in the proposal

masih · 2022-03-25T14:15:18Z

+- fula-client constructor should get another parameter call secret and if exist set connProtector for libp2p
+- create an example for the describing functionality
+
+## Implementation 


Consider providing an overview of steps, where each sub section expands on.

masih · 2022-03-25T14:16:04Z

+}
+
+```
+the box and client already support pkey input, but we should add the above function to them


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.

masih · 2022-03-25T14:18:23Z

+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/>


Flesh this out as a case study with more details. Remove  ?

Co-authored-by: Masih H. Derkani <m@derkani.org>

farhoud · 2022-03-26T15:18:50Z

@masih @gitaaron
I try to cover all the feed back but i still have to work on implementation and case study. its more of preview can u review it.

farhoud · 2022-03-28T09:56:58Z

The second draft is ready.

farhoud · 2022-03-25T13:15:52Z

No description provided.

gitaaron · 2022-03-25T13:39:42Z

+- 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, 


What is the purpose of building a temporary workaround to auth/ACL instead of just waiting for the auth/ACL to be developed?

@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

@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.

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?

yes. and i try to add more on it.

gitaaron · 2022-03-25T13:49:03Z

+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.


This sounds related to the discussion @masih and @ruffiano89 were having around the question -
what is the relationship between DID and PeerId?

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.

I will try to separate them.

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

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 ... .

and if we want to use ipfs-cluster then it also have to cover a lot of ground on go lang too.

gitaaron · 2022-03-25T13:52:05Z

+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 


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.

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.

I don't see any overlapping. we are working at different layer.

masih

Great start 👍

masih · 2022-03-25T14:13:31Z

+
+
+## Alternative approaches
+- Using VPN for creating the private network


Expand on this please.

@gitaaron
Can you collaborate with me on this?

Apologies I think I am mistaken on the use case / purpose of this PR. You can remove this.

masih · 2022-03-25T14:14:48Z

+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.
+


We also need to talk about how the network is joined together. So far this reads as a simple key generation RFC.

I will try to add current network topology to background and also how network join in the proposal

masih · 2022-03-25T14:15:18Z

+- fula-client constructor should get another parameter call secret and if exist set connProtector for libp2p
+- create an example for the describing functionality
+
+## Implementation 


Consider providing an overview of steps, where each sub section expands on.

masih · 2022-03-25T14:16:04Z

+}
+
+```
+the box and client already support pkey input, but we should add the above function to them


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.

masih · 2022-03-25T14:18:23Z

+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/>


Flesh this out as a case study with more details. Remove  ?

Co-authored-by: Masih H. Derkani <m@derkani.org>

farhoud · 2022-03-26T15:18:50Z

@masih @gitaaron
I try to cover all the feed back but i still have to work on implementation and case study. its more of preview can u review it.

farhoud · 2022-03-28T09:56:58Z

The second draft is ready.

farhoud · 2022-03-25T13:15:52Z

No description provided.

gitaaron · 2022-03-25T13:39:42Z

+- 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, 


What is the purpose of building a temporary workaround to auth/ACL instead of just waiting for the auth/ACL to be developed?

@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

@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.

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?

yes. and i try to add more on it.

gitaaron · 2022-03-25T13:49:03Z

+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.


This sounds related to the discussion @masih and @ruffiano89 were having around the question -
what is the relationship between DID and PeerId?

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.

I will try to separate them.

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

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 ... .

and if we want to use ipfs-cluster then it also have to cover a lot of ground on go lang too.

gitaaron · 2022-03-25T13:52:05Z

+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 


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.

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.

I don't see any overlapping. we are working at different layer.

masih

Great start 👍

masih · 2022-03-25T14:13:31Z

+
+
+## Alternative approaches
+- Using VPN for creating the private network


Expand on this please.

@gitaaron
Can you collaborate with me on this?

Apologies I think I am mistaken on the use case / purpose of this PR. You can remove this.

masih · 2022-03-25T14:14:48Z

+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.
+


We also need to talk about how the network is joined together. So far this reads as a simple key generation RFC.

I will try to add current network topology to background and also how network join in the proposal

masih · 2022-03-25T14:15:18Z

+- fula-client constructor should get another parameter call secret and if exist set connProtector for libp2p
+- create an example for the describing functionality
+
+## Implementation 


Consider providing an overview of steps, where each sub section expands on.

masih · 2022-03-25T14:16:04Z

+}
+
+```
+the box and client already support pkey input, but we should add the above function to them


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.

masih · 2022-03-25T14:18:23Z

+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/>


Flesh this out as a case study with more details. Remove  ?

Co-authored-by: Masih H. Derkani <m@derkani.org>

farhoud · 2022-03-26T15:18:50Z

@masih @gitaaron
I try to cover all the feed back but i still have to work on implementation and case study. its more of preview can u review it.

farhoud · 2022-03-28T09:56:58Z

The second draft is ready.

farhoud · 2022-03-25T13:15:52Z

No description provided.

gitaaron · 2022-03-25T13:39:42Z

+- 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, 


What is the purpose of building a temporary workaround to auth/ACL instead of just waiting for the auth/ACL to be developed?

@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

@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.

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?

yes. and i try to add more on it.

gitaaron · 2022-03-25T13:49:03Z

+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.


This sounds related to the discussion @masih and @ruffiano89 were having around the question -
what is the relationship between DID and PeerId?

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.

I will try to separate them.

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

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 ... .

and if we want to use ipfs-cluster then it also have to cover a lot of ground on go lang too.

gitaaron · 2022-03-25T13:52:05Z

+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 


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.

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.

I don't see any overlapping. we are working at different layer.

masih

Great start 👍

masih · 2022-03-25T14:13:31Z

+
+
+## Alternative approaches
+- Using VPN for creating the private network


Expand on this please.

@gitaaron
Can you collaborate with me on this?

Apologies I think I am mistaken on the use case / purpose of this PR. You can remove this.

masih · 2022-03-25T14:14:48Z

+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.
+


We also need to talk about how the network is joined together. So far this reads as a simple key generation RFC.

I will try to add current network topology to background and also how network join in the proposal

masih · 2022-03-25T14:15:18Z

+- fula-client constructor should get another parameter call secret and if exist set connProtector for libp2p
+- create an example for the describing functionality
+
+## Implementation 


Consider providing an overview of steps, where each sub section expands on.

masih · 2022-03-25T14:16:04Z

+}
+
+```
+the box and client already support pkey input, but we should add the above function to them


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.

masih · 2022-03-25T14:18:23Z

+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/>


Flesh this out as a case study with more details. Remove  ?

Co-authored-by: Masih H. Derkani <m@derkani.org>

farhoud · 2022-03-26T15:18:50Z

@masih @gitaaron
I try to cover all the feed back but i still have to work on implementation and case study. its more of preview can u review it.

farhoud · 2022-03-28T09:56:58Z

The second draft is ready.

farhoud · 2022-03-25T13:15:52Z

No description provided.

gitaaron · 2022-03-25T13:39:42Z

+- 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, 


What is the purpose of building a temporary workaround to auth/ACL instead of just waiting for the auth/ACL to be developed?

@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

@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.

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?

yes. and i try to add more on it.

gitaaron · 2022-03-25T13:49:03Z

+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.


This sounds related to the discussion @masih and @ruffiano89 were having around the question -
what is the relationship between DID and PeerId?

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.

I will try to separate them.

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

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 ... .

and if we want to use ipfs-cluster then it also have to cover a lot of ground on go lang too.

gitaaron · 2022-03-25T13:52:05Z

+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 


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.

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.

I don't see any overlapping. we are working at different layer.

masih

Great start 👍

masih · 2022-03-25T14:13:31Z

+
+
+## Alternative approaches
+- Using VPN for creating the private network


Expand on this please.

@gitaaron
Can you collaborate with me on this?

Apologies I think I am mistaken on the use case / purpose of this PR. You can remove this.

masih · 2022-03-25T14:14:48Z

+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.
+


We also need to talk about how the network is joined together. So far this reads as a simple key generation RFC.

I will try to add current network topology to background and also how network join in the proposal

masih · 2022-03-25T14:15:18Z

+- fula-client constructor should get another parameter call secret and if exist set connProtector for libp2p
+- create an example for the describing functionality
+
+## Implementation 


Consider providing an overview of steps, where each sub section expands on.

masih · 2022-03-25T14:16:04Z

+}
+
+```
+the box and client already support pkey input, but we should add the above function to them


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.

masih · 2022-03-25T14:18:23Z

+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/>


Flesh this out as a case study with more details. Remove  ?

Co-authored-by: Masih H. Derkani <m@derkani.org>

farhoud · 2022-03-26T15:18:50Z

@masih @gitaaron
I try to cover all the feed back but i still have to work on implementation and case study. its more of preview can u review it.

farhoud · 2022-03-28T09:56:58Z

The second draft is ready.

rewrite private-network RFC
30c0c0b

farhoud requested review from 2bigO, ehsan6sha, emadbaqeri, ghorbani-m, gitaaron, masih and ruffiano89 March 25, 2022 13:15

farhoud linked an issue Mar 25, 2022 that may be closed by this pull request
design doc: private network #63
Closed

gitaaron suggested changes Mar 25, 2022
View reviewed changes

masih suggested changes Mar 25, 2022
View reviewed changes

farhoudand others added 8 commits March 26, 2022 13:33

Update docs/RFCs/private-network.md
d5e3598
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
44ac8d5
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
10de984
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
041a0b7
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
d0acb97
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
bd04dcd
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
683b3d5
Co-authored-by: Masih H. Derkani <m@derkani.org>

second draft
48e2e09

Add more details on implementation and case study
10225f9

farhoud requested review from gitaaron and masih March 28, 2022 09:41

fix indent.
7bc9efd

masih approved these changes Mar 28, 2022
View reviewed changes

gitaaron merged commit 50d8f6d into functionland:mainMar 29, 2022

rewrite private-network RFC
30c0c0b

farhoud requested review from 2bigO, ehsan6sha, emadbaqeri, ghorbani-m, gitaaron, masih and ruffiano89 March 25, 2022 13:15

farhoud linked an issue Mar 25, 2022 that may be closed by this pull request
design doc: private network #63
Closed

gitaaron suggested changes Mar 25, 2022
View reviewed changes

masih suggested changes Mar 25, 2022
View reviewed changes

farhoudand others added 8 commits March 26, 2022 13:33

Update docs/RFCs/private-network.md
d5e3598
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
44ac8d5
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
10de984
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
041a0b7
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
d0acb97
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
bd04dcd
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
683b3d5
Co-authored-by: Masih H. Derkani <m@derkani.org>

second draft
48e2e09

Add more details on implementation and case study
10225f9

farhoud requested review from gitaaron and masih March 28, 2022 09:41

fix indent.
7bc9efd

masih approved these changes Mar 28, 2022
View reviewed changes

gitaaron merged commit 50d8f6d into functionland:mainMar 29, 2022

rewrite private-network RFC
30c0c0b

farhoud requested review from 2bigO, ehsan6sha, emadbaqeri, ghorbani-m, gitaaron, masih and ruffiano89 March 25, 2022 13:15

farhoud linked an issue Mar 25, 2022 that may be closed by this pull request
design doc: private network #63
Closed

gitaaron suggested changes Mar 25, 2022
View reviewed changes

masih suggested changes Mar 25, 2022
View reviewed changes

farhoudand others added 8 commits March 26, 2022 13:33

Update docs/RFCs/private-network.md
d5e3598
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
44ac8d5
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
10de984
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
041a0b7
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
d0acb97
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
bd04dcd
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
683b3d5
Co-authored-by: Masih H. Derkani <m@derkani.org>

second draft
48e2e09

Add more details on implementation and case study
10225f9

farhoud requested review from gitaaron and masih March 28, 2022 09:41

fix indent.
7bc9efd

masih approved these changes Mar 28, 2022
View reviewed changes

gitaaron merged commit 50d8f6d into functionland:mainMar 29, 2022

rewrite private-network RFC
30c0c0b

farhoud requested review from 2bigO, ehsan6sha, emadbaqeri, ghorbani-m, gitaaron, masih and ruffiano89 March 25, 2022 13:15

farhoud linked an issue Mar 25, 2022 that may be closed by this pull request
design doc: private network #63
Closed

gitaaron suggested changes Mar 25, 2022
View reviewed changes

masih suggested changes Mar 25, 2022
View reviewed changes

farhoudand others added 8 commits March 26, 2022 13:33

Update docs/RFCs/private-network.md
d5e3598
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
44ac8d5
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
10de984
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
041a0b7
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
d0acb97
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
bd04dcd
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
683b3d5
Co-authored-by: Masih H. Derkani <m@derkani.org>

second draft
48e2e09

Add more details on implementation and case study
10225f9

farhoud requested review from gitaaron and masih March 28, 2022 09:41

fix indent.
7bc9efd

masih approved these changes Mar 28, 2022
View reviewed changes

gitaaron merged commit 50d8f6d into functionland:mainMar 29, 2022

rewrite private-network RFC
30c0c0b

farhoud requested review from 2bigO, ehsan6sha, emadbaqeri, ghorbani-m, gitaaron, masih and ruffiano89 March 25, 2022 13:15

farhoud linked an issue Mar 25, 2022 that may be closed by this pull request
design doc: private network #63
Closed

gitaaron suggested changes Mar 25, 2022
View reviewed changes

masih suggested changes Mar 25, 2022
View reviewed changes

farhoudand others added 8 commits March 26, 2022 13:33

Update docs/RFCs/private-network.md
d5e3598
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
44ac8d5
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
10de984
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
041a0b7
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
d0acb97
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
bd04dcd
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
683b3d5
Co-authored-by: Masih H. Derkani <m@derkani.org>

second draft
48e2e09

Add more details on implementation and case study
10225f9

farhoud requested review from gitaaron and masih March 28, 2022 09:41

fix indent.
7bc9efd

masih approved these changes Mar 28, 2022
View reviewed changes

gitaaron merged commit 50d8f6d into functionland:mainMar 29, 2022

rewrite private-network RFC
30c0c0b

farhoud requested review from 2bigO, ehsan6sha, emadbaqeri, ghorbani-m, gitaaron, masih and ruffiano89 March 25, 2022 13:15

farhoud linked an issue Mar 25, 2022 that may be closed by this pull request
design doc: private network #63
Closed

gitaaron suggested changes Mar 25, 2022
View reviewed changes

masih suggested changes Mar 25, 2022
View reviewed changes

farhoudand others added 8 commits March 26, 2022 13:33

Update docs/RFCs/private-network.md
d5e3598
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
44ac8d5
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
10de984
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
041a0b7
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
d0acb97
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
bd04dcd
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
683b3d5
Co-authored-by: Masih H. Derkani <m@derkani.org>

second draft
48e2e09

Add more details on implementation and case study
10225f9

farhoud requested review from gitaaron and masih March 28, 2022 09:41

fix indent.
7bc9efd

masih approved these changes Mar 28, 2022
View reviewed changes

gitaaron merged commit 50d8f6d into functionland:mainMar 29, 2022

rewrite private-network RFC
30c0c0b

farhoud requested review from 2bigO, ehsan6sha, emadbaqeri, ghorbani-m, gitaaron, masih and ruffiano89 March 25, 2022 13:15

farhoud linked an issue Mar 25, 2022 that may be closed by this pull request
design doc: private network #63
Closed

gitaaron suggested changes Mar 25, 2022
View reviewed changes

masih suggested changes Mar 25, 2022
View reviewed changes

farhoudand others added 8 commits March 26, 2022 13:33

Update docs/RFCs/private-network.md
d5e3598
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
44ac8d5
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
10de984
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
041a0b7
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
d0acb97
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
bd04dcd
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
683b3d5
Co-authored-by: Masih H. Derkani <m@derkani.org>

second draft
48e2e09

Add more details on implementation and case study
10225f9

farhoud requested review from gitaaron and masih March 28, 2022 09:41

fix indent.
7bc9efd

masih approved these changes Mar 28, 2022
View reviewed changes

gitaaron merged commit 50d8f6d into functionland:mainMar 29, 2022

rewrite private-network RFC
30c0c0b

farhoud requested review from 2bigO, ehsan6sha, emadbaqeri, ghorbani-m, gitaaron, masih and ruffiano89 March 25, 2022 13:15

farhoud linked an issue Mar 25, 2022 that may be closed by this pull request
design doc: private network #63
Closed

gitaaron suggested changes Mar 25, 2022
View reviewed changes

masih suggested changes Mar 25, 2022
View reviewed changes

farhoudand others added 8 commits March 26, 2022 13:33

Update docs/RFCs/private-network.md
d5e3598
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
44ac8d5
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
10de984
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
041a0b7
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
d0acb97
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
bd04dcd
Co-authored-by: Masih H. Derkani <m@derkani.org>

Update docs/RFCs/private-network.md
683b3d5
Co-authored-by: Masih H. Derkani <m@derkani.org>

second draft
48e2e09

Add more details on implementation and case study
10225f9

farhoud requested review from gitaaron and masih March 28, 2022 09:41

fix indent.
7bc9efd

masih approved these changes Mar 28, 2022
View reviewed changes

gitaaron merged commit 50d8f6d into functionland:mainMar 29, 2022



		## Alternative approaches
		- Using VPN for creating the private network

		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.

Uh oh!

Conversation

farhoud commented Mar 25, 2022

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gitaaronMar 27, 2022• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

farhoudMar 26, 2022• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

farhoudMar 26, 2022• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

masih left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

farhoud commented Mar 26, 2022

Uh oh!

farhoud commented Mar 28, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

farhoud commented Mar 25, 2022

Uh oh!

Choose a reason for hiding this comment

gitaaronMar 27, 2022•
edited
Loading

farhoudMar 26, 2022•
edited
Loading

farhoudMar 26, 2022•
edited
Loading

gitaaronMar 27, 2022•
edited
Loading

farhoudMar 26, 2022•
edited
Loading

farhoudMar 26, 2022•
edited
Loading