cabal-desktop

cabal-desktop copied to clipboard

Cabal opens up the novel possibility of users posting messages offline, and then having their messages propagated at a later time when they reconnect with other peers.

To other peers, when those messages are downloaded they are inserted into the chat as though they were always there -- as if the past had changed! They see new notifications for new messages, but perhaps the latest message is the same. Spooky.

But depending on when these messages were originally sent, they could be many pages back from where the latest message is, making them easy to overlook. It would be easy to become confused by thinking there were new messages, but not seeing anything new.

How can this unique situation be represented in Cabal Desktop?

Two ideas off the top of my head:

• The 'simplest' solution I can imagine is to have a second number indicator next to channel numbers for new messages which come before the latest known one.
• Having an element indicate that there are new (old...? new old?) messages 'above the fold'. Tricky because you need to introduce tracking which messages have been seen.

Here's a far out idea: using hypercore, is it possible, given two blocks of data, to know if there are any missing blocks between them? If so, you could even have UI indicating that there are missing messages, which could clear up confusing situations like conversations apparently being held with no-one.

@todrobbins Happy to be mentioned if you have a Q, but please don't assign issues to me. :pray:

Got it! Apologies!

yeah it's been coming up now and then. i'd love it if a drive-by designer just magically appeared and made a mockup of the problem lol

one thing you could do is have the slack message line thing but allow it to have two states (or three, but yeah).

• one new messages! from peers just writing while you were tabbed to another channel.
• the other someone just came online with new messages! and highlight them in the backscroll somehow

but yes, it's actually a quite novel problem and i hope someone else swoops in with a nice design pattern 😅

Thanks for highlighting this issue, @sgwilym -- it's such an interesting problem!

It occurs to me that it perhaps has similarities to the "old days" of PC-based email clients (like Thunderbird), where folks would dial up, and receive and send new messages. It must have often been the case that after connecting and sending one's replies, one learned that there had already been a continuation of an email thread. But dialup was also before email was typically even "threaded" ... it was generally up to the user to infer the proper "psychological sequence" of emails (as opposed to the vulgar "time sequence" :)).

What I see as a sort of gnarly problem is that e.g. Alice may have connected to the swarm, downloaded Bob's message #1, disconnected, and then replied offline at length to his message. Meanwhile Bob has written messages #2 and #3, and has synced with other peers. Then Alice returns online, her messages are sent, and although the proper time ordering may be assigned retroactively, there's still the issue that Alice's replies may now seem "off" because, as far as Bob and his interlocutors were concerned, the conversation had moved on.

It's almost as though it would be nice to retain every peer's "version" of the message history that they saw when they were writing their message, so that when you read a message that suddenly drops into the previous history (in the way you'd mentioned), you know the original context in which it was written. Almost like versions of a document.

In any case, another far simpler hacky not-quite-solution that occurs to me is that right now, when I see unread messages in cabal-desktop, they are highlighted in blue; I could imagine that messages that were "inserted retroactively" might be highlighted in e.g. green -- so that I'd know when reading them that I would need to pay extra attention when interpreting their meaning, knowing that their author wasn't necessarily privy to the same message history when writing. And then the fancier version would be that I'd get to toggle between their version of the history and my version of the history when reading, or something :)

End of caffeinated ramble :)

The discussion is about linear message history. But what about implementing branched history? Every message should have an ancestor, and if Alice sends 0, and Bob and Charlie receive it. Then Bob goes offline, and replies with 1 to 0. Meanwhile Charlie replies with 2 to 0. When Bob goes online, 1 shouldn't be tried to be inserted into a linear history, but 1 and 2 should be shown as children of 0. This approach would require more UI work, but it would make the message history clearer. (branches should be collapseable) It would solve #3 also.