I have an idea for an app that will allow users to contact each other from within the app. This does not need to be real time. I initially thought about implementing some type of internal messaging system but then realized there’s no reason to go through all that work or deal with the overhead of storing the actual correspondence. All that’s really needed is a way to allow users to email each other without actually divulging their email address - much like Craigslist.
Has anyone done something like this or have any suggestions as to how to proceed?
Hi @philip_ferreira. Unfortunately, no, I have not. At the time, I was doing some very preliminary research in anticipation of the need but have since gotten sidetracked into solving a couple other issues.
I still think that, for my needs, it would be better than an internal messaging system; but I have yet to devote any more thought to it. It might require Sendgrid or another third-party mailer, though. I’ll post back here once I make some progress.
This could be done using Sendgrid (or similar service) as the proxy service, just use Bubble to run the backend. For the app, create a 3 things and use some variation of the following :
Messages
**4 data types: body [text], conversation [Conversations], from [text], to [text]
Conversations
**2 data types: messages [list of Messages], participants [list of Participants]
Participants
**2 data tpes: Users [users], email [text] (optional)
If I’m understanding correctly, you’re essentially creating an internal chat app without the UI and using a email-as-a-service (Sendgrid, Mailgun, etc.) to generate emails to the recipient user. When the users respond to an email, your Bubble app will use the unique conversation ID to route the response to the correct recipient. You would just attach a conversation’s unique ID, for example, to the ‘from’ address (ex. "conversation-ID100001@example.com")
For example:
UserA sends email to UserB from the address conversation-ID100001@example.com
UserB responds to UserA and your Bubble server parses out ID100001 to route the reply back to UserA.
The basic premise is using custom message API endpoints that you create in Bubble, which should allow you to specify a body_format of “html” to preserve the HTML of the email for inbound messages. Similarly, when sending outbound replies, the “body” field of the payload your server receives will contain the HTML version of the message to be sent to the other recipient - a different use-case for a standard messaging app.
Thanks a lot, @supernaturally. You’ve definitely helped stimulate some thinking on this topic.
For my app, I wouldn’t need (or want) to store the content of the messages. I’m interested only in relaying messages between users via email. I’m envisioning a “Send Message” link on a user’s profile page which, when clicked, would open a new message in the message sender’s email client to initiate the conversation. Thereafter, simply replying to an email would send a response to the other user through the platform as an intermediary. Both the sender and recipient would need an account on the system.
The whole idea is to facilitate the conversation, but do so in a way which keeps each user’s email address private - until and unless they explicitly share it with the other party.
As such, it seems the platform would simply need to know who the sender and recipient are on the system. It can then retrieve the email addresses for each party and relay messages between them “on the fly” without storing anything on the system itself. Of course, I’m likely glossing over details, so it’ll be interesting to see what issues arise when I start working through it. For one thing, a simple log with sender, receiver, and timestamp might be useful for troubleshooting purposes. I’ve yet to set up a Sendgrid account, so that’s a bit of a “black box” to me right now as well.
Happy to help. Its sounds like you’re thinking about things in the right way. If relaying emails is the only goal, you might just get rid of #1 (Messages) altogether. You would need at least #2 (Conversation) to store the participants engaged in a specific dialog instance.
Sendgrid is pretty easy once you get the hang of the API documentation, but it can be overwhelming at first. Looking into things a bit further - Sendgrid has an X-Message-ID that is a part of each email’s message ID and is returned in the mail send response for the API. Each email/send receives a unique message ID. When it comes to the Event Webhook, each email event will include this message id so that you can relate the event to its email.
For example: when you send an email, you receive only the first part of the message ID as follows: X-Message-ID = 8XXXXXXXsdfajkjkdfa2
Once the email gets to SendGrid, the second part of the message is created. sg_message_id = “8stGv8SRT76NJeVxk9oVQg.filter0808p1mdw1-26392-590B69BC-C.0”
Using that information, you should be able to work to thread messages together via Bubble. It may sound fairly involved, but it is very doable. You would basically be building out a Craigslist-style relay
This would be exactly what we need to build. If there is anyone up for building this for us using Bubble and Sendgrid (we already use them anyways) we would pay a very good price for it.
Or is there a better place to post freelance job offers?
As the one who started this thread, I just wanted to come full circle and say that I finally had time to design and implement a solution with the following features:
No communication is stored on the system. All correspondence occurs via private email. The platform simply facilitates the conversation without the need for users to disclose their email address.
Only users with an account on the system can communicate with each other.
A user must be logged in to initiate a conversation, which simply opens the user’s default email program to send the message. (Behind the scenes, a database object is created to facilitate communication between the 2 parties, but no message content is stored on the system.)
Users can disable messaging entirely.
Users can selectively “block” other users from sending messages to them.
Conversations can be set to expire. That means a login will be required to re-contact a user when replying to a relayed email message after certain amount of time has elapsed. (I took that idea from Craigslist.)
The following errors are handled with an appropriate response to the message sender:
Sender has no account on the system - i.e. The email address of the sender does not match that of any user on the system.
The recipient is not accepting messages - i.e. has disabled the feature.
The recipient has blocked messages from the sender.
The sender attempts to send a message to themself (which is prevented via the UI, but just in case).
The conversation has expired, in which case the sender is prompted to log in to their account to re-contact the recipient.
This is all working perfectly with both SendGrid and Postmark. I am certain that it will work with Mailgun as well, but I’m not going to spend $35 just to prove it. (Their free tier doesn’t offer inbound processing.) It will not work with Sendinblue, since they currently don’t offer inbound processing it all.
This started out as a need for a personal project but recently became a requirement for a business venture, which provided the impetus to come up with this solution.
Do you have time to offer any insight as to how you accomplished this? My app is a directory that allows non-logged in users to post listings by only verifying they’re human via sms.
Other non-logged in users are able to search and respond to these listings. If someone has a question about a listing they need to be able to send an inquiry, but I don’t want the email of the person who created the listing to be visible.
Thanks in advance for any guidance you’re able to provide.
Just trying to get a sense for how many people might be interested in this solution if I were I to make it available (at a cost). It would walk through setup and configuration step by step to create a fully functioning integration using your own Postmark or SendGrid account. I’m talking about providing working Bubble logic - not screenshots and/or screencasts.
If you have a need for an email relay messaging system, feel free to PM me to express your interest so that I can gauge demand.
It will not work with Sendinblue, since they currently don’t offer inbound processing it all.
