@warren i think, we should have the option of sharing the posts on the facebook and its revert at the end month of the summer, once the login is complete. What do you think?

This is looking good so far! I'll do a more in-depth review soon -- maybe your mockup could become your lead image? Thanks!!!

Actually, there is some problem with the rich editor. Whenever one tries to edit his/her post then the images are gone away and the lead image becomes one of the images present in the text. I will make an issue of this behaviour.

Hi @warren What all we need in addition to Oauth? I think we can add up the facebook integrations so that people can put stuff in and add through there??? Like the twitter one is made by @sagarpreet?

@sagarpreet I have read your profile.... You and I am are in the same college Delhi Technological University. It's great to see that. If interested and if we get selected into gsoc, we could have a seminar as a part of 3rd evaluation. @warren I would like to have a seminar at my college as a part of 3rd evaluation so that more people will get acquainted with the open source and especially about our community. So, that the new developers will be able to quicken the pace which we are lacking at public labs. Especially the editor project is not touched for many years so that may be enhanced from thereafter by other nerds. @warren I don't know whether it is a good idea or not. @ebarry @sagarpreet from you guys too I want to know whether I should include it in the resume?

I have seen that in the month of September to November the number of contributors on Public labs is less. So, if the seminar will be conducted (if mentors approve) it should be in month of August.

Great idea ! Yes we can conduct a Seminar in our college teaching students about OSS . We can also encourage them to fork PL projects and solve issues and make the PR for the same .

This will not only bring more developer on-board but also help the students to explore the world of open-source :)

Thanks !

Hi! I'm not familiar with how a seminar works are your school, but it sounds interesting! Would this happen during the summer? I do like to see a plan for how proposals will incorporate efforts to welcome new people into the work, to build a bigger community with more capacity. This is one reason we try to break things up so much -- easier to engage people on tasks that are clearly defined and self-contained.

As to OAuth, I think there are a few things I want to understand well:

• what happens if someone logs in once with FB and then with Twitter? Would OmniAuth enable them to both access the same account?
• what about when someone has an account already but then wants to log in via FB -- would it create a distinct account?
• if duplicate accounts get made, is there a way to merge accounts?
• once accounts are created, can we use them to generate the "social media" user tags shown on profiles? (this should be pretty easy)
• Would we be able to link or import Twitter or FB content to PL.org? There's been some good discussion on "comment via Twitter" -- take a look at other discussion on @sagarpreet's proposal: https://publiclab.org/notes/sagarpreet/02-16-2018/social-media-integration-and-part-of-interactive-project-maps (you don't have to implement this, but just be aware of some of the complimentary ideas in others' proposals!)

I hope this is helpful! Also note you have a line saying you'll be adding mockups, which sounds great (although not required!) but if you decide not to add them, probably you should remove that before submitting. :-)

Thank you!

The seminar would be conducted in the month of August. Our University has a footfall 7000+ students. Out of them, many are curious to get involved in the Open Source Development but they don't know how to get started and from where we can get started. So, I can arrange a seminar at my university where I will explain about the Open Source Community, Basic Git Practices, Public labs different projects -plots2, Editor, leaflet etc, GSoC etc. Those who will get in touch me after the seminar would start contributing to the public labs. Regarding the Oauth, it will provide a multi-third party authentication service. I am thinking of introducing identities. A user has many identities. These identities have provider and uid fields. There would be a 'user has many identities' and an 'identity belongs to a user' kind of association. The providers will be present inside the identities. The basic work flow for a new user is as follow: He/she opens the public labs for the first time. He/she wants to make a new account. He has two options either he will click on the sign up through the provider(fb, twitter, github or google) or will sign up through the system which we have currently. If he/she tries to sign up via provider then he will be redirected to user registration form containing password, email address etc(available at /signup). If he signs up through then it will show up the user 4 icons for the four providers at the edit profile page. On clicking on the icon, say facebook the facebook account will be linked in with the main user account. An identity will store the information of the user provided by the provider. If the user then clicks on that same icon again then the user will get notified that you have already enabled a fb account. Now the user can link to any of the accounts. Now the user signs out. Then the user will be able to login through any of the provider which he has linked to his account.

