Database Design for Threaded Conversations

Question

I have a scenario that looks like this:

1. User A is a registered user.
2. User B is just a visitor (not registered).
3. User B needs to send a message to User A (without having to register).
4. User A needs to reply to User B.
5. Repeat steps 3 & 4 ad infinitum.

So basically I've implemented this simple table structure:

id
id_message (= 0 on first contact or = id on replies) 
from
to
message
date_created

The idea is that each message where id_message equals to 0 would have it's on public URL so that both parties could access it and see the threaded conversation. For User A I just need to store his user id. for User B, since he is not registered I would need to store his name, phone/mobile number and email address (serialized of course). Each time a new message is posted the other party receives a warning email regarding the update.

However I see some problems with this approach:

• Serialization of User B details doesn't seem "right".
• User B needs to enter the same details each time a reply is needed.
• I can't think of anything else right now, but I'm sure there are other problems that come up with this approach.

Basically, what I'm looking for is the best solution for a complete stranger to engage in a conversation with a registered user while keeping the ease of use for both parties. What do you guys think, should I take this approach? Are there any other clever alternatives to solve similar problems?

Answer 1

The simplest answer is often the best. Make the user register.

But you can have two kinds of users: basic users and premium users. Basic users don't need much in the way of registration - you could even allow their email address to be optional. The premium users would have to include all the details, and they'd get to use all the features.

This way, you have a pair of real, registered users who can communicate with each other, while having a very low barrier to entry for new, basic users.

Answer 2

You could use use an effectively random value in the URL, similar to a session ID, for user B such that he has to have/know this URL in order to get back to the conversation. Of course, you would probably want to e-mail (?) this URL to User B, so he would still have to give you some contact information. If you simply gave him a link or told him to bookmark the page, it would be too easy to "lose" the conversation and be unable to continue it.