Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: message propagation indicator #122

Open
sgwilym opened this issue Jun 1, 2019 · 18 comments
Open

Suggestion: message propagation indicator #122

sgwilym opened this issue Jun 1, 2019 · 18 comments
Assignees
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@sgwilym
Copy link

sgwilym commented Jun 1, 2019

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
Copy link

dwblair commented Jun 1, 2019

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
Copy link

dwblair commented Jun 3, 2019

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
Copy link
Member

cblgh commented Jun 3, 2019

@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
Copy link

dwblair commented Jun 6, 2019

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 todrobbins added enhancement New feature or request help wanted Extra attention is needed labels Jun 10, 2019
@todrobbins
Copy link
Member

todrobbins commented Jun 13, 2019

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:

peer-count

@todrobbins todrobbins self-assigned this Jun 13, 2019
@hackergrrl
Copy link
Member

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.

cabal-club/cabal-core#47

@todrobbins
Copy link
Member

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

@todrobbins
Copy link
Member

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

@hackergrrl
Copy link
Member

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

@dwblair
Copy link

dwblair commented Jun 13, 2019

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:

peers

@todrobbins
Copy link
Member

That's clever!

@hackergrrl
Copy link
Member

hackergrrl commented Jun 13, 2019 via email

@dwblair
Copy link

dwblair commented Jun 13, 2019

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
Copy link

dwblair commented Jun 13, 2019

-- 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
Copy link
Member

hackergrrl commented Jun 13, 2019 via email

@sgwilym
Copy link
Author

sgwilym commented Jun 14, 2019

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
Copy link

dorkmo commented Jun 14, 2019

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

@dwblair
Copy link

dwblair commented Jun 14, 2019

@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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

6 participants