Answers to the questions you have posted If a user logs in via facebook and then sign ups via twitter then he will be logged in. the user will have two identities one for the fb and the other for the twitter. If a person logs in through the current account via password and then links his account via facebook, then there would be a single account. The user will be able to access the same account by any alternative.

Regarding the import from facebook to PL.org we need to use the Koala gem. We can use the Open graph Api of fb. But as you suggested on gitter this yr we are focussing on twitter which is done by sagarpreet.

The strategy which I am adopting will minimise the chances of the requirement of merge of 2 accounts. We will have a single account with all providers linked to it. Also, if required the person will be able to unlink his/her provider account and can link another account. Can you explain in which cases do we require merge??? Want your views. One situation could be a single person has multiple accounts on public labs and has a single Facebook account. He wishes to connect to both of his accounts via his single account on Facebook. So, when the person tries to link an already linked facebook provider to his account which lacks login through FB functionality, he will be notified with flash message - "Please link to another FB account. This Facebook account is already linked to someone" (somewhat).

Yes it will be easy to link to the social media icons listed on the profile page. I previously thought that we could have an integration at the last stage but the integration needs to be done simultaneously. Sorry about that. Also, sign up and login will be done in a single step. If done in multiple steps, it may have some problem in the production. @ebarry, @icartio, @warren, @liz, @mkashyap354 ,@sagarpreet can you please tell me the changes required. Thanks

hi @bansal_sidharth2996 , I liked the way you have divided your timeline. Nice proposal !!!

P.S: I also faced issues while editing my proposal in Rich text mode, but give a try to markdown mode that worked for me.

For me, markdown button will also give the missing research note. So, I am maintaining a google doc.

Hi @warren, I would like to mention that we cannot have a direct sign up from the provider(without signing through registration form) because of many reasons:

User model must have an email. If we are directly writing into the user model then twitter login cannot be made because twitter does not provide email addresses.

A user can have multiple providers. This capability can only be achieved by has many relationships. Hence, we need to have an identity associated with the user.

If a user directly signs up through a provider and then unlinks his same provider account then that will result in the deletion of the user account

There are potential chances of having username same for the user model currently present in the public lab's production database and the username given by the provider so that will result in a conflict

There would be no way of merging accounts of the different provider but of the same person.

A user will have only one provider, so he cannot access the account via another provider.

The case when the person deletes his provider X account A but does not delete his account B on the public lab(say person deletes his facebook account permanently) then he will be no longer able to access his account at public labs

When a person deletes his old account and makes a new account at twitter, facebook, google etc.(Even though there are negligible chances but we need to consider at the time of defining relationships) then the user will not be able to access his previous account at public labs.

Consider the case, when one provider is gone from the market(I am considering the worst case scenario, eg Orkut was a social networking site which is no longer used) then there would be a need to delete the provider's account. That will result in the users account deletion

Hence, we cannot have a direct sign up from a provider. Instead, the user will need to first sign up through the registraion form then he can add providers to his user model. After the linking is successful the user will be able to directly login though the provider. We will be using identities which will be associated with the user model. They can be created or deleted as per the user's need. This will not result in any deletion of account from public labs(until the user wants to delete his account in the public lab) when any discrepancy would happen in future. We could at the later stages (whenever needed ) add other providers like LinkedIn, Instagram etc.

I hope I am clear. If not please ping me, I am ready to explain. Thanks

The proposal looks very good and well explanatory. Nice work @bansal_sidharth2996

@bansal_sidharth2996 this is a very nice proposal!! I specially loved your implmentation details. Also I have a suggestion for you, it would be more effective if you include some mochups or some design UI ideas of bootstraped public labs website of one or two pages.

@thanks @vidit ,@sukhbir. I will.

Hi @bansal_sidharth2996 !

You have provided amazing corner-cases in the comments above !

I agree that Twitter does not provide the email , hence we cannot make the sign-up using twitter .

But we can make for FB and github , right ? I think in the mock - up above , we may give option to link only twitter account because of this constraint of email by twitter .

We can make sign - up through FB , by fetching the email after authentication and searching our User database :

• if that email exists we say that "you are already part of community => please sign-in" .

