Pump.io's only-thread-originator-gets-notification problem and Pumpa's bad fix
I wrote a really long response to this thread on pump.io which illustrates a long-standing problem in pump.io which I have dubbed the “only-thread-originator-gets-notification problem”. As you may know I am the author of Pumpa, a client for pump.io, and Pumpa has a “hack” that tries to circumwent the problem, unfortunately this has some unintended consequences which are also illustrated by the thread (the fact that nobody except me can see @mray’s comments to this thread).
I’m going to repeat my explanation of the problem here in my blog for posterity (with some minor fixes and changes):
Person A posts a new major post in pump.io (ie. a new note, not a comment). Let’s say this post was directed “Cc: Public”, i.e. a publicly readable pump.io message.
Person B replies to this. If he or she uses anything else than Pumpa the client will not fill in the To/Cc fields of the reply, but instead rely on the server doing this. The server will automatically copy the To/Cc of the original post plus add person A in the “To” fields so that person A receives a notification of it. So far, so good. (We’ll get to what Pumpa does in a moment.)
Then person C comes along and also replies to the conversation. Since the web UI doesn’t really support deeper threads, most clients place this reply as a reply to the original post by A. If person C uses anything else than Pumpa the client again will not fill in the To/Cc fields but rely on the server doing that. The server will do exactly what it did in step 2, i.e. copy the original post’s To/Cc (Cc: Public) and fill in person A only in the “To” field. This leads to the situation that only A gets notified of the reply, and not B. This is the problem that @mray was having, i.e. he was not seeing replies from @maiki, because he was not the originator of the thread. (In fact in this case person C is the same as A, but it doesn’t matter for this issue.)
We’ve known about this issue in the pump.io community for a long time, and I’ve posted about it many times before, but no global solution has yet been settled on. To try to fix this problem in Pumpa, it does something slightly different when posting replies (steps. 2 and 3.). Instead of relying on the server it tries to fill in the To and Cc fields itself. It copies the To/Cc of the original post, adds person A, and then if person C pressed “comment” on person B’s reply also adds person B to the To field, thus both should get notifications in step 3. above.
Unfortunately this behaviour by Pumpa doesn’t always work as expected, and I’m unsure if it was a good idea in the first place. The problem is, there are cases where the client no longer is able to deduce the To and Cc of the original that it should be copying. Since the user is closing the client and starting it again it cannot have the same information in memory as the server. And if you are e.g. seeing the object you are replying to via someone liking it or repeating it may have lost the original To/Cc information (which is really connected to the posting action not the object, but this is getting to deep details of the protocol). So I believe this may be the problem why @mray’s replies to me are not having proper To/Cc’s.
That’s what I wrote in the comment. Now I really hope that the pump.io community could get together and fix this problem. I can see a few possible alternative solutions:
Clients could continue on relying on the pump.io server, but it would instead fill in all people that have previously replied to the thread when you are posting a response. I.e. in step 3. it would fill in both A and B as To-recipients.
There could be a mechanism to tell the server to “do whatever you would do automatically, but also add this person as a recipient”. Maybe add a new field “To+auto:” or something… (This alone would only fix Pumpa’s solution, not the overall problem.)
Have a mechanism for the client to reliably determine the original To/Cc of any object, or better yet the original posting action. This again should fix the problems of Pumpa’s solution only.
My vote is on implementing both 1. and 2. Solution 1. would be a fix that would instantly fix it for all clients. Solution 2. would still be useful, since users can then reliably trust the server to do the right thing, but also add additional recipients. Maybe you wish to pull in a fourth person into discussion. (Hey, @foobar, did you see this?).
Solution 3. would be useful, but require another HTTP request + few clients will likely implement this, so the overall problem is still there.
(Also, please do not suggest allowing deep threading, since then the discussion will descend into arguments about threading, and it would still not solve the problem of notifying both A and B in the example. It’s a discussion for another day :-)
Posted by Mats Sjöberg.