Suggestion: message propagation indicator

[sgwilym]

In the same way that many chat clients have UI indicating whether a message has been received or even read, I was thinking it would be really nice to have a way to see if a message has been propagated to at least one other peer.

For example:

1. you send a message while offline in a plane. There is a grey dot next to the message.
2. You reconnect to the internet later, and your message is distributed to other peers. The grey dot turns green.

[dwblair]

Just to put in my $.02, as someone who has started to use Cabal-Desktop with friends -- I think this would be a brilliant feature.

I've also been using Matrix / Riot, and the way they handle it is to show an icon next to the message for every recipient who has received / seen the message. When you're in a room with a lot of people, the icons sort of stack on top of one another; but you're able to hover over and see all the people who've received the messages.

So (dreaming big), I'd raise the bar here even further, and wish for an indication (icons? a integer equal to the number of peers?) of all of the peers who've received a given message. Somehow :)

Thanks for suggesting this!

[dwblair]

Oooh -- @noffle just referenced https://github.com/cabal-club/cabal-client in another issue thread -- which then made me very curious to look and see what shiny new thing 'cabal-client' might be :) -- and it seems as though cabal-client could be a nice way to accomplish the 'which of your cabal peers have accessed this message?' idea proposed here, as per this issue. Easy for me to say ... not sure how to implement :) ... but exciting that there's a possible overlap!

(Been using cabal a bunch for remote chat recently, btw, and it's been super solid ...)

[cblgh]

@dwblair ohhhhh i'm so glad it's been solid recently!

yeah cabal-client is intended to be a common interface for many of the operations any kind of client would want to do, so your suggestion of adding propagation progress there makes a lot of sense ^_^ (we just like, need to make cabal-client hehe)

[dwblair]

Haha -- yes!

And, just mulling this over ... (excuse this ramble if it doesn't make sense ... I'm pretty hazy on the actual architecture of these sorts of things :)) ...

I'm particularly interested in scenarios where a client is running Cabal on a battery, or is otherwise time-constrained -- e.g. off-grid farming scenarios, disaster scenarios, etc. In these cases, I imagine that a client would like to enter the swarm, send a message quickly, and then "log off" / go back to sleep. Becuase sending a message via the swarm sometimes takes a little while (to discover and exchange data with peers), it'd be really great if the 'sender' client knew when the messages they are trying to send as successfully been received by peers (either a particular peer, or any peer). In other words, I'm imagining a sequence like:

• Oooh -- I've got a new message I'd like to send! But I need to do it quickly to conserve battery ...
• Append my new message to my local multi-core / kappa-core
• Attempt to connect to the swarm
• Stop the swarming if either a) one has received a verification / acknowledgement that the message has been received by some peer / a particular peer (depending on use-case), or b) one has reached a preset timeout
• Go back to sleep

I'm currently wondering whether this functionality is actually already present in the existing cabal-core API ... or is almost there ...

Anyway, :) ... I'll continue to mull it over / play around ...

Thanks again so much for all the awesomeness here!

Cheerio, D

[todrobbins]

what about this for communicating peering within the user experience:

1. after you send a message (hit Enter)
2. message appears as grey text until peered
3. message appears as black text when peered

alternatively you could hover your mouse over a message, similar to Slack, and be provided with current peer count:

[hackergrrl]

This would be a pretty easy API to add, since hypercore exposes information about uploads of data blocks to peers!

A tricky & relevant case is that just because you upload a message to a peer, doesn't mean the rest of the swarm will see it. There's no global unpartitioned state in cabal: just a general hope that everyone will eventually peer with each other again. So it's important to somehow communicate that uploading to one peer (or even 3) doesn't guarantee anything.

https://github.com/cabal-club/cabal-core/issues/47

[todrobbins]

Ooh, good points. Maybe just a 🙏 emoji as a status of hope... 🤣

[todrobbins]