• else we add the email-id to the User Model . But what about the password and username in User model , right ? How about we send an email to this new user with temporary unique username and a temporary password . In this way he/she will always be able to sign-in through FB but can do normal sign-in only when the user enter the temporary username and password or sets the PL password via the link in the email .

Does this makes sense ? I hope this helps . What do you think ?

Thanks !

Thanks @sagarpreet for your suggestions. One thing I would to say, we should have symmetry with the providers. All providers should be able to be linked or unlinked to the profile or none of them. This will not leave the user in ambiguity. So, from my point of view all providers should be linked/unlinked via the edit profile.

Also, I agree the case of github, facebook and google. We could send them an email and ask them to change their passwords after they receive an email of username and password. But that way there would be three problems

1) The username is some sort of random number so the user will have difficulty in remembering it. We cannot give the user the ability to change the username ,right!

2)A user is having different emails for different providers. So, that way the new user will sign up via different accounts and then he will have different accounts at PL. We will not have any way to merge the information of the different accounts. That will be a big mess. When the user would sign up through different providers, he will expect the same content.

3)Consider the case when user has an account with email address X on public lab traditionally and now he signs up through fb with email Y. So he will have two accounts.

Making of the duplicate accounts is something which we need to deal, I guess so not giving the user the ability to directly sign up would be the best. He can link/unlink his different providers from his user account would be best.

Does it make sense? What do you say @sagarpreet??

@warren we need to ignore one or the other problem while deciding about the OAuth. Expecting that problem might not occur. So your suggestions are of great importance before executing the final stuff.

OK - some VERY good points here. Great thinking. Let me address what I can:

1. if the twitter username collides with an existing PL username, we could offer to modify the PL username, or prompt people for a new one (perhaps suggesting warren1, warren2 etc?)
2. if Twitter doesn't offer email, we can prompt for email just after the account is made, OR
3. we could just allow accounts to not have emails and just be sure whenever doing notifications that we check for email before sending

As to multiple accounts being made, perhaps we need to consider the possibility of a "merge account" system.

With the above considerations, and assuming we can implement them successfully, have we addressed your concerns about OAuth => account generation? In the case of Twitter it may involve one extra step of email input, and we can drop people onto the Signup page for that.

Maybe I missed one of the issues you mentioned -- happy to if you want to point it out, as the comment thread has become quite long!

THANK YOU for thinking this through so carefully! Great discussion in here!

Hi all! What a great thread, i have learned a lot. I also wanted to say how impressive your stats at https://www.stopstalk.com/user/profile/bansal_sidharth2996 are, i had never seen this platform before but clearly you do solve many problems!

@ebarry thanks. @warren thanks for reviewing my proposal. I want to list some further concerns :

1) we could just allow accounts to not have emails and just be sure whenever doing notifications that we check for email before sending Sorry I am not at all in favour of this because if a person forgets his password and unlinks twitter because he does not want to use Twitter to sign up anymore, this will result in inaccessibility of the account. Am I clear? What will happen to the forget password and reset password capabiltiy? 2) Prompt for username and email are good. this will result in asking the username password, email and username isnt it?? So, why not the user first registers and then links his account to twitter.

Am I clear with linking and unlinking of providers to the user accout??

Yeah I want to point out that 1 )A user is having different emails for different providers. So, that way the new user will sign up via different accounts and then he will have different accounts at PL. We will not have any way to merge the information of the different accounts. That will be a big mess. When the user would sign up through different providers, he will expect the same content.

2)Consider the case when a user has an account with email address X on public lab traditionally and now he signs up through twitter with email Y(because he has given email Y to twitter).and then through facebook with email Y(because he has given email Y to Facebook) So he will have two accounts

Making of the duplicate accounts is something which we need to deal, I guess so not giving the user the ability to directly sign up through the providers without registering would be the best. He can link/unlink his different providers from his user account would be best. This will result in the effective creation of accounts and minimum need to merge accounts. The above points are trivial we do by this approach.

What do you suggest @warren?

Yes, I think that makes sense and it's why i like the option of telling people "please enter an email in case you get locked out of your account"

