This won't change how we decide if a notice is in reply to a /person/ -- that will still just depend on the @ syntax. And I'm not addressing using @ across different instances. So, don't ask about those.
Replies currently work like this:
if (in_reply_to is set) {
notice.in_reply_to = in_reply_to;
} otherwise {
notice.in_reply_to = last notice by first @name in content;
}
The main error we get here is that stuff where you're starting a new
conversation ("@zach how are you doing?") or where you mention someone
off-hand ("I saw @csarven at work today") looks like a response to their
latest notice. This means that new notices tend to appear in
conversations they don't belong in.
I'd like to fine-tune this. Both the Web and API input channels accept in_reply_to; so we really only need to guess with "narrow" (text-only) channels like email, SMS and XMPP. A new algorithm would be:
if (in_reply_to is set) {
notice.in_reply_to = in_reply_to;
} else if ((notice not from API or Web) and (notice content starts with
"@name ")) {
notice.in_reply_to = last notice by initial @name in
content;
}
}
I think this would handle the two false-positives mentioned above. The
only way I can of that it would give false negatives is for clients that
don't set in_reply_to. Which they really should.
We may want to fine-tune this further in the future by putting a time limit or inbox limit on those other input channels. It's very unlikely that someone is replying by XMPP or SMS to a notice that was posted 8 months ago, or to a notice that they didn't receive via XMPP or SMS.
Note that we won't be able to fix old notice's in_reply_to fields, but that's probably OK.
Comments? -Evan
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Laconica-dev mailing list [email protected] http://mail.laconi.ca/mailman/listinfo/laconica-dev
