cohere-coop / nourish.party

Celebrating and nourishing creative communities
Other
6 stars 0 forks source link

RFC: What should the `wp-nourish` plugin do? #8

Closed zspencer closed 6 years ago

zspencer commented 6 years ago

@jtu0 mentioned that we'll want tight Wordpress integration. I'd like it if we build nourish external to wordpress, but had a wp-nourish plugin.

@emdashbuck - What do you think of the following use cases we'd want to support;

???

dashbuck commented 6 years ago

I agree re: having it be external but hook into WordPress. That's in alignment with how WordPress likes to integrate with outside services. This also means that if a creator is using some other website creation thing they'll still be able to play with us!

dashbuck commented 6 years ago

WordPress can do these tasks via API. We need to give users the ability to sign in with the same credentials across multiple parties. After 30 seconds of googling it looks like OpenID can be made to play nice with WordPress. Is that the technology we want to use here? Is there something else better?

We can define as many layers of partygoers as we want if hosts want tiers (spectators, crowd, VIP?).

Yeah, we can do this. Party Favors should be a custom post type with categories, then the category page can be restricted to the correct attendee level.

We'll need:

bhaibel commented 6 years ago

I like using OpenID or OAuth (preference for OAuth if it's as easy to integrate with WP) -- focusing on open standards will hopefully make it easier to build other CMS plugins in the future.

OAuth we might be able to do something with token revocation to force logout? I'm not sure if that's possible, but it sounds plausible.

dashbuck commented 6 years ago

Yep, OAuth is doable. I can't tell which one's easier from here; both are going to require me to do research etc so might as well go with the one you prefer.

zspencer commented 6 years ago

Is single sign on really necessary at this point? Can't we do invitations and have people manage their passwords themselves instead of us acting as an identity provider?

I feel like mandating nourish.party as identity provider would make it harder to adopt?

dashbuck commented 6 years ago

Does OAuth mean we have to manage identity? I thought OAuth meant the user can use a generic login they've already got? I don't know a lot about this space.

zspencer commented 6 years ago

OAuth is a way of allowing people to log in via a different service, i.e. log in with google or log in with facebook.

I don't think we need that, necessarily, since Wordpress's API (I think?) allows us to check if there is a user with a particular email address, invite them, and add them to groups all before they finish the sign up process.

Does that make any sense? I'm working from the assumption that we don't need OpenID or OAuth in order to create users and manage their group memberships in a wordpress instance.

How do you feel about a wordpress plugin that listens by default at <wordpress-site>/nourish-listener/ (or something), which then has full access to make changes to the database? Is that a reasonable way to implement this in WP land? Or should we write the API calls to wordpress directly into the nourish.party site?

dashbuck commented 6 years ago

Hmm. You're right, we don't need those things to create/manage users in a WordPress instance. I was worried about the friction of multiple parties...probably not an important enough issue for MVP. Think I got a bit ahead of myself there, sorry!

I feel like I'm not 100% certain how listening works and I'm not sure WordPress can even do that natively (it's written in PHP). I do know API calls will work!

bhaibel commented 6 years ago

OAuth is a system for managing identity where one site serves as the "identity provider" and the other serves as the "identity consumer." So in Nourish's context, we could have it serve as both, or only as one, or as neither. Having folks log into a given Nourish instance using their Google account would be an example of Nourish being an identity consumer. Having folks log in (or "log in") to a creator's Wordpress using their Nourish account would be an example of Nourish being an identity provider. Having a folks log in to Nourish using Google and then having that pass credentials through to Wordpress would be both.

I think that OAuth (on both the provider and consumer sides, but particularly on the provider side) is really pretty important to making the product useful to creators who want to paywall. That's because the UX of accessing paywalled content by managing two whole new accounts (one for their payment info, one for the content) is pretty bad.

Like, let's say I'm a not very technically savvy person who just wants to read Mariah O'Leary's short stories about talking seahorses. I see on her Twitter that I can do that by signing up at her "nourish" (whatever that is) "instance" (whatever that is.) I go, I sign up, I enter my credit card, this all makes sense, I'm a little annoyed about giving my credit card to yet another place but whatever. That's cool. Then I get an email saying that I can see my talking seahorse stories if I log in to her wordpress. I go, I do that, I enter the password for the account I think I just made (because I'm assuming that my nourish account is the same thing)... and it doesn't work. What do I do next?

All of sudden poor Mariah is spending all her time explaining to people that they need two passwords instead of writing seahorse stories like she really wants to do. I don't like that. I think OAuth needs to be a priority.

zspencer commented 6 years ago

Ah, clarifying point, I don't mean listening like subscribing via an event, but more exposing an endpoint that can receive a POST request when stuff happens inside of nourish, so that the nourish code base doesn't need to know about Wordpress, just that it should send POST requests to a certain location when a partygoer subscribes/unsubscribes and then the wp-nourish codebase knows what data to expect at that endpoint and what to do with it.

I think we're probably reaching the point at which we could split this card into many cards? (I see there's a project, maybe we can promote the cards in the project into Full Issues or soemthing?)

zspencer commented 6 years ago

@bhaibel - That makes sense, I'll make a ticket for nourish to be an OAuth provider

dashbuck commented 6 years ago

Thanks @bhaibel , that's exactly the sort of thing I was worried about across multiple parties. Hadn't thought about it in the context of payment/content access.

jtu0 commented 6 years ago

I :heart: this discussion and like the questions that are getting raised and answered here!

dashbuck commented 6 years ago

I think this discussion has outgrown this issue. I've created a Project and created cards for all of the various stuff we talked about here. Please feel free to add tickets etc to it! I'll be knocking out tasks when I can, although I do have to wait for there to be a Nourish app to connect to. :)