or, @noffle, what about a peer ratio? like "3/25 peers have seen this message"? Is that assessable from the swarm?

[hackergrrl]

@todrobbins A peer doesn't know how big the whole swarm is, only how many peers they're personally connected to.

[dwblair]

Great points @noffle & @todrobbins !

Perhaps useful reference: when using the Riot Matrix web chat client, each of my messages has a collection of tiny icons on the far right, indicating the peers who've received the message. If a peer hasn't seen the latest message in the channel/room, then their icon stays back up at the latest message they've seen. Here's a snapshot of a recent chat, demonstrating this:

[todrobbins]

That's clever!

[hackergrrl]

@dwblair: I wonder how that could be modeled on top of a subjectively ordered history of messages! Everything's so much trickier in p2p land: some peers could be ahead of you re certain messages AND behind you re other messages :D

[dwblair]

Oops, hah! That's a great point @noffle ... I see I still need to get my bearings around p2p land :)

Maybe the p2p version of the Riot approach above might simply (hah! easy for me to write 'simply'! :)) display, alongside each message, all of the peers who've seen that message (essentially just @todrobbins 's idea above , but identifying individual peers) ... ?

Related question (I think?): is there a unique identifier associated w/ each cabal message? If not, is that something that could be extracted somehow from the underlying hypercore log? Maybe this is where the idea of a separate cabal-client database as per your other proposal comes in handy ...

[dwblair]

-- i.e., message propagation would then be tracked and displayed at the individual message level -- some graphical indication of:

• "Peers 'ac2f2', 'f2ccs', and '5hmfg' received this message.

(Apologies if I'm simply be repeating earlier proposals, here!)

[hackergrrl]

@dwblair: We could! It's certainly technically possible. I wonder how noisy it'd visually look. I'm thinking also about cabals with 1000s of users.

I wonder if a nice version-1 goal would be to just show a number to the left of each message you publish (how many peers received it), and maybe even fade it out once it reaches 3+. Just to indicate that the swarm has that message in a probably pretty reliable way.

[sgwilym]

Just showing the number of peers/times the data has been shared has good precedent in p2p apps too e.g. ratio in torrent clients. I think it’s enough to just know that your message made it out there and will most probably be seen.

[dorkmo]

maybe an indicator that it hasnt been sent to anyone? Like instead of turning green, the dot just disapears

[dwblair]

@noffle @sgwilym @dorkmo -- really useful, thank you! I think I had conflated two features -- both of which seem very useful in p2p / asynchronous messaging:

1. How widely has this message propagated in the swarm among peers?
2. Has this message been received by its intended recipient(s)?

In many messaging use-cases -- e.g., Alejandro is trying to send a message to Bremen -- I think what the sender really wants to know is the answer to (2) (which I now realize is the focus of this issue). This differs from typical generic p2p filesharing, where a user will be satisfied if they receive a copy of a file from anyone in the swarm.

Answering (2) is a feature that e.g. WhatsApp and Riot offer -- "Bremen saw your message yesterday at 3:20 PM". I think it's particularly useful for small cabals. (I've been frustrated when caballing (can we use that verb? :D) with one or two friends, and I don't know whether they've not replied because they haven't seen the message, or because they're still pissed about the snarky comment I made about their socks ...)

However, in asynchronous p2p chat, if Alejandro has sent a message to Bremen and not yet received the answer to (2) (did Bremen receive the message?), Alejandro will also interested in the answer to (1) (has the message been well-swarmed?): if Bremen hasn't yet received the message, but the message has been well-swarmed, then it's much more likely that she will receive the message.

Punchline: I think the suggestions here of @noffle , @sgwilym , and @dorkmo in this thread are elegant answers to (2) (and I think they work the same way). And then, separately, it seems the answer to (1) will be an additional, useful feature (addressed in this issue).

Apologies for more words than necessary -- early morning coffee is my frenemy :)

Cheers & thanks all!