Speakerline is completely open to edit

[nodunayo]

I'm a big believer in not solving problems before I have a pain point, but I cannot help but feel anxious about how open the Speakerline site is.

As of now, somebody could go onto the website and edit proposals, even subtly, and I wouldn't know. At the moment, traffic is low. However, the site has huge potential but I'm anxious to push it as I'm wary losing integrity of the data on there.

As of now, there are some options:

• Leave the site as it is

  • Maybe it will be fine, but I won't be able to track the integrity of the data...this seems problematic given the aim of the website

• Add login accounts

  • One of the main positive bits of feedback I get is: wow, that was so quick and easy and I love that I didn't have to create an account
  • Also, then the question: who can edit what? At the moment, anybody can add or edit a proposal for anybody. So far, people have only submitted their own proposals though. With login accounts, do we make that restriction?

• Add a Wikipedia style review process

  • Anybody can suggest changes and they are sent to admins to approve or reject the changes or ask questions.
  • I'm guessing the person would then need to add an email address or something to the suggested change?
  • Does this become potentially problematic for little changes?

Right now, I run a 24 hour backup on the DB and the regularly of that will increase as the database and traffic grow, but for now, what do you think I should do?

@andrew — any thoughts?

[andrew]

@nodunayo wikipedia-style history of edits might be a nice way to avoid requiring a login, recording the IP that made each change would allow you to block troublesome visitors from making further changes whilst allowing anyone to edit.

Or you could have a simplified login-system that that just asks for an email address, then if anyone wants to log back in you send them an email with a login link, there's a pretty nice gem to enable that here: https://github.com/mikker/passwordless

[nodunayo]

@andrew The passwordless idea looks interesting. I'll have a think and look into it. Thanks!

[lolaodelola]

Hey @nodunayo, have you had any more thought on this?

[nodunayo]

Hey @lolaodelola! Yes, I've thought about it a lot, but have still not implemented anything yet.

I was looking into making a way that admins could review and approve any requests for updates that come in before they are propagated to the site.

I considered Andrew's suggestions too, both of which I could see working. Not sure which is best right now and haven't had the time to sit down and focus on it.

Why? Do you have any ideas? 😁

[lolaodelola]

@nodunayo who do you foresee being an admin? Would it be a select group of people like yourself who have an overarching view of the site or would a speaker be an admin of their own content & thus anyone who makes a change to content "owned" by someone else would then (dis)approve content?

My thinking is that realistically the only people likely to make changes about content are those that owns it, which is different to wikipedia in that nobody "owns" any content and therefore anyone can make changes to it. With that in mind, I think @andrew's suggestion is perfect, it keeps things protected without speakers having to keep track of yet another password.

[nodunayo]

@lolaodelola You're right, in that even though I like that anyone could add info for a speaker, ultimately, the information is likely to originate only from the speakers. Having some form of login prevents automated bots (which the RECAPTCHA kinda does now, really), but also limits the damage of any bad actors — they can only add proposals for themselves!

Well, let me know if you'd like to give it a go or not, otherwise, this will be likely something I work on next.

Thanks for discussing it with me. 😊

[lolaodelola]

@nodunayo I've been happy to! Do you have a timeline of when you'd want this done by? I'd like to give it a go but have a few things on my plate at the moment.

[nodunayo]

@lolaodelola There's no rush — if done within the next couple of months, that would be great. I'd like to do it this year! I'm also here to help, answer any questions, do the one-off pairing session, etc. Just let me know. I'll assign it to you for now and check in by end of October if I've not heard anything.

Sound good?

[nodunayo]

@lolaodelola Do you think you will still be able to have a look at this at some piont? I'm not finding that much time for Speakerline right now so am going to tweet out for help soon. Want to know if I should keep you assigned on this one!

Let me know. 😊

[nodunayo]

@CrowdHailer is working on a new paswordless product: did.app. We'll be meeting next week to pair and see if we can solve this issue!

[tomstuart]

@nodunayo Hello! Looks like I was too slow on this one. It sounds like it’s all under control now but I’ll keep an eye on the issue in case you still need help with it in future. 😄

[CrowdHailer]

Can we specify on this issue in a bit more detail what routes want protecting.
I assume something like having proposals have user_ids and then having that user_id in the session is the way forward. I also am unsure how to assign the existing proposals to a user id

[nodunayo]

@CrowdHailer Right, yes — when the issue was created I didn't have an idea of how it should be implemented.

I think something like the following makes sense:

• All proposals are attached to a user
• If you are the user of a given proposal, you have the ability to edit it
• Any proposal you create is owned by you
• All proposals in the database can be assigned to '[email protected]'.
  • I can then reach out to people I know to ask them if I can transfer ownership to their email address
  • A notice can be added that says: "want to make changes to this proposal, email us" — or something like that....

Does that make sense?

[CrowdHailer]

I have a PR over here. https://github.com/CrowdHailer/speakerline/pull/1/files

I've pointed it to my own docker branch so you can see only the relevant differences.
There are several comments that I could do with help on, more just around how rails works and where it wants it's initialization

[CrowdHailer]

Having thought some more about this I actually think using the full gem is over kill, We require such a small amount of the full OAuth spec to do what is needed here. I wrote a general purpose minimal guide for server integrations via OpenID Connect to DID.app here https://did.app/docs/step-by-step-integration/

I think just making the calls with an HTTP client library might be the easiest thing to do.

[nodunayo]

Thanks for looking into this some more.

Is this something you'd want to pair on or something you're happy to take a look at?

[CrowdHailer]

Pairing would be helpful, if there is a time that works? I got rather lost in some bits of rails

[nodunayo]

We had to revert the changes done to close out this issue since the DID.app service shut down.