[Discussion] Connecting matched partners

[angelocordon]

Feature Story: As a matched user, I should be able to connect with my matched partner intuitively.

--

The original idea stated that matches will be emailed by the platform so that their personal email addresses are anonymized. A matched user can then reply to the email and an email chain will be created:

platform emails both matches,
match 1 replies back on the thread ---> gets sent to the platform ---> gets sent to match 2,
and then vice versa. 

I think there's an in between layer here that handles the emails from the server side, but that seems very murky to me currently.

--

I want to propose that we explore alternative routes as multiway emails are really difficult to manage + outside variables that can potentially send emails from our platform to a user's spam folder, then missing connections.

I think it might be a more doable challenge to build out an in-platform messaging feature as we can control the environments more proactively, and also be able lean in more on Meteor's own reactive system (data on the wire philosophy).

We would still need to use emails as a form of notifications, but at least that way we've cut that down to a one way flow (our only responsibility is to notify users, we don't have to listen for incoming messages).

-- Relative issue for reference: #8

[angelocordon]

Question from the Discourse group; adding in this issue as a way to keep track of notes and decisions being discussed (slightly edited):

Are you proposing moving away from that for technical implementation reasons (we don't know how to implement), or because you think users might naturally want to have discussions on the platform and not via email?

From the former perspective, while I don't doubt that we could figure out how to implement, I'm questioning the time we'd have to invest in researching and testing to get a multiway-email-messaging system in place, even if it was just a prototype. From my past experience of handling system generated emails, email is a whole other beast that I'm not quite sure any of us are prepared to own (outside of one-way notifications, that is).

Let's say we do implement a system like this - the whole notion of being able to connect with someone is going to sit on this particular feature; so we can say this part of the platform is quite essential. We can know when emails from our platform are sent, but how do we know if they're being read? I'd think that aspect would be important to us as we'd want to know how engaged our matches are. Sparkpost would probably have a reporting layer that would give us that info, but we'd have to research if we can use any of that programmatically so that we can at least tell our users if they've been ghosted or not.

That's the first part, the second part is for the users to be able to reply back to the same email so that they can have a conversation. A user sends a reply email to the email address, our system would listen for inbound emails, then... we'd forward that message to the intended recipient?

At this point, we'd have to think about how many emails are we sending off, how many emails are we collecting and how many emails are we forwarding? What is going to be the average emails we accrue during a connection period (counting conversation emails per connection)? How fast are we going to hit our email limit?

We could probably spend somewhere between $120/year to $600/year (based on Sparkpost pricing, which... not terrible, but still money going out)

And then the notions of what if email clients mark our emails as spam? IIRC, there's a system in place where we have a reputation score, and if our reputation score goes down enough, our emails could very well just not reach a mass amount of people. Also, we'd have to look into can-spam rules.

So, while we could build it, I'm wondering if it's going to be worth it?

Say we do build an in-app messaging system -- same concept and notion that this is how people connect, still a pretty essential feature. They'll be emailed still that they have a match, or if they have messages that need to be read, but email cost I think would significantly go down in comparison, or at least our email runway could stretch longer. In-app messages just live in our db, which we have lots of credits for (therefore cost to that is free-ish). The things that could go wrong would be very much within our control. Or at least we could control more.

We could have user logs of when they last signed in, we could build ways within the system of if they've read a message or not and I think it's more flexible in a way that we would allow users to share the info that they want, without us having to specifically guard their privacy -- in the sense that if they want to share their emails so they can move off our chat, that's really on them while we would never share their contact info on purpose, what they do with their data should be their business

So I think while in-app messaging could totally have its own challenges, the tradeoff seems to me to be more manageable, if the whole premise of this particular feature is to start conversations between two people.

users might naturally want to have discussions on the platform and not via email

I don't know, to be honest - we don't really have enough data to support that. Users can certainly move to emails outside of an in-app messaging, too, but we'd have to build both systems to test it the other way around (seems silly to do that). I think in context, it's really more, which technical implementation do we want to manage more?

[lpatmo]

Thanks for pasting the discussion over to Github!

Seems like most of us are gravitating towards the idea of in-app discussion threads between matched partners.

Until we build that out, I'm still pondering the idea of Sparkpost firing an email to both parties, with the emails visible. Curious if anyone has stark objections to that, as an initial solution.

[angelocordon]

We could do that, I think we probably should assess the importance of anonymity in the platform. I get some of the use case but does it have to be supported off the bat? We could release that as a feature at a later date.

One way emails to both addresses should be fine 👍