However I think it's partially a matter of thinking of what the minimum steps are before someone can post a comment or question on the site. We can tell them relatively urgently that adding an email is important in case they unlink their Twitter, but it could be /after/ they go through the minimal barrier-to-entry login and get to what they initially want to do which could be to leave a comment or ask a question. It's kind of an ordering thing, and the easier it is to do your first "action" in public lab, the better. @liz, that's right, no?

Also, in case of FB, GitHub and google if we are wishing to have signed up directly with the providers we need to make usernames. I believe that asking the user about username and then about password (via temporary password email sent to the user via email as Sagar reported) is as same as getting the user registered through traditional /signup. That is why I am considering the user can register first and then link up through different providers.

they go through the minimal barrier-to-entry login and get to what they initially want to do which could be to leave a comment or ask a question. The login through provider is a single step always. I was asking about the sign up through the providers.

Ah, not sure about "signup through providers" as @bansal_sidharth2996 highlights. To @warren's question about sequence, i agree. We need to have some nice flow charts to keep track of what additional "onboarding" moments need to happen as we diversify the ways people create accounts. SHould we use our favorite Google Spreadsheets https://docs.google.com/presentation/d/12NU6V9UFeOWKJrql8AIQZI3mKUWTuakF8zrGpOlgrNg/edit#slide=id.g3616e40dc0_0_0 ?

Hi @liz thanks for reviewing my proposal. I have made the flow chart. The workflow is as under

1)The client first of sign up through our https://publiclab.org/signup page. Now he can access his account.

2) If the user wants to login through provider say twitter than he will go to PL.org/profile/edit and will link up the twitter account. If he wishes to link other providers fb, google, github etc he can via this page.

3) Now the user logs out

4)Now he can access the account in a single step by just clicking on the login through twitter button as I listed in one of the mockups.

If we need a way to directly sign up we could add buttons on the /sginup to sign up through the providers. Does this makes sense? If still I am not clear please ping me, I am there to clarify.

"signup through providers" means a first-timer coming to the site and wanting to interact but not yet having an account, and creating an account by clicking Sign up with Twitter or Facebook in order to create an account. This moment is really important to be low-barrier, so people can create an account as quickly as they can, then post their comment/question (their very first interaction with PL!) and then we can circle back to prompt them to add other information.

I appreciate what you're saying @bansal_sidharth2996 that it's pretty similar, but the sequencing I think is really important -- make sure people can do what they came to do as early as possible. We can then show an alert saying if you'd like to link an email address + add a password, it's a good idea -- but /after/ the initial low-barrier login.

Does it make sense how we really want people to be able to engage quickly and smoothly? This is a high enough priority that I think we can show people the "reset password" function ONLY if they'd made a password.

Ok We can do one thing, fb, google and GitHub provides us the email so we can save a random username like warren1 and password. For twitter, let's promt the user for the email that will decrease the barrier for comments and questions. We will directly have buttons on the /signup page for directly signing up through the providers. That will be in addition to what I have written in the proposal. And the edit page will ALSO have links to link and unlink the providers so that they can add/remove more providers. Regarding the passwords randomly generated, we will notify the user to change their passwords on PL once they sign in through the provider via an email. Does this makes sense??

I like that a lot. And for usernames -- we could prompt for username like warren1 based on a best-guess -- github and twitter have usernames (if they're not taken) and google has _____@gmail.com (again, if not taken).

We can say:

Username: jywarren <= in a form, guessed from my GitHub handle, but we let people change it before we save

The other option, to riff on what you're saying, Sidharth -- we could basically bump people to the signup form, but pre-populate everything with what we are able to guess from their other account. @liz, what do you think of that vs. only asking the absolute minimum in a stripped-down signup form?

Yeah, that would be better to have some of the fields in by the provider and the rest the user can fill in and then can sign up via the provider. That was neither the account duplicacy will occur nor will the trouble which we had with the twitter will occur. Thanks @warren What do your suggest @liz?

Hi @warren , @bansal_sidharth2996 !

FB has done some major changes in their API endpoints and for Facebook Login .

See this :
https://developers.facebook.com/blog/post/2018/04/04/facebook-api-platform-product-changes/

Thanks @sagarpreet. I have started looking at them.