Messaging System Exploration

Revision #1.

This is a rough and very preliminary design attempting to provide a visualisation aid for the pieces we envision being part of the initial ElectrumSV (ESV) messaging system.

It should ideally highlight the initial scope and help keep in mind the longer term scope. It won’t be precise, and won’t necessarily be representative of the final result.

Bits and pieces

Let’s break down the different involved elements and consider how they might be displayed and interacted with.

A user is not going to manually add and specify a name for every user who they are involved with. An example of this is a discussion, they might not have added any of the participants manually as contacts. But they will need to see a name for these contacts, and to differentiate between contacts who declare the same name.

So perhaps we can keep it simple and have two aspects we choose to highlight for a given contact:

  • That we distinguish them from any other contact, which can be done through the colouring of their name, and perhaps further down the road some generated image based off some deterministic details to act as their avatar.
  • That we indicate whether they are a known or acquired contact. This might be done through a stock image annotating their name, or merely a bracketed number (e.g. “#23” or “[23]”) suffixed to their name. Both of these things would not be possible for a user to specify as part of their declared name.

A question is how we obtain acquired contact information, and what it should contain. At the very least it should be a requested display name, a link of some sort to an avatar for future use and perhaps a little more. Anything should perhaps have at least for the initial version, strict formatting requirements.

It should be possible to identify the set of events we need to handle. In this case, the most obvious are the following:

  • Notification of available updates to ElectrumSV.
  • Notification of action required with regard to multi-signature wallets the user is involved in.
  • Notification of new messages in any discussion the user is involved in.

There are some further variations on discussion events we might want to consider:

  • Alice does not know Bob, who wants to contact her. He sends her an initial message along with a payment so that she might decide his request is worth reading. Should she accept the request, she may decide to refund him to some degree. Otherwise she might keep the payment.

What other types of events might there be?

We’re not designing anything new here, we don’t want to design anything new here, and it’s very possible what we present for the first design will strongly resemble the minimal form of your favourite chat client. In fact, it probably should.

A list of messages with two columns, time of day and username followed by message. Emojis will replace the assumed standard colon-delimited names (e.g. colons surrounding the word “lollipop” display as 🍭). All messages for a given day will be preceded by a line broken in the center stating the date (e.g. “ —July 6th, 2019 —”). We might do whatever is standard with respect to avatars at some later point.

But then we come to what differentiates one discussion from another. If you have several windows open, each containing different discussions, then how does the user tell which is why by looking at them.

What if the stream of messages wasn’t just comments, but actions. Like setting the title/topic of the discussion. Then it might be in the interest of each discussion group to set it, so that they can differentiate the discussions. Similarly there might be other actions that affect the chat, that get embedded like the messages to other members, but not directly displayed.

Involved user-interfaces

Let’s start with a chat window. This will represent a discussion with one or more people, and the will allow the usual ways of interaction, and access to the same information.

This will be a popup window, but it should also be possible to dock it in the window. Qt should allow this easily. Perhaps they should all dock in the same the tab to prevent a tab-castrophe.

It’s possible to scroll back through the history of the discussion, if you were party to it. If you are a latecomer, you might only see the point from which you joined after being invited, and you would be oblivious outside of message content of those messages.

Everything that deals with someone you have interacted with should link to that person as a contact where possible.

The contacts view would appear as a tab in the current UI:

The goal of this interface will be to present a useful list and overview of one’s contacts. This should allow searching and filtering. Left-clicking would expand the contact, and show details and the most important actions. Right-clicking would offer a contact menu. Double-clicking might pop-out a window with the details and options.

Acquired or known, you have them in your list. You click on them and they expand. Or you double-click and they pop-out. What do you see?

You would want the ability to customise their display name. Perhaps even see their declared display name, as either bundled in some acquisition metadata, or as retrieved from their identity service.

Just because you know a user, or have obtained their id and added them does not mean you can send them messages. You might first have to buy their attention. If a user has identity metadata, then this might imply that not only is there a suggested display name, and perhaps avatar image linked, but also other metadata in the form of things like an attention fee.

It should be possible to add a user who has not been acquired. It might be that you have obtained the id for a user, who you wish to get in contact with.

A possible sequence of events are the following:

  1. The user enters a valid id that is handled by an identity system we support.
  2. The user interface goes off and contacts a server which provides the latest published metadata for that identity. This might be from a blockchain index that provides versions of signed data, or from an identity server for that user and that identity system.
  3. The interface shows the declared identity name (and later avatar).
  4. The user either accepts it, or customises how it displays to them, perhaps even annotates it and then adds it.

This should be searchable, filterable, sortable and interactive. The mock-up below is a guess at how it might look and not representative of a polished end result.

The status bar in the main window displays an indication of how many events you have waiting, and perhaps the importance of the highest priority messages.

The initial implementation would be a list in a tab. A left-click on an entry would invoke the interaction with the event. A right-click a focused context menu of only the most useful actions. If the list of event types is limited and defined, then it might behoove us to have an icon associated with each and use that to make the list more visually appealing. Alternatively, perhaps we could use the avatar of a selected user related to the event — maybe the last person to be involved in it.

A later most polished implementation might be a sidebar like the Windows 10 notifications, which pushes the tabbed area to the left. Or some other approach taken in some other application or operating system.

It should be possible to dismiss specific events, dismiss kinds of events, and to act on events. The default view would perhaps only display the new events, and older events could be selected as part of the filtering.

Further topics

What else needs exploration?

It might be best if this was considered like the BIP270 specification, where there is a base specification for the lowest-common denominator of identity metadata to be structured in JSON, and further specifications for extended functionality.

The base specification might just be some reference to the identity system used, and the requested display name. One extended specification might be an avatar reference, another might be the “attention payment” and declared policy regarding it. We might defer the avatar specification, and proceed with the base and the “attention payment”.

Could signing identity metadata be useful? If your contact signed the details of one of their contacts identifiably for you, and gave it to you, it might be counted as vouching for you. It might also be necessary for a contact when publishing their metadata to sign it, but if they do so via blockchain transaction this might be done implicitly.

There’s a lot of value in creating an application with depth, if we store old conversations, index them and allow the user to find them again when needed.

Similarly if objects (whether discussions, events or even things that have been shared with them, or are perhaps just tagged with them) in the wallet are linked to contacts, and referring to a contact can allow more easy finding of those objects.

We should think about how we associate data with contacts, and how we store it.


ElectrumSV developer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store